,

Chapter 3

Developing the Project Scope Statement

The PMP® exam content from the Planning the Project performance domain covered in this chapter includes the following:

• Task 1: Assess detailed project requirements, constraints, and assumptions with stakeholders based on the project charter, lessons learned from previous projects, and the use of requirement-gathering techniques (e.g., planning sessions, brainstorming, focus groups) in order to establish the project deliverables.
• Task 2: Create the work breakdown structure with the team by deconstructing the scope in order to manage the scope of the project.
• Knowledge and Skills:
  • Requirements gathering techniques
  • Work breakdown structure (WBS) tools and techniques
  • Scope management techniques
  • Elements, purpose, and techniques of project planning

Great job! You’ve successfully completed the project Initiating processes and published the project charter, the stakeholder register, and stakeholder management strategy. The project is officially underway. Stakeholders have been identified and informed of the project, you have management buy-in on the project, the project manager has been assigned, and the project objectives and description have been identified. A solid foundation for the planning process is in place.

In this chapter, we will begin the Planning processes for the project. In fact, I will continue discussing the Planning processes through Chapter 7, “Planning Project Resources.” Planning is a significant activity in any project and, if done correctly, will go a long way toward ensuring project success.

This chapter begins with the Develop Project Management Plan process. This process will describe the overall approach you’ll use to manage the project. The result of this process is the project management plan document that describes how you’ll execute, monitor, and control the project outcomes as the project progresses and how you’ll close out the project once it concludes.

Then you’ll move on to the Collect Requirements process. During this process quantified requirements are gathered and documented to assure stakeholder needs are met and expectations are managed.

During the Define Scope process, you’ll use the project charter and the requirements documentation—plus some other inputs—and then apply the tools and techniques of this process to come up with the project scope statement. I’ll talk in depth about project objectives, requirements, constraints, assumptions, and other elements of writing the project scope statement, which is an output of this process.

Once you have the deliverables and requirements well defined, you’ll begin the process of breaking down the work of the project via a work breakdown structure (WBS). You’ll accomplish this task in the Create WBS process. The WBS defines the scope of the project and breaks the work down into components that can be scheduled and estimated as well as easily monitored and controlled.

We have a lot to cover in this chapter so let’s get started.

Developing the Project Management Plan

The first process in the Planning process group is the Develop Project Management Plan process. It’s first for good reason. This process is part of the Project Integration Management Knowledge Area and is concerned with defining, coordinating, and integrating all the various subsidiary project plans.

This process involves defining and documenting the processes you’re going to use to manage this project. For example, let’s say you and the project team have determined you will use project management processes involving costs, human resources, risks, and a project schedule. (Warning: This is a demonstration only—don’t try this at home. In reality, professionals perform many more processes than this on a typical project.) Each particular process might have a management plan that describes it. For instance, a cost management plan (an example of a subsidiary plan) would describe how costs will be managed and controlled and how changes to costs will be approved and managed throughout the project. The Develop Project Management Plan process brings all these subsidiary plans together, along with the outputs of the Planning group processes, into one document called the project management plan.

To create and document the plan, you need to gather some inputs and build on the information you’ve already collected.

Developing Inputs

The Develop Project Management Plan process has four inputs:

• Project charter
• Outputs from planning processes
• Enterprise environmental factors
• Organizational process assets

Let’s take a look at each next.

Project charter You’ll recall that the project charter describes the objectives of the project and the high-level requirements needed to satisfy stakeholder expectations. The reason it’s an input into this process is because the content of the project charter—including project objectives, project description, high-level requirements, summary milestone schedule, summary budget, and so on—will help you and the team determine exactly which project management processes to use on the project.

Outputs from Planning processes The project management processes include all the individual processes that make up the process groups we’re talking about throughout this book. The Initiating group, for example, has two processes, Planning has a zillion (OK, not that many, but it seems like it), and so on. The outputs from the Planning processes you use on the project become inputs to the Develop Project Management Plan process. For example, the cost management plan we talked about in the introduction is an input. Any processes you use that produce a baseline (such as schedule or cost) or a subsidiary management plan (such as a risk management plan, communication management plan, and so on) are included as inputs to this process.

Enterprise environmental factors You’ve seen enterprise environmental factors before. Some of the key elements of the environmental factors you should consider when choosing the processes to perform for this project include standards and regulations (both industry and governmental), company culture and organizational structure, personnel administration, and the project management information system (PMIS).

Organizational process assets Some of the key elements of the organizational process assets input you should consider when choosing the processes to perform for this project include project management plan template, change control procedures, historical information, and the configuration management knowledge database that contains the official company policies, standards, procedures, and other project documents.

The PMIS is an automated (or manual) system used to document the project management plan and subsidiary plans, to facilitate the feedback process, and to revise the documents. It incorporates the configuration management system and the change control system, both of which I’ll cover in Chapter 10, “Measuring and Controlling Project Performance.” Later in the project, the PMIS can be used to control changes to any of the plans. When you’re thinking about the PMIS as an input (that is, as part of the enterprise environmental factors), think of it as a collection and distribution point for information as well as an easy way to revise and update documents. When you’re thinking about the PMIS as a tool and technique, think of it just that way—as a tool to facilitate the automation, collection, and distribution of data and to help monitor processes such as scheduling, resource leveling, budgeting, and web interfaces.

As I talked about in Chapter 1, the processes you choose to perform for the project will be based on the complexity of the project, the project scope, and the type of industry in which you work. Your organization’s standards, guidelines, and policies or the project management office (PMO) might also dictate the types of processes you’ll use for the project. You should also consider whether your organization has existing change control processes in place, templates that you’re required to use, or financial controls and processes. Historical information and past project files are useful in helping you decide which processes to use for this project.

The only tool and technique of this project is expert judgment. According to the PMBOK® Guide, the types of expert judgment you’ll need to complete this process include the following:

• Tailoring techniques
• Understanding technical and management details that need to be included in the project management plan
• Determining resources and assessing skill levels needed for project work
• Determining and defining the amount of configuration management to apply on the project
• Determining which project documents require formal change control processes

Documenting the Project Management Plan

The purpose of most processes is, of course, to produce an output. Outputs are usually a report or document of some type or a deliverable. In this case, you end up with a document—the project management plan—that describes, integrates, and coordinates baselines and subsidiary plans for the processes you’ve determined to use for the project. The project management plan can be detailed, or it can be a high-level summary based on the needs of the project.

According to the PMBOK® Guide, the project management plan defines how the project is executed, how it’s monitored and controlled, and how it’s closed. It also documents the outputs of the Planning group processes, which I’ll cover over the next several chapters. The project management plan should include or discuss the following elements:

• Processes you’ll use to perform each phase of the project
• The life cycle you’ll use for the project and for each phase of the project if applicable
• The tailoring results the project team defines
• Methods for executing the work of the project to fulfill the objectives
• Change management plan describing methods for monitoring and controlling change
• Configuration management
• Methods for determining and maintaining the validity of performance baselines
• Communication needs of the stakeholders and techniques to fulfill those needs
• Management reviews of content, issues, and pending decisions

In addition to the elements just listed, the subsidiary plans that are associated with the processes you’ll be using for this project should be documented in the project management plan. Each of these subsidiary management plans might contain the same elements that the overall project management plan does, but they’re specifically related to the topic at hand. For example, the cost management plan should define how changes to cost estimates will be reflected in the project budget and how changes or variances with a significant impact should be communicated to the project sponsor and stakeholders. The schedule management plan describes how changes to the schedule will be managed, and so on.

The subsidiary plans might be detailed or simply a synopsis, depending on the needs of the project. I’ve listed the subsidiary plans along with a brief description next. I will cover each of these plans in more detail throughout the remainder of this book. According to the PMBOK® Guide, the subsidiary plans are as follows:

Scope management plan Describes the process for determining project scope, facilitates creating the work breakdown structure (WBS), describes how the product or service of the project is verified and accepted, and documents how changes to scope will be handled.

Requirements management plan Describes how requirements will be analyzed, documented, traced, reported, and managed throughout the project.

Schedule management plan Describes how the project schedule will be developed and controlled and how changes will be incorporated into the project schedule.

Cost management plan Describes how costs will be managed and controlled and how changes to costs will be approved and managed.

Quality management plan Describes how the organization’s quality policy will be implemented. It should address and describe quality control procedures and measures, quality assurance procedures and measures, and continuous process improvement.

Communications management plan Describes the communication needs of the stakeholders, including timing, frequency, and methods of communications.

Risk management plan Describes how risks will be managed and controlled during the project. This should include risk management methodology; roles and responsibilities; definitions of probability and impact; when risk management will be performed; and the categories of risk, risk tolerances, and reporting and tracking formats.

Procurement management plan Describes how the procurement processes will be managed throughout the project. This might include elements such as type of contract, procurement documents, and lead times for purchases.

The project management plan is not limited to the subsidiary plans listed here. You might include other plans and documentation that help describe how the project will be executed or monitored and controlled. Perhaps you’re working on a project that requires precise calculations and exact adherence to requirements. You could include a plan that describes these calculations, how they’ll be monitored and measured, and the processes you’ll use to make changes or corrections.

The project management plan also includes project baselines, such as these:

• Schedule baseline
• Cost performance baseline
• Scope baseline

I’ll talk about each of these documents in the remaining chapters as well.

As the project progresses and more and more processes are performed, the subsidiary plans and the project management plan itself might change. These changes should be reviewed, and the project management plan should be updated to reflect the approved changes. Depending on the nature of the changes, the project manager, stakeholders, or sponsor (or some combination) should review and approve the changes.

Collecting Requirements

Collect Requirements is the first process in the Project Scope Management Knowledge Area and the second process in the Planning process group. You might recall from Chapter 1 that the purpose of the Project Scope Management Knowledge Area is to describe and control what is and what is not work of the project. This is the first process where we get into the meat of the Planning processes and get down to defining what the final product or service of the project will look like—therefore, we’re starting off by defining what is included in the work of the project.

Requirements describe the characteristics of the deliverables. They might also describe functionality that a deliverable must have or specific conditions a deliverable must meet in order to satisfy the objective of the project. Requirements are typically conditions that must be met or criteria that the product or service of the project must possess in order to satisfy the objectives of the project. Requirements quantify and prioritize the wants, needs, and expectations of the project sponsor and stakeholders. According to the PMBOK® Guide and lots of personal experience, you must be able to measure, trace, and test requirements. It’s important that they’re complete and accepted by your project sponsor and key stakeholders.

The primary purpose of the Collect Requirements process is to define and document the project sponsor, the customer, and the stakeholder’s expectations and needs for meeting the project objective. In my experience, understanding, documenting, and agreeing on requirements are critical factors to project success. Recording the requirements and attaining stakeholder approval of the requirements will help you define and manage their expectations throughout the project.

You’ve already learned about the two inputs to this process, the project charter and stakeholder register, so we’ll move on to tools and techniques.

Using the Tools and Techniques of the Collect Requirements Process

Your communication skills are about to come in handy. Gathering and documenting requirements is not a task for the faint of heart. Because defining and producing requirements are so critical to the success of the project, I recommend using team members with excellent communication skills to perform this task. If they have the ability to read minds, all the better. Stakeholders almost always know what they want the end product to look like but often have difficulty articulating their needs. An expert communicator can read between the lines and ask probing questions that will draw the information out of the stakeholder.

Business process owners are those people who are experts in their particular area of the business. They are invaluable resources to the project manager and in gathering requirements for the project. They are usually the midlevel managers and line managers who still have their fingers in the day-to-day portion of the business. For example, it takes many experts in various areas to produce and market a great bottle of beer. Machinists regulate and keep the stainless steel and copper drums in top working order. Chemists check and adjust the secret formulas brewing in the vats daily. Graphic artists must develop colorful and interesting labels and ads to attract the attention of those thirsty patrons. Of course, those great TV commercials advertising the tasty brew are produced by yet another set of business experts. These are the kinds of people you’ll interview and ask to assist you in identifying requirements.

There are several tools and techniques in this process you can use to help identify the requirements of the project. Some of these tools and techniques can also be used during the Identify Risk process and the Plan Quality process. We’ll cover those processes in Chapter 6, “Risk Planning,” and Chapter 7, “Planning Project Resources,” respectively. The following tools and techniques are used for the Collect Requirements process:

Interviews Interviews are typically one-on-one conversations with stakeholders. Interviews can be formal or informal and generally consist of questions prepared ahead of time. The advantages to this tool are that subject matter experts and experienced project participants can impart a lot of information in a short amount of time and typically have a good understanding of the features and functions needed from the project deliverables. You should record the responses during the interviews and don’t be afraid to ask spontaneous questions as they occur to you during the interview.

Focus groups Focus groups are usually conducted by a trained moderator. The key to this tool lies in picking the subject matter experts and stakeholders to participate in the focus group.

Facilitated workshops Cross-functional stakeholders come together in a facilitated workshop to discuss and define requirements that affect more than one department. For example, if you’re implementing a software package that impacts several business units, you’ll need representatives from each unit together in a workshop so that all of their needs are represented and prioritized. This way, all the participants understand the various needs and have a facilitated forum to discuss and resolve their issues.

Group creativity techniques Group creativity involves several techniques, like brainstorming, the Nominal Group technique, the Delphi technique, and affinity diagrams. We will cover each of these techniques in either the Identify Risk process (Chapter 6) or the Plan Quality process (Chapter 7).

Idea/mind mapping is a group creativity technique where participants first use brainstorming techniques to record their ideas. White boards and flip charts are great tools to use with this process. The facilitator uses the white board to map ideas and, using a mind-mapping layout, group similar topics together. There are a few mind-mapping software packages available on the market that can greatly assist with this process. Mind mapping allows the participants to get an understanding of common ideas and themes, create new ideas, and understand differences.

Group decision-making techniques According to the PMBOK® Guide, there are many methods groups can use to reach decisions. These methods can also be used with the group creativity techniques. The four methods mentioned include unanimity, where everyone agrees on the resolution or course of action; majority, where more than 50 percent of the members support the resolution; plurality, where the largest subgroup within the group makes the decision if majority is not reached; and dictatorship, where one person makes the decision on behalf of the group.

Questionnaires and surveys This technique involves querying a large group of participants via questionnaires or surveys. These tools allow you to gather information quickly and apply statistical analysis, if needed, to the results.

Observations This technique is typically a one-on-one experience where an observer sits side by side with the participant to observe how the participant interacts with the product or service. This technique is also known as job shadowing. For example, you may use this technique to determine requirements for an upgrade to a software product. Sitting with the user and watching their interactions with the product enables the observer to uncover requirements they would not have ordinarily discovered. This technique can also involve participant observers who perform the job themselves in order to ascertain requirements.

Prototypes Prototyping is a technique which involves constructing a working model or mock-up of the final product with which the participants can experiment. The prototype does not usually contain all the functionality the end product does, but it gives participants enough information that they can provide feedback regarding the mock-up. This is an iterative process where participants experiment and provide feedback and the prototype is revised and the cycle starts again.

Documenting Requirements

Now that you’ve employed the tools and techniques of this process to gather requirements, you’ll want to record them in a requirements document. Stakeholders sometimes have short memories, particularly on long-term projects, so documenting requirements and obtaining their approval is essential for project success. You will use the requirements documentation throughout the project to manage stakeholder and customer expectations. This is a lot easier to accomplish when they’ve agreed to the requirements ahead of time and you have their approval documented.

I’ve already mentioned the first output of this process, which is requirements documentation. The remaining two outputs are the requirements management plan (this could be a subsidiary plan to the project management plan) and the requirements traceability matrix. I’ll describe each in detail next.

Requirements Documentation

As I mentioned in the opening to this section, requirements quantify and prioritize the wants, needs, and expectations of the project sponsor and stakeholders. Requirements typically start out high-level and are progressively elaborated as the project progresses. You must be able to track, measure, test, and trace the requirements of the project. If you can’t measure or test whether the requirement satisfies the business need of the project, the definition of success is left to the subjective opinions of the stakeholders and team members.

You’ve worked hard to gather and define requirements and you don’t want all that effort going to waste. This output involves recording the requirements in a requirements document. The PMBOK® Guide does not dictate the format of this document and acknowledges it can be formal with lots of detail or a simple list categorized by stakeholder and priority. However, it does state that the requirements document may include at least the following elements:

• Business need for the project and why it was undertaken
• Objectives of the project and the business objectives the project hopes to fulfill
• Functional requirements
• Nonfunctional requirements
• Quality requirements
• Acceptance criteria
• Business rules
• Organizational areas and outside entities impacted
• Support and training requirements
• Assumptions and constraints

One of the most important elements of the requirements document that isn’t in the preceding list is the signatures of the key stakeholders indicating their acceptance of the requirements. They will also sign the scope statement, which we’ll talk about in the section “Defining Scope” later in this chapter.

Creating the Requirements Management Plan

The requirements management plan defines how the requirements will be analyzed, documented, and managed throughout all phases of the project. The type of phase relationship you choose to manage the project will determine how requirements are managed throughout the project. For example, in a sequentially phased project, it’s possible to define requirements in later phases of the project after some work has been completed. In an overlapping phased relationship, you’ll need to define and document most of the requirements early in the life cycle.

There are several components of a sound requirements management plan. According to the PMBOK® Guide, you should include the following factors in the plan:

• How planning, tracking, and reporting of requirements activities will occur
• How changes to the requirements will be requested, tracked, and analyzed along with other configuration management activities
• How requirements will be prioritized
• What metrics will be used to trace product requirements
• What requirements attributes will be documented in the traceability matrix (the last output of this process)

Remember that the requirements management plan can be considered a subsidiary management plan and be included in the project management plan.

Documenting the Requirements Traceability Matrix

The last output of the Collect Requirements process is the requirements traceability matrix. The idea behind the traceability matrix is to document where the requirement originated, document what the requirement will be traced to, and then follow it through to delivery or completion. Table 3-1 shows a sample traceability matrix with several attributes that identify the requirement.

Table 3-1: Requirements Traceability Matrix

Each requirement should have its own unique identifier. You could devise a numbering system that defines both the category of the requirement and a unique, ascending number—for example, HR (for human resources) 001—or, a simple numbering system as shown in this example may suffice.

The description should be brief but have enough information to easily identify the requirement.

The source column refers to where the requirement originated. Requirements may come from many sources, including project objectives, business needs, product design, the work breakdown structure, deliverables, and so on.

Priority refers to the priority of the requirement. You can use any prioritization process like a simple numbering system or an alpha system as the example shows here. The definition of a “B” priority should be included in the requirements management plan. Perhaps an “A” is essential to project success and a “B” is highly desirable.

The test scenario in this example is where you record how the requirement will be tested or during which project phase, and test verification indicates if it passes or fails the test.

Status may capture information about the requirement that refers to whether the requirement has been approved to be included in the project; if it was added, deferred, canceled; and so on.

The next process in the Planning process group is the Define Scope process. Before we jump into that process, I want to talk a little about the scope management plan. We’ll look at that next.

Documenting the Scope Management Plan

The scope management plan describes how the project team will go about defining project scope, verifying the work of the project, and managing and controlling scope. The PMBOK® Guide does not go into detail regarding this plan, but there are some things you may need to know about this plan for the exam.

The project scope management plan should contain the following:

• The process you’ll use to prepare the project scope statement. The project scope statement (which I’ll define later in this chapter) contains a detailed description of the project deliverables.
• A process for creating the work breakdown structure (WBS). The WBS further defines the work of the project (as defined in the scope statement) by breaking down the deliverables into smaller pieces of work. We’ll talk about the WBS at the end of this chapter.
• A definition of how the deliverables will be verified for accuracy and the process used for accepting deliverables.
• A description of the process for controlling scope change requests, including the procedure for requesting changes and how to obtain a change request form.

Defining Scope

Scope is collectively the product, service, or result of the project. Scope can refer to product scope (the features and characteristics that describe the product, service, or result of the project) or project scope (the project management work). We’ll look at both product and project scope in this section.

Now that you’ve documented the project requirements, you’re ready to further define the needs of the project in the Define Scope process. The project scope statement (an output of this process) is what you’ll use to develop and document a detailed description of the deliverables of the project and the work needed to produce them. This process is progressively elaborated as more detail becomes known.

First, you’ll examine the inputs and tools and techniques of this process.

The inputs to the Define Scope process are as follows:

• Project charter
• Requirements documentation
• Organizational process assets

One of the important elements from the project charter that you’ll want to consider when writing the project scope statement (we’ll cover this output later) is the project objectives.

Objectives are quantifiable criteria used to measure project success. They describe “what” you’re trying to do, accomplish, or produce. Quantifiable criteria should at least include schedule, cost, and quality measures. You might use business measures or quality targets as well. These objectives will be broken down shortly into deliverables that will describe the objectives outlined in the charter.

Some of the other important information you’ll want to key in on from these inputs are historical information; the product description; and the project objectives, assumptions, and constraints. (I’ll cover each of these in the section “Writing the Project Scope Statement” later in this chapter.)

You’ll see some new tools and techniques in this process:

• Expert judgment
• Product analysis
• Alternatives identification
• Facilitated workshops

I covered expert judgment and facilitated workshops in Chapter 2. I’ll discuss product analysis and alternatives identification in the following sections.

Product Analysis

Product analysis goes hand in hand with the product scope description and, therefore, is most useful when the project’s end result is a product. Product analysis is a method for converting the product description and project objectives into deliverables and requirements. According to the PMBOK® Guide, product analysis might include performing value analysis, functional analysis, requirements analysis, systems-engineering techniques, systems analysis, product breakdown, or value-engineering techniques to further define the product or service.

Alternatives Identification

Alternatives identification is a technique used for discovering different methods or ways of accomplishing the work of the project. For example, brainstorming might be used to discover alternative ways of achieving one of the project objectives. Perhaps the project’s budget doesn’t allow for a portion of the project that the stakeholders really think needs to be included. Brainstorming might uncover an alternative that would allow the needed portion to be accomplished.

Lateral thinking is a form of alternatives identification that can be used to help define scope. Edward de Bono created this term and has done extensive research and writing on the topic of lateral thinking. The simplest definition is that it’s thinking outside the box. Lateral thinking is a process of separating the problem—or in our case the components of project scope (the deliverables and requirements)—looking at them from angles other than their obvious presentation and encouraging team members to come up with ways to solve problems or look at scope that are not apparently obvious.

Writing the Project Scope Statement

The purpose of the project scope statement is to document the project objectives, deliverables, and the work required to produce the deliverables so that it can be used to direct the project team’s work and as a basis for future project decisions. The scope statement is an agreement between the project and the project customer that states precisely what the work of the project will produce. Simply put, the scope statement tells everyone concerned with the project exactly what they’re going to get when the work is finished.

Since the scope statement serves as a baseline for the project, if questions arise or changes are proposed later in the project, they can be compared to what’s documented in the scope statement. Making change decisions is easier when the original deliverables and requirements are well documented. You’ll also know what is out of scope for the project simply because the work isn’t documented in the scope statement (or conversely, deliverables or other elements are documented and noted as being specifically out of scope). The criteria outlined in the scope statement will also be used to determine whether the project was completed successfully. I hope you’re already seeing the importance of documenting project scope.

Understanding the Scope Statement Components

According to the PMBOK® Guide, the project scope statement should include all of the following:

• Product scope description
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints
• Project assumptions

If the details surrounding these are spelled out in other documents, you don’t have to reenter all the information in the scope statement. Simply reference the other document in the scope statement so that readers know where to find it.

Product Scope Description

The product scope description describes the characteristics of the product, service, or result of the project. I talked about this in Chapter 2. If the product scope description is contained in the project charter, you can reference the project charter in the project scope statement or you can copy and paste the information from the project charter into the scope statement. It won’t hurt anything to have it in both places and will make reading the scope statement easier.

Product Acceptance Criteria

Product acceptance criteria include the process and criteria that will be used to determine whether the deliverables and the final product, service, or results of the project are acceptable and satisfactory. Product acceptance criteria help you describe project success because it defines the specifications the deliverables must meet in order to be acceptable to the stakeholder. Acceptance criteria might include any number of elements, such as quality criteria, fitness for use, and performance criteria. This component should also describe the process stakeholders will use to indicate their acceptance of the deliverables.

Project Deliverables

Deliverables are measurable outcomes, measurable results, or specific items that must be produced to consider the project or project phase completed. Deliverables should be specific and verifiable. For example, one of your deliverables might include widgets with a three-inch diameter that will in turn be assembled into the final product. This deliverable, a three-inch-diameter widget, is specific and measurable. However, if the deliverable was not documented or not communicated to the manager or vendor responsible for manufacturing the widgets, there could be a disaster waiting to happen. If they deliver two-inch widgets instead of the required three-inch version, it would throw the entire project off schedule or perhaps cause the project to fail. This could be a career-limiting move for the project manager because it’s the project manager’s responsibility to document deliverables and monitor the progress of those deliverables throughout the project. Most projects have multiple deliverables. As in this example, if you are assembling a new product with many parts, each of the parts might be considered independent deliverables.

A project deliverable is typically a unique and verifiable product or result or a service that’s performed. The product or service must be produced or performed in order to consider the project complete. The deliverables might also include supplementary outcomes such as documentation or project management reports.

The bottom line is this: no matter how well you apply your project skills, if the wrong deliverables are produced or the project is managed to the wrong objectives, you will have an unsuccessful project on your hands.

Project Exclusions

Project exclusions are, as you’d guess, anything that isn’t included as a deliverable or work of the project. You’ll want to note the project exclusions in the project scope statement so that you can continue to manage stakeholder expectations throughout the project.

Project Constraints

Constraints are anything that either restricts the actions of the project team or dictates the actions of the project team. Constraints put you in a box. (I hope you’re not claustrophobic.) As a project manager, you have to manage to the project constraints, which sometimes requires creativity.

In my organization, and I’m sure the same is true in yours, we have far more project requests than we have resources to work on them. In this case, resources are a constraint. You’ll find that a similar phenomenon occurs on individual projects as well. Almost every project you’ll encounter must work within the triple constraint combination of scope, time, and cost. The quality of the project (or the outcomes of the project) is affected by how well these three constraints are managed. Usually, one or two triple constraints apply (and sometimes all three), which restricts the actions of the project team. You might work on projects where you have an almost unlimited budget (don’t we wish!) but time is the limitation. For example, if the president mandated that NASA put an astronaut on Mars by the end of 2011, you’d have a time-constrained project on your hands.

Other projects might present the opposite scenario. You have all the time you need to complete the project, but the budget is fixed. Still other projects might incorporate two or more of the project constraints. Government agencies are notorious for starting projects that have at least two and sometimes all three constraints. For example, new tax laws are passed that impact the computer programs, requiring new programs to calculate and track the tax changes. Typically, a due date is given when the tax law takes effect, and the organization responsible is required to implement the changes with no additions to budget or staff. In other words, they are told to use existing resources to accomplish the objectives of the project, and the specific requirements, or scope, of the project are such that they cannot be changed to try to meet the time deadline.

As a project manager, one of your biggest jobs is to balance the project constraints while meeting or exceeding the expectations of your stakeholders. In most projects, you usually will have to balance only one or two of the triple constraints. For example, if one of the project objectives is to complete the project by the end of the year and stay within a certain budget, you will need to balance the other two constraints: time and cost. As the saying goes, “I can give it to you fast or I can give it to you cheap, but I can’t give it to you fast and cheap.”

Constraints can take on many forms and aren’t limited to time, cost, and scope. Anything that impedes your project team’s ability to perform the work of the project or specifically dictates the way the project should be performed is considered a constraint. Let’s say in order to fulfill some of the deliverables of your project you’ll have to purchase a large amount of materials and equipment. Procurement processes may be so cumbersome that ordering supplies for a project adds months to the project schedule. The procurement process itself becomes a constraint because of the methods and procedures you’re required to use to get the materials.

You’re likely to encounter the following constraints on your future projects:

Time constraint As I said, time can be a project constraint. This usually comes in the form of an enforced deadline, commonly known as the “make it happen now” scenario. If you are in charge of the company’s holiday bash scheduled for December 10, your project is time constrained. Once the invitations are out and the hall has been rented, you can’t move the date. All activities on this project are driven by the due date.

Budget constraints Budgets, or cost, are another element of the classic triple constraint. Budgets limit the project team’s ability to obtain resources and might potentially limit the scope of the project. For example, component X cannot be part of this project because the budget doesn’t support it.

Scope constraints Scope is the third element of the original triple constraints. Scope defines the deliverables of the project, and you may have situations where scope is predefined by your project sponsor. Alternatively, sometimes budget constraints will impact the scope of the project and require you to cut back on the deliverables originally planned.

Quality constraints Quality constraints typically are restricted by the specifications of the product or service. The specifications for those three-inch widgets talked about earlier could be considered a quality constraint. Most of the time, if quality is a constraint, one of the other constraints—time or budget—has to have some give. You can’t produce high quality on a restricted budget and within a tightly restricted time schedule. Of course, there are exceptions, but only in the movies.

Schedule constraints Schedule constraints can cause interesting dilemmas for the project manager. For example, say you’re the project manager in charge of building a new football stadium in your city. The construction of the stadium will require the use of cranes—and crane operators—at certain times during the project. If crane operators are not available when your project plan calls for them, you’ll have to make schedule adjustments so that the crane operators can come in at the right time.

Resource constraints Resources could be a constraint from a few different perspectives, including availability of key resources both internally and in the market place, skill levels, and personality. You may also have availability issues or quality problems with nonhuman resources, like materials and goods. In my experience, human resources constraints are something I deal with on every project.

Technology constraints Technology is marvelous. In fact, how did humans survive prior to the invention of computers and cell phones? However, it can also be a project constraint. For example, your project might require the use of new technology that is still so new it hasn’t been released on a wide-scale basis or hasn’t been adequately tested to determine stability in production. One impact might be that the project will take an additional six months until the new technology is ready and tested.

Directive constraints Directives from management can be constraints as well. Your department might have specific policies that management requires for the type of work you’re about to undertake. This might add time to the project, so you must consider those policies when identifying project constraints. When you’re performing work on contract, the provisions of the contract can be constraints

Constraints, particularly the classic triple constraints, can be used to help drive out the objectives and requirements of the project. If it’s difficult to discern which constraint is the primary constraint, ask the project sponsor something like this, “Ms. Sponsor, if you could have only one of these two alternatives, which would you choose? The project is delivered on the date you’ve stated, or we don’t spend one penny more than the approved budget.” If Ms. Sponsor replies with the date response, you know your primary constraint is time. If push comes to shove during the project Planning processes for this project, the budget might have to give because time cannot.

You’ll want to understand what the primary constraint is on the project. If you assume the primary constraint is budget when in actuality the primary constraint is time, in the immortal words of two-year-olds worldwide, “Uh-oh.” Understanding the constraints and which one carries the most importance will help you later in the project Planning process group with details such as scope planning, scheduling, estimating, and project plan development. That’s assuming your project gets to the project Planning processes, which brings me to the next topic: project assumptions.

Project Assumptions

You’ve probably heard the old saying about the word assume, something about what it makes out of “u” and “me.” In the case of project management, however, throw this old saying out the window, because it’s not true.

Assumptions, for the purposes of project management, are things you believe to be true. For example, if you’re working on a large construction project, you might make assumptions about the availability of materials. You might assume that concrete, lumber, drywall, and so on are widely available and reasonably priced. You might also assume that finding contract labor is either easy or difficult, depending on the economic times and the availability of labor in your locale. Each project will have its own set of assumptions, and the assumptions should be identified, documented, and updated throughout the project.

It’s essential to understand and document the assumptions you’re making, and the assumptions your stakeholders are making, about the project. It’s also important to find out as many of the assumptions as you can up front. Projects can fail, sometimes after lots of progress has been made, because an important assumption was forgotten or the assumption was incorrect. Defining new assumptions and refining old ones are forms of progressive elaboration.

Let’s say you make plans to meet your buddy for lunch at 11:30 on Friday at your favorite spot. When Friday rolls around, you assume he’s going to show up, barring any catastrophes between the office and the restaurant. Project assumptions work the same way. For planning purposes, you presume the event or thing you’ve made the assumptions about is true, real, or certain. You might assume that key resources will be available when needed on the project. Document that assumption. If Dara is the one and only resource who can perform a specific task at a certain point in the project, document your assumption that Dara will be available and run it by her manager. If Dara happens to be on a plane for Helsinki at the time you thought she was going to be working on the project, you could have a real problem on your hands.

Other assumptions could be factors, such as vendor delivery times, product availability, contractor availability, the accuracy of the project plan, the assumption that key project members will perform adequately, contract signing dates, project start dates, and project phase start dates. This is not an exhaustive list, but it should get you thinking in the right direction. As you interview your stakeholders, ask them about their assumptions and add them to your list. Use brainstorming exercises with your team and other project participants to come up with additional assumptions.

Try to validate your assumptions whenever possible. When discussing assumptions with vendors, make them put them in writing. In fact, if the services or goods you’re expecting to be delivered by your suppliers are critical to the project, include a clause in the contract to assure a contingency plan in case your suppliers fail to perform. For example, if you’re expecting 200 computers to be delivered, configured, and installed by a certain date, require the vendor to pay the cost of rental equipment in the event the vendor can’t deliver on the promised due date.

Remember, when assumptions are incorrect or not documented, it could cause problems partway through the project and might even be a project killer.

Approval Requirements

Approval requirements are not an official component of the scope statement according to the PMBOK® Guide, but I recommend that you know something about them. Approval requirements refer to how the objectives, deliverables, project management documents, and other outcomes and results of the project will be approved. This is different from product acceptance criteria—that element describes how the product itself will be approved, whereas this element describes the requirements that must be met in order to approve the deliverables. An example product-acceptance criterion might be “All widgets must measure three inches.” A deliverable approval requirement might be that the director of sales must approve a prototype before the project can proceed. This section might also contain the process and approval requirements of the project scope statement.

Approving and Publishing the Project Scope Statement

Just like the project charter, the project scope statement should be approved, agreed upon, published, and distributed to the stakeholders, key management personnel, and project team members. This isn’t an official output of this process, nor is it noted in the PMBOK® Guide. You can accomplish this with a formal sign-off procedure that’s documented as part of the approval requirements section of the scope statement. When stakeholders sign off and agree to the scope statement, they’re agreeing to the deliverables and requirements of the project. As with the project charter, their agreement and endorsement of the project requirements and deliverables will likely sustain their participation and cooperation throughout the rest of the project. That doesn’t mean they’ll agree to everything as the project progresses, but it does mean the stakeholders are informed and will likely remain active project participants.

Updating the Project Documents

The last output of this process is project document updates. Project documents encompass any document that is not a plan or a baseline, which would otherwise be included as part of the project management plan. When you’re in the midst of defining deliverables, you’ll often find that changes to the original project objectives, requirements, or stakeholder register will occur. This may require updates to the stakeholder register, the requirements documentation, and requirements traceability matrix. Changes to scope may occur later in the project. When the changes are approved, you’ll need to update the scope statement and notify stakeholders that changes have been made.

In addition to the deliverables, you want to go over the following requirements with Maria to be certain you both are in agreement:

• The location should be somewhere in the downtown area.
• Employees are encouraged to bring one guest but no children.
• There will be an open bar paid for by Maria.

• The agenda will include a speech by Maria, followed by the distribution of bonus checks to every employee. This is to be kept secret until the reception.
• The decorations should include gold-trimmed fountain pens with the company logo at every place setting for the attendees to keep.

Once you’ve documented all the particulars, you ask to speak with Maria to go over this project scope statement and get her approval before proceeding with the project.

Creating the Work Breakdown Structure

Have you ever mapped out a family tree? In the Create WBS process, you’ll construct something like it called a work breakdown structure (WBS). It maps the deliverables of the project with subdeliverables and other components stemming from each major deliverable in a tree or chart format. On page 116 of the PMBOK® Guide, the WBS is described this way: “The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables…the WBS defines the total scope of the project.” Simply put, a WBS is a deliverable-oriented hierarchy that defines and organizes the work of the project and only the work of the project. Like the scope statement, the WBS serves as a foundational agreement among the stakeholders and project team members regarding project scope.

The WBS will be used throughout many of the remaining Planning processes and is an important part of project planning. As you probably have concluded, everything you’ve done so far builds on the previous step. The project charter, requirements documentation, and project scope statement outline the project objectives, requirements, and deliverables. Now you’ll use that comprehensive list of requirements and deliverables to build the framework of the WBS.

The WBS should detail the full scope of work needed to complete the project. This breakdown will smooth the way for estimating project cost and time, scheduling resources, and determining quality controls later in the Planning processes. Project progress will be based on the estimates and measurements assigned to the WBS segments. So, again, accuracy and completeness are required when composing your WBS.

Before you begin constructing the WBS, you’ll need to gather and review some important project documents. You’ll look at those next.

Gathering the WBS Inputs

The inputs to the Create WBS process aren’t new. They are as follows:

• Project scope statement
• Requirements documentation
• Organizational process assets

The important aspect to note about the inputs to this process is that the approved project scope statement is the document you will use to define and organize the work of the project in the WBS. Make certain you’re using the most current version of the scope statement. Also note that the WBS, just like the project scope statement, contains the work of the project and only the work of the project.

Decomposing the Deliverables

The Create WBS process consists of one tool and technique called decomposition. This technique involves breaking down the deliverables into smaller, more manageable components of work. The idea here is to break down the deliverables to a point where you can easily plan, execute, monitor and control, and close out the project deliverables. Decomposition typically pertains to breaking deliverables down into smaller deliverables, or component deliverables, where each level of the WBS (or each level of decomposition) is a more detailed definition of the level above it.

This breaking-down or decomposing process will accomplish several tasks for you, one of which is improving estimates. It’s easier to estimate the costs, time, and resources needed for individual work components than it is to estimate them for a whole body of work or deliverable. Using smaller components also makes it easier to assign performance measures and controls. These give you a baseline to compare against throughout the project or phase. Finally, assigning resources and responsibility for the components of work makes better sense because several resources with different skills might be needed to complete one deliverable. Breaking them down assures that an assignment, and the responsibility for that assignment, goes to the proper parties.

According to the PMBOK® Guide, decomposition is a five-step process:

You can now plug the components you’ve identified into the WBS. This all sounds like a lot of work. I won’t kid you—it is, but it’s essential to project success. If you don’t perform the WBS process adequately and accurately, you might end up setting yourself up for a failed project at worst or for lots of project changes, delayed schedules, and increased costs at best—not to mention all those team members who’ll throw up their hands when you return to them for the third or fourth time to ask that they redo work they’ve already completed. I know you won’t let this happen, so let’s move on to constructing the WBS.

The Create WBS process has several outputs, one of which is the WBS. You’ll look at the specifics of how to create the WBS next.

Constructing the WBS

There is no “right” way to construct a WBS. In practice, the chart structure is used quite often. (This structure resembles an organization chart with different levels of detail.) But a WBS could be composed in outline form as well. The choice is yours. You’ll look at both ways shortly, along with some figures that depict the different levels of a WBS.

According to the PMBOK® Guide, you can organize the WBS in several ways:

Major deliverables and subprojects The major deliverables of the project are used as the first level of decomposition in this structure. If you’re opening a new store, for example, the deliverables might include determining location, store build-out, furnishings, product, and so on. I’ll talk about subprojects in the next section.

Subproject that may be executed outside the project team Another way to organize the work is by subprojects. Perhaps you’re expanding an existing highway and several subprojects are involved. Some of your first level of decomposition might include these subprojects: demolition, design, bridgework, and paving. Each of the subproject managers will develop a WBS for their subproject that details the work required for that deliverable. When subproject work is involved, often times the subproject work is contracted out. In this example, if you contracted out the bridgework deliverable, this subproject requires its own WBS, which the seller (the bridgework subcontractor) is responsible for creating as part of the contract and contract work.

Project phases Many projects are structured or organized by project phases. For example, let’s say you work in the construction industry. The project phases used in your industry might include project initiation, planning, designing, building, inspection, and turnover. A feasibility study might be a deliverable under the project initiation phase, blueprints might be a deliverable under the planning phase, and so on. Each phase listed here would be the first level of decomposition (that is, the first level of the WBS); their deliverables would be the next level, and so on.

We’ll take a look at some example WBS structures next.

Understanding the Various WBS Levels

Although the project manager is free to determine the number of levels in the WBS based on the complexity of the project, all WBS structures start with the project itself. Some WBS structures show the project as level one. Others show the level under the project, or the first level of decomposition, as level one. The PMBOK® Guide notes that level one is the project level, so I’ll follow that example here.

The first level of decomposition might be the deliverables, phases, or subprojects, as I talked about earlier. (Remember that the first level of decomposition is actually the second level of the WBS because the project level is the first level.) The levels that follow show more and more detail and might include more deliverables followed by requirements. Each of these breakouts is called a level in the WBS. The lowest level of any WBS is called the work package level. (I’ll talk more about this in “Defining Work Packages” later in this chapter.) The goal is to construct the WBS to the work package level where you can easily and reliably estimate cost and schedule dates. Keep in mind that some projects or deliverables may need only one or two levels of decomposition.

The easiest way to describe the steps for creating a WBS is with an example. Let’s suppose you work for a software company that publishes children’s games. You’re the project manager for the new Billy Bob’s Bassoon game, which teaches children about music, musical rhythm, and beginning sight reading. The first box on the WBS is the project name; it appears at the top of the WBS, as shown in Figure 3-1, and is defined as WBS Level One.

The next level is the first level of decomposition and should describe the major deliverables for the project. In this example, some of the deliverables might be requirements definition, design specifications, and programming. This isn’t an exhaustive list of deliverables; in practice, you would go on to place all of your major deliverables into the WBS as level-one content. For illustration purposes, just look at a slice of the WBS for this project. Refer to Figure 3-1 to see the WBS with level-one and level-two detail added.

Level-three content might be the component deliverables that are further broken out from the major deliverables of level two, or it might be the products or results that contribute to the deliverable. The Billy Bob’s Bassoon example shows further deliverables as level-three content. See Figure 3-2 for an illustration of the WBS so far.

The goal here is to eventually break the work out to the point where the responsibility and accountability for each work package can be assigned to an organizational unit or a team of people. In Figure 3-3, I’ve decomposed this WBS to the fourth level to show an even finer level of deliverable detail. Remember that activities are not usually included in the WBS. An easy way to differentiate between deliverables and activities is to use nouns as the deliverable descriptors and verbs as activity descriptors (we’ll talk about activities in Chapter 4). Reaching way back to my grade-school English, I recall that a noun is a person, place, or thing. In this example, the deliverables are described using nouns. When we get to the activity list, you might use verbs like define, design, and determine to describe them.

You can see from these illustrations how a poorly defined scope or inadequate list of deliverables will lead to a poorly constructed WBS. Not only will this make the WBS look sickly, but the project itself will suffer and might even succumb to the dreaded premature project demise. The final cost of the project will be higher than estimated, and lots of rework (translation: late nights and weekends) will be needed to account for the missing work not listed on the WBS. You can construct a good WBS and maintain a healthy project by taking the time to document all the deliverables during the Define Scope process.

Don’t get too carried away when creating a WBS. The object is to define the work of the project so you can easily plan, manage, monitor, and control the work. But, you don’t want to take this too far. If you decompose the work to the point that you’re showing every minute detail, you’ve ventured into inefficiency and will find it more difficult to plan and manage. In addition, you’re potentially stifling the creativity of the people working on the project because everything is so narrowly defined.

Sometimes, particularly when working on large projects that consist of several subprojects, some of the subprojects might not be scheduled until a future date. Obviously, it makes sense to develop the WBS in detail at that future date when the deliverables and subprojects are better known and more details are available. This technique is called rolling wave planning. The idea behind this technique is that you elaborate the work of the project to the level of detail you know about at the time. If a subproject or deliverable is scheduled sometime in the future, the only component that might appear on the WBS today is the subproject itself. As you get closer to the subproject, you’ll elaborate the details of the subproject and record them on the WBS.

Understanding the Unique WBS Identifiers

Each element at each level of the WBS is generally assigned a unique identifier according to the PMBOK® Guide. This unique identifier is typically a number, and it’s used to sum and track the costs, schedule, and resources associated with the WBS elements. These numbers are usually associated with the corporation’s chart of accounts, which is used to track costs by category. Collectively, these numeric identifiers are known as the code of accounts. The unique identifiers for the requirements definition branch of the WBS might look something like this:

10-1 Billy Bob’s Bassoon

10-2 Requirements Definition

10-3 Game Requirements

10-3-1 Character Definition

10-3-2 Instruments Design

10-4 Software Requirements

10-4-1 Platform

10-4-2 System Description

Defining Work Packages

Work packages are the components that can be easily assigned to one person, or a team of people, with clear accountability and responsibility for completing the assignment. Assignments are easily made at the work package level; however, assignments can be made at any level in the WBS. The work package level is where time estimates, cost estimates, and resource estimates are determined.

Work package levels on large projects can represent subprojects that are further decomposed into their own work breakdown structures. They might also consist of project work that will be completed by a vendor, another organization, or another department in your organization. If you’re giving project work to another department in your organization, you’ll assign the work packages to individual managers, who will in turn break them down into activities during the Activity Definition process later in the Planning process group.

Work packages might be assigned to vendors or others external to the organization. For example, perhaps one of the deliverables in your project is special packaging and a vendor is responsible for completing this work. The vendor will likely treat this deliverable as a project within its own organization and construct its own WBS with several levels of decomposition. However, for your project, it’s a deliverable listed at the work package level of the WBS.

Creating WBS Process Outputs

The Create WBS process has four outputs:

• Work breakdown structure
• WBS dictionary
• Scope baseline
• Project document updates

I’ve covered the WBS in detail already. Updates to the scope statement and project document updates might come about as a result of changes that occur when you’re creating the WBS. You can see from the examples you’ve walked through in this chapter how new deliverables or requirements might surface as a result of working on the WBS. These requested changes should be reviewed and either approved or denied using your change control processes. (I’ll talk about that in Chapter 10.) The approved changes should be noted in the project scope statement, and the project management plan and other project documents should be updated to reflect the new approved project scope statement.

WBS Dictionary

The WBS dictionary is where work component descriptions are documented. According to the PMBOK® Guide, the WBS dictionary should include the following elements for each component of the WBS:

• Code of accounts identifier
• Description of the work of the component
• Organization responsible for completing the component
• List of schedule milestones
• Schedule activities associated with the schedule milestones
• Required resources
• Cost estimates
• Quality requirements
• Criteria for acceptance
• Technical references
• Contract information

Let’s look at an example of what some of the elements of a WBS dictionary entry might look like. You’ll use the work package level called Inspection and Identification defined in the sidebar “The Lincoln Street Office Building” earlier. The WBS dictionary entry for this might look like the following:

3.1 Inspection and Identification

Description of work: Inspect the building for asbestos, and identify all areas where it’s found. Update the plan for removal (WBS 2.2) with each location identified.

Responsible organization: Adrian in Facilities will hire and oversee a contractor to perform this work.

Schedule milestones: Inspection and identification to start after contractor is identified and hired (no later than July 1). Work should be completed no later than September 15.

Contract information: Two contractors have been identified as qualified and experienced in this type of work. Contract process should close no later than June 12.

Scope Baseline

Remember how I said that everything you’ve done so far has built upon itself? This is an important concept you should know for this output. The scope baseline for the project is the approved project scope statement, the WBS, and the WBS dictionary. (You’ll recall from Chapter 2 that the project scope statement serves as a baseline for future project decisions because it helps the team determine whether requested changes are inside or outside of scope.) In other words, these documents together describe in detail all the work of the project. From these documents, you’ll document schedules, assign resources, and monitor and control the work of the project according to what’s described here.

If the WBS is constructed well, you’ve given yourself a huge helping hand with the remaining Planning processes. The completion of many of the remaining processes depends on the project scope statement and WBS being accurate and complete. In Chapter 4, for example, you’ll use the work packages created here to further elaborate the work into activities. From there, you can estimate costs, develop schedules, and so on. The WBS is an essential tool for project planning, so keep it handy.

Approved changes might also impact the project scope management plan or some of the subsidiary plans that make up this plan. Make certain you update this plan as a result of the changes made during the Define Scope process.

Understanding How This Applies to Your Next Project

In this chapter, you dealt with the realities of life on the job. The reality is, many project managers I know are managing several projects at once as opposed to one large project. Although every concept presented in this chapter is a sound one, it’s important to note that you have to balance the amount of effort you’ll put into project management processes against the size and complexity of the project.

As a manager who prides herself and my team on excellent customer service, I have once or twice gotten my team into precarious situations because I was so focused on helping the customer that I hurt them and our department in the process. If you’re wondering how that happened, it was because we didn’t take the time to document the scope of the project and the final acceptance criteria. In one case, in the interest of getting the project completed quickly because of our customer’s own internal deadlines, we decided the project was straightforward enough that we didn’t need to document deliverables. The customer promised to work side by side with us as we produced the work of the project. Unfortunately, that wasn’t the case, and we didn’t meet the expectations of our customer. Further, after we did implement the project (two months behind schedule), we went through another six weeks of “fixes” because of the miscommunication between the customer and the project team on what constituted some of the features of the final product. There’s always a great reason for cutting corners—but they almost always come back to haunt you. My advice is to always create a scope statement and a requirements list and get stakeholder signatures on both. (In practice, small projects can include both the deliverables and requirements within the scope statement.)

Decomposing the deliverables is the first step toward determining resource requirements and estimates. A WBS is always a good idea, no matter the size of the project. I have to admit I have cheated a time or two on small projects and used the project schedule as the WBS. In all fairness, that worked out fine when the team was small and there weren’t more than three or four people working on the project. If you get many more than four people on the project team, it can be a little cumbersome to track deliverables with a schedule only. The WBS is the perfect tool to use to assign names to work packages, and it’s the foundation for determining estimates for the work of the project.

The five-step process outlined by the PMBOK® Guide works very well. Starting with the 50,000-foot view, the team determines the major deliverables of the project. From there, the deliverables are decomposed into ever smaller units of work. The trick here is to break the work down into measurable units so that you can verify the status of the work and the completion and acceptance of the work when you’re finished. If you have “fuzzy” WBS levels or work packages, you won’t be able to determine status accurately. In the information technology field, we have a saying about the status of projects: “It’s 90 percent complete.” The problem is it always seems that the last 10 percent takes twice as long to complete as the first 90 did. If you’ve taken the time to document a WBS, you’ll have a much better idea of what that 90 percent constitutes. The last step is the verification step where you determine whether everything you’ve identified in the WBS is absolutely necessary to fulfill the work of the project and whether it’s decomposed enough to adequately describe the work. It has been my experience that documenting the WBS will save you time later in the Planning processes, particularly developing the project schedule and determining the project budget.

I believe the most important idea to take from this chapter is a simple one: always use a scope statement and requirements list, and always get them signed.

Summary

This chapter started you on the road to project planning via the Develop Project Management Plan process, the Collect Requirements process, the Define Scope process, and the Create WBS process. We covered a lot of material in this chapter. Everything you’ve learned so far becomes the foundation for further project planning.

The output of the Develop Project Management Plan process is the project management plan, which is concerned with defining, coordinating, and integrating all the ancillary project plans and baselines. The purpose of this plan is to define how the project is executed, how it’s monitored and controlled, and how it’s closed.

The Collect Requirements process involves gathering and documenting the requirements of the project. It’s important that requirements be measurable, traceable, testable, and so on. Measurement criteria for project requirements are agreed upon by the stakeholders and project manager. Additionally, requirements should be tracked in a traceability matrix that documents where they originated, the results of the tests, the priority of the requirement and more.

The scope statement is produced during the Define Scope process. It describes the project deliverables. The scope statement forms a baseline you’ll use to weigh future project decisions, most particularly change requests. The scope statement contains a list of project deliverables that will be used in future Planning processes.

The project scope statement contains many elements, including product scope description, product acceptance criteria, deliverables, exclusions from scope, constraints, and assumptions.

Constraints restrict or dictate the actions of the project team. Constraints usually involve time, cost, and scope but can also include schedules, technology, quality, resources, risk, and more.

Assumptions are things believed to be true. You’ll want to document project assumptions and validate them as the project progresses.

A WBS is a deliverable-oriented group of project essentials. The highest levels of the WBS are described using nouns, and the lowest levels are described with verbs. Each element in the WBS has its own set of objectives and deliverables that must be met in order to fulfill the deliverables of the next highest level and ultimately the project itself. In this way, the WBS validates the completeness of the work.

The lowest level of the WBS is known as the work package level. This breakdown allows the project manager to determine cost estimates, time estimates, resource assignments, and quality controls.

Exam Essentials

Be able to state the purpose of the Develop Project Management Plan process. It defines, coordinates, and integrates all subsidiary project plans.

Understand the purpose of the project scope statement. The scope statement serves as a common understanding of project scope among the stakeholders. The project objectives and deliverables and their quantifiable criteria are documented in the scope statement and are used by the project manager and the stakeholders to determine whether the project was completed successfully. It also serves as a basis for future project decisions.

Be able to define project constraints and assumptions. Project constraints limit the options of the project team and restrict their actions. Sometimes constraints dictate actions. Time, budget, and cost are the most common constraints. Assumptions are conditions that are presumed to be true or real.

Be able to describe the purpose of the scope management plan. The scope management plan has a direct influence on the project’s success and describes the process for determining project scope, facilitates creating the WBS, describes how the product or service of the project is verified and accepted, and documents how changes to scope will be handled. The scope management plan is a subsidiary plan of the project management plan.

Be able to define a WBS and its components. The WBS is a deliverable-oriented hierarchy. It uses the deliverables from the project scope statement or similar documents and decomposes them into logical, manageable units of work. The first level of decomposition is the major deliverable level or subproject level, while the second level of decomposition is a further elaboration of the deliverables, and so on. The lowest level of any WBS is called a work package.

Key Terms

Planning, planning, planning… I can’t stress enough how important the planning processes are to a successful project. In this chapter, you learned about the processes involved in developing your project scope statement. Understand these processes well, and know them by the names used in the PMBOK® Guide:

Develop Project Management Plan

Collect Requirements

Define Scope

Create WBS

Before you take the exam, also be certain you are familiar with the following terms:

acceptance criteria	project management information system (PMIS)
alternatives identification	project management plan
approval requirements	project scope management plan
assumptions	project scope statement
code of accounts	requirements
constraints	rolling wave planning
critical success factors	scope
deliverables	WBS dictionary
product analysis	work package
project boundaries

Review Questions

1. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You are getting ready to write the project management plan and know that all the following are true regarding the PMIS except for one. Which of the following is not true?

A. The PMIS is a tool and technique of this process.

B. The configuration management system is a subsystem of the PMIS.

C. The PMIS includes a change control system.

D. The PMIS is an automated system.

2. Which of the following is true?

A. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, controlled, and closed. You are working on the project scope management plan.

B. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, controlled, and closed. You are working on the product scope statement.

C. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed and controlled and how changes will be monitored and controlled. You are working on the project management plan.

D. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, controlled, and closed. You are working on the project scope statement.

3. You are a project manager responsible for the construction of a new office complex. You are taking over for a project manager who recently left the company. The prior project manager completed the scope statement and scope management plan for this project. In your interviews with some key team members, you conclude which of the following?

A. They understand that the scope statement assesses the stability of the project scope and outlines how scope will be verified and used to control changes. They also know that project scope is measured against the product requirements.

B. They understand that the scope management plan describes how project scope will be managed and controlled and how the WBS will be created and defined. They also know that product scope is measured against the product requirements.

C. They understand that the scope management plan is deliverables oriented and includes cost estimates and stakeholder needs and expectations. They understand that project scope is measured against the project management plan.

D. They understand that the scope statement describes how the high-level deliverables and requirements will be defined and verified. They understand that product scope is measured against the project management plan.

4. Unanimity, majority, plurality, and dictatorship are four examples of which of the following techniques?

A. Group creativity techniques, which is a tool and technique of the Collect Requirements process

B. Interviews, which is a tool and technique of the Define Scope process

C. Facilitated workshops technique, which is a tool and technique of the Define Scope process

D. Group decision-making techniques, which is a tool and technique of the Collect Requirements process

5. Which of the following is true regarding the project scope statement?

A. The project scope statement includes a change control system that describes how to make changes to the project scope.

B. The project scope statement further elaborates the details from the Initiating and Planning processes and serves as a basis for future project decisions.

C. The project scope statement describes how the team will define and develop the work breakdown structure.

D. The project scope statement assesses the reliability of the project scope and describes the process for verifying and accepting completed deliverables.

6. You are a project manager for an agricultural supply company. You have interviewed stakeholders and gathered requirements. Which of the following is true regarding the process to which this question refers?

A. The requirements document lists the requirements and describes how they will be analyzed, documented, and managed throughout the project.

B. Requirements documentation consist of formal, complex documents that include elements such as the business need of the project, functional requirements, nonfunctional requirements, impacts to others inside and outside the organization, and requirements assumptions and constraints.

C. The requirements documentation details the work required to create the deliverables of the project, including deliverables description, product acceptance criteria, exclusions from requirements, and requirements assumptions and constraints.

D. The requirements traceability matrix ties requirements to project objectives, business needs, WBS deliverables, product design, test strategies, and high-level requirements and traces them through to project completion.

7. Which of the following makes up the project scope baseline?

A. The approved project scope statement

B. The approved scope management plan and WBS

C. The WBS, approved project scope statement, and WBS dictionary

D. The approved scope management plan, the WBS, and the WBS dictionary

8. Which of the following statements is true regarding brainstorming and lateral thinking?

A. They are forms of expert judgment used to help define and develop requirements and develop the project scope statement.

B. They are tools and techniques used to elaborate the product scope description.

C. They are group decision-making techniques, which are a tool and technique of the Collect Requirements process.

D. They are alternatives identification techniques, which are a tool and technique of the Define Scope process.

9. Your company, Kick That Ball Sports, has appointed you project manager for its new Cricket product line introduction. This is a national effort, and all the retail stores across the country need to have the new products on the shelves before the media advertising blitz begins. The product line involves three new products, two of which will be introduced together and a third one that will follow within two years. You are ready to create the WBS. All of the following are true except for which one?

A. The WBS can be structured using each product as a level-one entry.

B. The WBS should be elaborated to a level where costs and schedule are easily estimated. This is known as the work package level.

C. Rolling wave refers to how all levels of the WBS collectively roll up to reflect the work of the project and only the work of the project.

D. Each level of the WBS represents verifiable products or results.

10. You are a project manager for Giraffe Enterprises. You’ve recently taken over for a project manager who lied about his PMI certification and was subsequently fired. Unfortunately, he did a poor job of defining the scope. Which of the following could happen if you don’t correct this?

A. The stakeholders will require overtime from the project team to keep the project on schedule.

B. The poor scope definition will adversely affect the creation of the work breakdown structure, and costs will increase.

C. The project management plan’s process for verification and acceptance of the deliverables needs to be updated as a result of the poor scope definition.

D. The project costs could increase, there might be rework, and schedule delays might result.

11. You are the project manager for Lucky Stars nightclubs. They specialize in live country and western band performances. Your newest project is in the Planning processes group. You are working on the WBS. The finance manager has given you a numbering system to assign to the WBS. Which of the following is true?

A. The numbering system is a unique identifier known as the WBS dictionary, which is used to assign quality control codes to the individual work elements.

B. The numbering system is a unique identifier known as the WBS dictionary, which is used to track the descriptions of individual work elements.

C. The numbering system is a unique identifier known as the code of accounts, which is used to track time and resource assignments for individual work elements.

D. The numbering system is a unique identifier known as the code of accounts, which is used to track the costs of the WBS elements.

12. You’ve constructed the WBS for your recent project. You’ve requested that the subproject managers report to you in three weeks with each of their individual WBSs constructed. Which statement is not true regarding the subproject managers’ WBSs?

A. The work package level is decomposed to create the activity list.

B. The work package level is the lowest level in the WBS.

C. The work package level facilitates resource assignments.

D. The work package level facilitates cost and time estimates.

13. You are a project manager working on a new software product your company plans to market to businesses. The project sponsor told you that the project must be completed by September 1. The company plans to demo the new software product at a trade show in late September and, therefore, needs the project completed in time for the trade show. However, the sponsor has also told you that the budget is fixed at $85,000, and it would take an act of Congress to get it increased. You must complete the project within the given time frame and budget. Which of the following is the primary constraint for this project?

A. Budget

B. Scope

C. Time

D. Quality

14. Which of the following statements about decomposition is the least true?

A. Decomposition involves structuring and organizing the WBS so that deliverables are always listed at level one.

B. Decomposition requires a degree of expert judgment and also requires close analysis of the project scope statement.

C. Decomposition is a tool and technique used to create a WBS.

D. Decomposition subdivides the major deliverables into smaller components until the work package level is reached.

15. You are in the process of translating project objectives into tangible deliverables and requirements. All of the following are techniques used in the product analysis tool and technique of the Define Scope process except for which one?

A. Value engineering and value analysis

B. Product configuration and specification analysis

C. Systems analysis and systems engineering

D. Product breakdown and functional analysis

16. You are a project manager for a documentary film company. In light of a recent regional tragedy, the company president wants to produce a new documentary on the efforts of the heroic rescue teams to air as soon as possible. She’s looking to you to make this documentary the best that has ever been produced in the history of this company. She guarantees you free rein to use whatever resources you need to get this project done quickly. However, the best photographer in the company is currently working on another assignment. Which of the following is true?

A. The primary constraint is time because the president wants the film done quickly. She told you to get it to air as soon as possible.

B. Resources are the primary constraint. Even though the president has given you free rein on resource use, you assume she didn’t mean those actively assigned to projects.

C. The schedule is the primary constraint. Even though the president has given you free rein on resource use, you assume she didn’t mean those actively assigned to projects. The photographer won’t be finished for another three weeks on his current assignment, so schedule adjustments will have to be made.

D. The primary constraint is quality because the president wants this to be the best film ever produced by this company. She’s given you free rein to use whatever resources needed to get the job done.

17. Your project depends on a key deliverable from a vendor you’ve used several times before with great success. You’re counting on the delivery to arrive on June 1. This is an example of a/an ___________________ .

A. Constraint

B. Objective

C. Assumption

D. Requirement

18. What limits the options of the project team?

A. Technology

B. Constraints

C. Deliverables

D. Assumptions

19. Your company provides answering services for several major catalog retailers. The number of calls coming into the service center per month has continued to increase over the past 18 months. The phone system is approaching the maximum load limits and needs to be upgraded. You’ve been assigned to head up the upgrade project. Based on the company’s experience with the vendor who worked on the last phone upgrade project, you’re confident they’ll be able to assist you with this project as well. Which of the following is true?

A. You’ve made an assumption about vendor availability and expertise. The project came about because of a business need.

B. Vendor availability and expertise are constraints. The project came about because of a business need.

C. You’ve made an assumption about vendor availability and expertise. The project came about because of a market demand.

D. Vendor availability and expertise are constraints. The project came about because of a market demand.

20. Which of the following is not a major step of decomposition?

A. Identify major deliverables.

B. Identify resources.

C. Identify components.

D. Verify correctness of decomposition.

Answers to Review Questions

1. A. The PMIS is one of the elements of the enterprise environmental factors, which is an input to the Develop Project Management Plan process.

2. C. The project management plan describes the processes you’ll use to perform the project and describes how the project will be executed, monitored, controlled and how the work of the project will be executed to meet the objectives.

3. B. The scope management plan describes how project scope will be defined and verified, how the scope statement will be developed, how the WBS will be created and defined, and how project scope will be managed and controlled. Project scope is measured against the project management plan, whereas product scope is measured against the product requirements.

4. D. These four decision-making techniques belong to the Collect Requirements process and are part of the group decision-making tool and technique in this process.

5. B. The scope statement further elaborates the project deliverables and documents the constraints and assumptions for the project. It serves as a basis for future project decisions.

6. D. The requirements traceability matrix links requirements to their origin and traces them throughout the project. Option A describes the requirements management plan, not the requirements document. Option B is partially true with the exception of the first statement. Requirements documents do not have to be formal or complex. Option C refers to the project scope statement, not the requirements.

7. C. The scope baseline consists of the approved project scope statement, the WBS, and the WBS dictionary.

8. D. Alternatives identification is a tool and technique of the Define Scope process that includes brainstorming and lateral thinking techniques.

9. C. Each of the three products might have different amounts of elaboration and levels. The question said the third product would not be introduced until two years after the first two. This WBS entry might contain only one level stating the product name.

10. D. Option A might seem like a correct answer, but option D is more correct. There isn’t enough information to determine whether stakeholders will require overtime. We do know that poor scope definition might lead to cost increases, rework, schedule delays, and poor morale.

11. D. Each element in the WBS is assigned a unique identifier. These are collectively known as the code of accounts. Typically, these codes are associated with a corporate chart of accounts and are used to track the costs of the individual work elements in the WBS.

12. A. The work package level is the lowest level in the WBS and facilitates resource assignment and cost and time estimates. The agreed-upon deliverables in C would appear in the higher levels in the WBS.

13. C. The primary constraint is time. Since the trade show demos depend on project completion and the trade show is in late September, the date cannot be moved. The budget is the secondary constraint in this example.

14. A. Decomposition subdivides the major deliverables into smaller components. It is a tool and technique of the Create WBS process and is used to create a WBS. Level-two components might be deliverables, phases, subprojects, or some combination.

15. B. Product analysis includes techniques such as value engineering, value analysis, systems analysis, systems engineering, product breakdown, and functional analysis.

16. D. The primary constraint is quality. If you made the assumption as stated in B, you assumed incorrectly. Clarify these assumptions with your stakeholders and project sponsors. This applies to C as well.

17. C. This is an example of an assumption. You’ve used this vendor before and haven’t had any problems. You’re assuming there will be no problems with this delivery based on your past experience.

18. B. Constraints restrict the actions of the project team.

19. A. The project came about because of a business need. The phones have to be answered because that’s the core business. Upgrading the system to handle more volume is a business need. An assumption has been made regarding vendor availability. Always validate your assumptions.

20. B. The steps of decomposition include identify major deliverables, organize and determine the structure, identify lower-level components, assign identification codes, and verify correctness of decomposition.