Discussion

PMP_Project_Management_Professional_Exam_Study_Gui..._----_Pg_155--208.pdf

Home >Business & Finance homework help >Accounting homework help >Discussion

Chapter

3 Developing the Project Scope Statement

The PMP® exaM conTenT froM The Planning PerforMance doMain covered in This chaPTer includes The following:

✓ Task 1: review and assess detailed project requirements, constraints, and assumptions with stakeholders based on the project charter, lessons learned, and by using requirement gathering techniques in order to establish the project deliverables.

✓ Task 2: develop a scope management plan, based on the approved project scope and using scope management techniques, in order to define, maintain, and manage the scope of the project.

✓ Task 9: develop the change management plan by defining how changes will be addressed and controlled in order to track and manage change.

✓ Task 12: conduct kick‐off meeting, communicating the start of the project, key milestones, and other relevant information in order to inform and engage stakeholders and gain commitment.

✓ Knowledge and skills:

■ Requirements gathering techniques (e.g., planning sessions,

brainstorming, and focus groups)

■ Estimation tools and techniques

■ Scope deconstruction (e.g., WBS, Scope Backlog) tools and

techniques

■ Scope management planning

Heldman, Kim. PMP: Project Management Professional Exam Study Guide : Updated for the 2015 Exam, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/gcu/detail.action?docID=4185201. Created from gcu on 2025-05-12 02:12:48.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Great job! You’ve successfully completed the project Initiating processes and published the project charter and the stakeholder register. The project is officially under way.

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 Plan Scope Management process. Here we will examine documenting a plan that outlines how to define, validate, and control the project scope.

The Collect Requirements process is next. During this process, quantified requirements are gathered and documented to assure that 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.

The process names, inputs, tools and techniques, outputs, and descriptions of the project management process groups and related materials and figures in this chapter are based on content from A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition (PMI, 2013).

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 99

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 reasons. This process is part of the Project Integration Management Knowledge Area and is concerned with defining, preparing, coordinating, and then integrating all the various subsidiary project plans into an overall project management plan.

If you haven’t already done so, make certain to conduct a project kick‐off meeting with the stakeholders and project team members. Before beginning the processes we’ll discuss in this chapter, you need stakeholder buy‐in and commitment to the project in order to successfully document requirements, key milestones, and deliverables.

Exam Spotlight

The PMI® Project Management Professional (PMP®) Examination Content Outline documents the official project kick‐off meeting in the Planning process group. In reality, many of you, myself included, may perform this step during the Initiating process, but remember for the exam that it occurs in the Planning process group.

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.

In Chapter 1, “What Is a Project?,” I talked about tailoring—determining which processes within each process group are appropriate for the project on which you’re working. Tailoring is used in the Develop Project Management Plan process because it’s here you’ll determine what processes to use to best manage the project.

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

100 Chapter 3 ■ Developing the Project Scope Statement

developing inputs The Develop Project Management Plan process has four inputs:

■ Project charter

■ Outputs from other 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. 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 Other 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 (okay, not that many, but it seems like it), and so on. The outputs from other 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.

I’ll talk more about baselines and the makeup of individual subsidiary management plans as we discuss the various Planning processes, starting with this chapter and continuing through Chapter 7.

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, infrastructure, and the project management information system (PMIS).

Organizational Process Assets Some of the critical 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, performance measurement criteria, historical information, and the configuration management

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 101

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.

Exam Spotlight

The PMIS in the Develop Project Management Plan process includes a subsystem called the configuration management system, and the change control system is a subsystem of the configuration management system.

The two tools and techniques of this process are expert judgment and facilitation techniques. We looked at facilitation techniques in Chapter 2, “Creating the Project Charter.” According to the PMBOK® Guide, you’ll need the following types of expert judgment to complete this process:

■ 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

102 Chapter 3 ■ Developing the Project Scope Statement

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 how it’s controlled. It is progressively elaborated over the life of the project. 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 and their level of implementation, the tools and techniques you’ll use from these processes, and the interactions and dependencies among the processes. All this was determined as part of the tailoring exercise we talked about in Chapter 2.

■ The life cycle you’ll use for the project and for each phase of the project if applicable.

■ Methods for executing the work of the project to fulfill the objectives.

■ Change management plan describing methods for monitoring and controlling change.

■ Configuration management plan.

■ 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 these elements, 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 defining, maintaining, and managing project scope, facilitates creating the work breakdown structure (WBS), describes how the product or service of the project is validated and accepted, and documents how changes to scope will be handled.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 103

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.

Process Improvement Plan Focuses on finding inefficiencies in a process or activity and eliminating them.

Human Resource Management Plan Documents the roles and responsibilities for project team members, their reporting relationships, and how the team will be managed.

Stakeholder Management Plan Documents what strategies to use to encourage stakeholder participation, documents the analysis of their needs and interests and impacts, and documents the process regarding project decision making.

The project management plan is not limited to the subsidiary plans listed here. For example, even though the PMBOK® Guide does not mention the change management plan in the list of subsidiary plans, you should develop and include a change management plan with your project management plan. The change management plan describes how you will document, address, track, and control changes. 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 baseline

■ Scope baseline

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

104 Chapter 3 ■ Developing the Project Scope Statement

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

Exam Spotlight

Understand that the purpose of the project management plan is to define how the project is executed, monitored and controlled, and closed as well as to document the processes you’ll use during the project.

As the project progresses and more and more processes are performed, the subsidiary plans and the project management plan itself might change. You will manage these changes using the Perform Integrated Change Control process. All changes should be reviewed following the processes outlined in the change control plan, and the project management plan should be updated to reflect the approved changes.

Exam Spotlight

In practice, you’ll find that you’ll prepare the project management plan after you’ve progressed through several of the other Planning processes. It’s difficult to finalize some of these subsidiary plans without thinking through or sometimes performing the process they’re associated with first. However, for the exam, remember that Develop Project Management Plan is the first process in the Planning group, and it should be performed first. Updates can and should occur to the project management plan as subsidiary plans are created or changed.

Plan Scope Management Plan Scope Management is the first process in the Project Scope Management Knowledge Area. 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. Scope is collectively the product, service, or result of the project and the deliverables the project intends to produce.

The primary purpose of this process is twofold: to write the scope management plan and to develop the requirements management plan. The scope management plan is a planning tool that documents how the project team will go about defining project scope, how changes to scope will be maintained and controlled, and how project scope will be verified. The requirements management plan addresses analyzing, documenting, and managing the project requirements. I’ll cover the requirements management plan in detail in the section “Documenting the Scope Management Plan” later in this chapter.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Plan Scope Management 105

Exam Spotlight

According to the PMI® Project Management Professional (PMP®) Examination Content Outline, the activities and processes in the Planning process group involve defining, assessing, and reviewing detailed project requirements based on the project charter in order to establish the project deliverables. You will perform these processes with your stakeholders using requirements gathering techniques. Reviewing lessons learned from previous projects of similar size and scope and reviewing the constraints and assumptions of this project are all keys to documenting a detailed list of project deliverables.

For now you’ll concentrate on the inputs to this process, which will help you get started documenting the decisions about the Plan Scope Management process for your project.

understanding the Plan scope Management inputs You’ve seen the inputs to the Plan Scope Management process before. They are as follows:

■ Project management plan

■ Project charter

■ Enterprise environmental factors

■ Organizational process assets

Even though I’ve talked about these before, you’ll want to look at specific elements of some of these inputs closely. Defining project scope, and managing that scope as you progress through the project, has a direct relationship to the success of the project. It’s difficult to document how you’ll define project scope if you don’t first understand the purpose behind the project; the product, service, or result you’re trying to produce; and the environmental factors and organizational process assets under which you’re working. The process of how you’ll go about defining and managing scope is what the scope management plan (which is what you’re ultimately getting to with this process) is about.

The project charter describes the purpose and high‐level requirements of the project. Analyzing the information in this document will help you determine the appropriate tools and methodologies to use (as well as which processes to perform) for the project. The idea here is that you want to understand the size and complexity of the project so that you don’t spend more time than needed documenting how you’re going to go about defining and managing scope.

One of the environmental factors that might influence the way scope is managed is personnel administration, or more specifically, the human resources involved on the project. Their skills, knowledge, and abilities to communicate and escalate issues appropriately might influence the way project scope is managed. Personnel policies governing those resources might also have an effect. For example, you might have a team member who has a close relationship with one of the stakeholders. Let’s say the stakeholder

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

106 Chapter 3 ■ Developing the Project Scope Statement

wants a change to the project. The stakeholder and team member grab a cup of coffee together at the corner deli, and the next thing you know, the team member is incorporating the change into the project. Scope can’t be managed efficiently when it’s being changed without the knowledge of the project manager or project team.

Other environmental factors that might affect scope management are the organization’s culture, economic conditions, market conditions, and physical and technological infrastructure.

Organizational process assets typically include policies and procedures, whether formal or informal. Your organization’s policies or the policies and guidelines of your industry might have an effect on scope management, so make certain you’re familiar with them. And don’t forget historical information. You can review the scope management plan from previous projects of similar size and scope to help you craft the one for this project.

Scope Management Plan Requirements

Phil Reid is a gifted engineer. He works as an accident reconstructionist and has a 90 percent success rate at assisting his clients (who are attorneys) at winning court cases. Phil can intuitively and scientifically determine whether the scene of an accident is real or is insurance fraud. Most cases Phil works on are managed as projects because each accident is unique, the cause of each accident is unique, and each investigation has a definite beginning and ending. The attorneys that Phil’s organization works with want the final results of the investigation delivered in different formats. Although Phil is exceptionally good at determining the forensic evidence needed to prove or disprove how the accident occurred, he is not at all gifted in oral communication skills. As a result, the scope management plan requires the client to define how the outcome of the investigation should be presented and whether the engineer might be required to testify regarding the results of the investigation. That way, Phil’s organization can plan in advance how to use his talents on the project and assign a resource to work with him who has the communication skills and ability to testify if that’s required.

using Plan scope Management Tools and Techniques Plan Scope Management has two tools and techniques:

Expert Judgment You’ll rely on the expert judgment of people or groups with specific skills, knowledge, or training to help assess the process inputs. One expert you can count on in this process is the executive manager who wrote or contributed to the project charter. This person can clarify questions you might have about the project objectives as well as the product description. Stakeholders, industry experts, team members, people with specialized training, or other project managers with previous experience on projects similar to yours can help you determine how scope management should work for this project.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Plan Scope Management 107

Meetings You will use meetings with the experts just noted to determine and formalize the information contained in the scope management plan.

documenting the scope Management Plan The first output of the Plan Scope Management process is the scope management plan. This plan describes how the project team will go about defining project scope, validating the work of the project, and managing and controlling scope. According to the PMBOK® Guide, the 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 what the deliverables and requirements of the project are and is based on the information contained in the preliminary scope.

■ A process for creating, maintaining, and approving the WBS. The WBS further defines the work of the project (as defined in the project scope statement) by breaking down the deliverables into smaller pieces of work.

■ A definition of how the deliverables will be validated 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.

Exam Spotlight

The scope management plan is a planning tool that documents how the project team will go about defining project scope, how the work breakdown structure will be developed, how changes to scope will be controlled, and how the work of the project will be validated and accepted. The scope management plan is based on the approved project scope. And don’t forget, the scope management plan is a component of (or a subsidiary of) the project management plan.

documenting the requirements Management Plan The requirements management plan is much like the scope management plan but focuses on the project requirements. This plan details how to analyze, document, and manage the project requirements throughout all phases of the project. Managing the requirements is the key to this process, and the phase‐to‐phase relationship you use to run the project will influence how you will manage the project requirements. For example, a sequential phase‐to‐ phase relationship would dictate that all the requirements for each phase be completed before beginning the work of the phase and most certainly before moving on to the next phase of the project. An overlapping relationship might mean that the requirements are not fully defined before the work begins and are progressively elaborated as the project (or phase) progresses.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

108 Chapter 3 ■ Developing the Project Scope Statement

We talked about phase‐to‐phase relationships in Chapter 1. There are two types: sequential and overlapping.

Exam Spotlight

Make certain you document the phase‐to‐phase relationship you’ll use during the project life cycle in the requirements management plan.

There are several components of a sound requirements management plan. According to the PMBOK® Guide, you should include the following factors in the plan (and you are always free to add more than those noted here):

■ 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)

■ What elements to include on the traceability matrix

Collecting Requirements Now we are getting into the meat of the Planning processes. In the Collect Requirements process, we define what the final product or service of the project will look like. You will recall that scope management describes what is and what is not included in the project scope. In this case, we’re starting off by defining what is included in the work of the project.

Exam Spotlight

The PMBOK® Guide notes that not all of the requirements gathered during this process will be included in the end result of the project. The Define Scope process is where you will determine which of the requirements gathered here will be included in the final project. We will look at Define Scope later in this chapter.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 109

Requirements describe the characteristics of the deliverables. They might also describe functionality that a deliverable must have or specific conditions a deliverable must meet 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 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.

Requirements can take many forms. According to the PMBOK® Guide, requirements can be classified into the categories listed here, which may also assist you in elaborating them further:

■ Business

■ Stakeholder

■ Solution

■ Functional

■ Nonfunctional

■ Transition

■ Project

■ Quality

The primary purpose of the Collect Requirements process is to define and document the project sponsor’s, the customer’s, and the stakeholder’s expectations and needs for meeting the project objectives. 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.

Exam Spotlight

Requirements must be documented, analyzed, and quantified in enough detail that they can be measured once the work of the project begins. Requirements become the basis for developing the WBS and are essential in estimating costs, developing the project schedule, and quality planning.

You’ve already learned about four of the five inputs to this process: the scope management plan, requirements management plan, project charter, and the stakeholder register. We will discuss the fifth, the stakeholder management plan, in Chapter 5, “Developing the Project Budget and Communicating the Plan,” so we’ll move on to tools and techniques.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

110 Chapter 3 ■ Developing the Project Scope Statement

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 and managers at all levels review and approve the work. 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 Risks process and the Plan Quality Management 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, in the information technology industry, you can use a technique called joint application design/development (JAD) to define requirements. Suppose you’re implementing

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 111

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 needs of other departments involved in the project and have a facilitated forum to discuss and resolve their issues. Other industries have similar techniques to bring together customers and/or business subject matter experts, such as Quality Function Deployment (QFD) sessions used in the manufacturing industry.

Exam Spotlight

The primary difference between focus groups and facilitated workshops is that focus groups are gatherings of prequalified subject matter experts and stakeholders, and facilitated workshops consist of cross‐functional stakeholders who can define cross‐functional requirements. Differences among stakeholders can be resolved more quickly and consensus is more easily attained in a facilitated workshop environment.

Group Creativity Techniques Group creativity involves several techniques, like brainstorming, the Nominal Group technique, affinity diagrams, and multicriteria decision analysis. We will cover each of these techniques in either the Identify Risks process (Chapter 6) or the Plan Quality Management process (Chapter 7).

Idea/mind mapping is a another group creativity technique in which participants first use brainstorming techniques to record their ideas. Whiteboards and flip charts are great tools to use with this process. The facilitator uses the whiteboard 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 gain 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 are 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

112 Chapter 3 ■ Developing the Project Scope Statement

with users and watching their interactions with the product enables observers 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 that 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.

Benchmarking This technique is used in the Quality processes as well and involves comparing measurements against standards to determine performance. It can also compare processes, operations, management practices, and so on against other departments, organizations, or industries to help refine and promote best practices or come up with ideas to improve current practices.

Context Diagrams Context diagrams use actors and business processes or equipment to visually show how interactions between them take place. Actors are people who use or interact with the business processes or equipment, which in turn produce outputs used by the actors.

Document Analysis Document analysis comes into play when it’s important to consider the organization’s business plans, marketing plans, contracts, business rules, strategic plans, and so on when determining requirements.

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 other output of this process is the requirements traceability matrix. I’ll describe each in detail next.

requirements documentation As I mentioned earlier, requirements quantify and prioritize the wants, needs, and expectations of the project sponsor and stakeholders to achieve the project objectives. 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. You never want to find yourself at the end of the project (or phase) and discover

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 113

you have no way to validate the requirements. 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 that 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 should 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

The first two items in this list—business need for the project and objectives—are also needed for the traceability matrix.

■ Functional requirements

■ Nonfunctional requirements

Functional requirements is a term used often in software development. It typically describes a behavior, such as calculations or processes that should occur once data is entered. In non‐software terms, functional requirements might describe specifications, quantities, colors, and more. Nonfunctional requirements refers to elements that are related to the product but doesn’t describe the product directly. In the case of a software product, this could be a security requirement or performance criteria.

■ Quality requirements

■ Acceptance criteria

■ Transition requirements for the operations area or customer receiving the end result of the project

■ 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

114 Chapter 3 ■ Developing the Project Scope Statement

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.

Ta b lE 3 .1 Requirements traceability matrix

unique id description of requirement source Priority

Test scenario owner status

001 Requirement one

Project objective

B User acceptance

HR specialist Approved

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 the owner of the test item, who will also decide if the test scenario passes or fails.

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, or canceled; and so on.

Exam Spotlight

According to the PMBOK® Guide, the requirements traceability matrix helps assure that business value is realized when the project is complete because each requirement is linked to a business and project objective.

The next process in the Planning process group is the Define Scope process. We’ll look at that next.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Defining Scope 115

Defining Scope Now that you’ve documented the project requirements, you’re ready to further define the needs of the project in the Define Scope process. 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 part of the chapter. 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.

Exam Spotlight

You’ll want to pay particular attention to the accuracy and completeness of this process. Defining project scope is critical to the success of the project because it spells out exactly what the product or service of the project looks like. Conversely, poor scope definition might lead to cost increases, rework, schedule delays, and poor morale.

First, you’ll examine the inputs and tools and techniques of this process. The inputs to the Define Scope process are as follows:

■ Scope management plan

■ Project charter

■ Requirements documentation

■ Organizational process assets

Some 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) are the project description, project objectives, the characteristics of the product of the project, and the process for approving the project.

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.

The requirements documentation is a starting point for developing the scope statement. During the Define Scope process, you will determine which requirements will be included in the final product, service, or result of the project. They will be progressively elaborated and then documented in detail in the scope statement. The idea here is that you know some information when the charter is being written and more information comes to light when you hold brainstorming sessions or other meetings with stakeholders to discover the requirements of the product of the project (during the Collect Requirements process).

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

116 Chapter 3 ■ Developing the Project Scope Statement

Finally, those requirements are decided on, further elaborated, and documented (again) in much more detail in the scope statement. Keep in mind that not all of the requirements that you gathered and documented in the Collect Requirements process may be included in the scope statement. You will reexamine those requirements here and determine which ones are keepers and which ones are not.

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 assumptions and constraints. I’ll cover each of these in the section “Writing the Project Scope Statement” later in this chapter.

Exam Spotlight

If the project charter is missing or was not created, you’ll need to develop the information normally found in the charter (or obtain it from other sources) to use as the foundation for creating the project scope statement.

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

■ Expert judgment

■ Product analysis

■ Alternatives generation

■ Facilitated workshops

You learned about expert judgment in Chapter 2 and about facilitated workshops earlier in this chapter. I’ll discuss product analysis and alternatives generation 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, product breakdown, systems‐engineering techniques, systems analysis, and value‐engineering techniques to further define the product or service.

Exam Spotlight

It’s beyond the scope of this book to go into the various analysis techniques used in product analysis. For exam purposes, remember that product analysis is a tool and technique of the Define Scope process and memorize the list of analysis techniques that might be performed in this process.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Defining Scope 117

alternatives generation Alternatives generation 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 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 generation 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 breaking apart the problem (or in our case the components of project scope, which are 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.

Outside the box

Lateral thinking is a way of reasoning and thinking about problems from perspectives other than the obvious. It challenges our perceptions and assumptions. Consider these two examples of lateral thinking that I crafted based on some puzzles I found at this website: www.folj.com/lateral/. Use your favorite search engine and run a query on “lateral thinking puzzles” to find many more examples.

Question: How could your pet Yorkie fall from the window of an 18‐story building and live?

answer: The question asks how your pet could fall from an 18‐story building and live; however, the question doesn’t state that your pet fell from the 18th floor. So, your pet Yorkie fell from the basement‐level window.

Question: Eight chocolates are arranged in an antique candy dish. Eight people each take one chocolate. There is one chocolate remaining in the dish. How can that be?

answer: If there are eight chocolates in an antique dish, how can the last person take the last chocolate yet one remains in the dish? Well, the last person to take a chocolate took the dish as well—therefore, the last chocolate remained in the dish.

Remember these examples the next time you’re defining scope or looking for alternative answers to a problem.

The use of pairwise comparisons is another alternatives generation technique. This is much like it sounds in that you compare any number of items against each other to determine which is preferred. This technique typically uses quantitative measures to determine the preferred option.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

http://www.folj.com/lateral/

118 Chapter 3 ■ Developing the Project Scope Statement

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 management team 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.

Exam Spotlight

Understand that the purpose of the scope statement, according to the PMBOK® Guide, is to provide all the stakeholders with a foundational understanding of the project and product scope. It describes the project deliverables in detail. Also remember that the scope statement defines and progressively elaborates the work of the project. It guides the work of the project team during the Executing process, and all change requests will be evaluated against the scope statement. If the change request is outside the bounds of the project scope as documented in the project scope statement, it should be denied.

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

■ Acceptance criteria

■ Project deliverables

■ Project exclusions

■ Project constraints

■ Project assumptions

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 119

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.

Exam Spotlight

You may be thinking that the project scope statement has some of the same information as the project charter. Keep in mind the project charter is a high‐level description of the project (and it names the project manager) whereas the project scope statement is a detailed description of the project and product scope and describes how the final product or result of the project will be accepted, along with the other items mentioned earlier.

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.

Exam Spotlight

You’ll use the project management plan as your measurement of project scope completion, and product scope completion will be measured against product requirements.

acceptance criteria 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. 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 or performed to consider the project or project phase completed. Deliverables should be specific and verifiable. For example, one of your deliverables might include

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

120 Chapter 3 ■ Developing the Project Scope Statement

widgets with a 3" diameter that will in turn be assembled into the final product. This deliverable, a 3" 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 2" widgets instead of the required 3" 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.

Critical Success Factors

Deliverables and requirements are sometimes referred to as critical success factors. Critical success factors are those elements that must be completed in order for the project to be considered complete. For example, if you’re building a bridge, one of the deliverables might be to produce a specific number of trusses that will be used to help support the bridge. Without the trusses, the bridge can’t be completed; in fact, the bridge might not stand without them. The trusses, in this case, are critical success factors. Not all deliverables are necessarily critical success factors, but many of them will fall into this category and should be documented as such.

Documenting All the Deliverables and Requirements

One of the project manager’s primary functions is to accurately document the deliverables and requirements of the project and then manage the project so that they are produced according to the agreed‐upon criteria. Deliverables describe the components of the goals and objectives in a quantifiable way. Requirements are the specifications of the deliverables. (Remember for the exam that requirements are documented in the Collect Requirements process that occurs before the Define Scope process.)

The project manager should use the project charter as a starting point for identifying and progressively elaborating project deliverables, but it’s possible that only some of

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 121

the deliverables will be documented there. Remember that the charter was signed by a manager external to the project, and it was the first take at defining the project objectives and deliverables. As the project manager, it’s your job to make certain all the deliverables are identified and documented in the project scope statement. That’s because the scope statement (not the project charter) serves as the agreement among stakeholders— including the customer of the project—regarding what deliverables will be produced to meet and satisfy the business needs of the project.

Interview the stakeholders, other project managers, project team members, customers, management staff, industry experts, and any other experts who can help you identify all the deliverables of the project. Depending on the size of the project, you might be able to accomplish this in a group setting using simple brainstorming techniques, but large complex projects might have scope statements for each deliverable of the project. Remember that the project scope statement is progressively elaborated into finer detail and is used later to help decompose the work of the project into smaller tasks and activities.

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 2020, 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

122 Chapter 3 ■ Developing the Project Scope Statement

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 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 triple 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. Constraints can come from inside or outside the project or organization. Let’s say 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 Constraints 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 3" widgets we 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 123

crane operators—at certain times during the project. If crane operators are not available when your schedule 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 marketplace, skill levels, and personality. You may also have availability issues or quality problems with nonhuman resources, like materials and goods. 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 management 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,

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

124 Chapter 3 ■ Developing the Project Scope Statement

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 Sandy is the one and only resource who can perform a specific task at a certain point in the project, document your assumption that Sandy will be available and run it by her manager. If Sandy 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.

Think about some of the factors you usually take for granted when you’re trying to identify assumptions. Many times they’re the elements everyone expects will be available or will behave in a specific way. Think about factors such as key team members’ availability, access to information, access to equipment, management support, and vendor reliability.

Try to validate your assumptions whenever possible. When discussing assumptions with vendors, make them put those assumptions 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 125

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

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.

Remember that the definition of a successful project is one that accomplishes the goals of the project and meets stakeholders’ expectations. Understand and document those expectations and you’re off to a good start.

updating the Project documents The last output of this process is project documents updates. 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 also 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.

Mountain Streams Services

Maria Sanchez is the CEO of Mountain Streams Services. She recently accepted a prestigious industry award on behalf of the company. Maria knows that without the dedication and support of her employees, Mountain Streams Services wouldn’t have achieved this great milestone.

Maria wants to host a reception for the employees and their guests in recognition of all their hard work and contributions to the company. Maria has appointed you to arrange the reception.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

126 Chapter 3 ■ Developing the Project Scope Statement

The reception is scheduled for April 12, and Maria has given you a budget of $125 per person. The company employs 200 people. The reception should be semiformal.

You’ve documented the deliverables as follows:

■ Location selection

■ Food and beverage menu

■ Invitations

■ Entertainment

■ Insurance coverage

■ Decorations

■ Photographer

■ Agenda

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

■ The location should be 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. Simply put, a WBS is a deliverable‐oriented hierarchy that defines and organizes the entire scope of work of the project and only the work of the project. The items defined on the WBS come from the approved scope statement. Like the scope statement, the WBS serves as a foundational agreement among the stakeholders and project team members regarding project scope.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 127

Exam Spotlight

Subdividing deliverables into smaller components is the purpose of the Create WBS process. The PMBOK® Guide calls this decomposition, which is also a tool and technique of this process.

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.

I can’t stress enough the importance of the work you’ve done up to this point. Your WBS will be only as accurate as your list of requirements and deliverables. The deliverables will become the groupings that will form the higher levels of the WBS from which activities will be derived later in the Planning processes.

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:

■ Scope management plan

■ Project scope statement

■ Requirements documentation

■ Enterprise environmental factors

■ Organizational process assets

The scope management plan outlines how you will create the WBS from the elements listed in the scope statement, and it also describes how to obtain approval for and maintain the WBS. 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

128 Chapter 3 ■ Developing the Project Scope Statement

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 two tools and techniques, decomposition and expert judgment. Decomposition 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:

1. Identify the deliverables and work. This step involves identifying all the major project deliverables and related work. You can use the expert judgment technique to analyze the project scope statement and identify the major deliverables.

2. Organize the WBS. This step involves organizing the work of the project and determining the WBS structure. (I’ll talk more about constructing the WBS in the next section.)

3. Decompose the WBS components into lower‐level components. WBS components, like the deliverables and requirements, should be defined in tangible, verifiable terms so that performance and successful completion (or delivery) are easily measured and verified. Each component must clearly describe the product, service, or result in verifiable terms, and it must be assigned to a unit in the organization that will take responsibility for completing the work and making certain of its accuracy.

4. Assign identification codes. This step is a process where you assign identification codes or numbers to each of the WBS components.

I’ll talk more about the process in step 4 later in this chapter in the section “Understanding the Unique WBS Identifiers.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 129

5. Verify the WBS. This step is a verification step. Examine the decomposition to determine whether all the components are clear and complete. Determine whether each component listed is absolutely necessary to fulfill the requirements of the deliverable, and verify that the decomposition is sufficient to describe the work.

Of course you won’t perform this process alone. That’s where the expert judgment tool and technique comes into play. You’ll work with others such as team members, stakeholders, other experts with specific training or industry knowledge, those who have worked on similar projects in the past, and industry aids such as templates.

You can now plug the components you and the team have 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 a couple of 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 next.

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, oftentimes 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

130 Chapter 3 ■ Developing the Project Scope Statement

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. 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 not all of the deliverables may need the same amount of decomposition. Also realize that performing too much decomposition can be as unproductive as not decomposing enough. My rule of thumb is, when the work outlined in the work package level is easily understood by team members and can be completed within a reasonable length of time, you’ve decomposed enough. If you decompose to the point where work packages are describing individual activities associated with higher‐level elements, you’ve gone too far.

Exam Spotlight

Remember that each descending level of the WBS is a more detailed description of the project deliverables than the level above it. Each component of the WBS should be defined clearly and completely and should describe how the work of the project will be performed and controlled. Collectively, all the levels of the WBS roll up to the top so that all the work of the project is captured (and no additional work is added). According to the PMBOK® Guide, this is known as the 100‐percent rule.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 131

There is some controversy among project managers over whether activities should be listed on the WBS. In practice, I often include activities on my work breakdown structure for small projects only because it facilitates other Planning processes later. In this case, the activities are the work package level. However, you should realize that large, complex projects do not include activities on the WBS. For the exam, remember that you will decompose activities during the Define Activities process that I’ll talk about in Chapter 4, “Creating the Project Schedule,” and that activities are not part of the WBS.

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.

F i gu R E 3 .1 WBS levels one and two

Billy Bob's Bassoon

Requirements De�nition

Design Speci�cations

Program Modules

WBS Level Two

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‐two 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

132 Chapter 3 ■ Developing the Project Scope Statement

F i gu R E 3 . 2 WBS levels one, two, and three

Billy Bob's Bassoon

Requirements De�nition

Game Requirements

Software Requirements

Software Design

Hardware Design

Code Requirements

Testing Requirements

Design Speci�cations

Program Modules

WBS Level Two

WBS Level One

WBS Level Three

Large, complex projects are often composed of several subprojects that collectively make up the main project. The WBS for a project such as the Billy Bob’s Bassoon game would show the subprojects as level‐one detail. These subprojects’ major deliverables would then be listed as level‐two content, perhaps more deliverables as level three, and so on.

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 133

F i gu R E 3 . 3 WBS levels one, two, three, and four

Character Definition

Instruments Design

Platform

System Description

Screen Design

Use Case Design

Speaker Design

Case Design

Module 1 Design

Module 1 Development

Unit Test Design

System Test Design

Billy Bob's Bassoon

Requirements Definition

Game Requirements

Software Requirements

Software Design

Hardware Design

Code Requirements

Testing Requirements

Design Specifications

Program Modules

WBS Level Two

WBS Level One

WBS Level Three

WBS Level Four

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.

WbS Templates

Work breakdown structures can be constructed using WBS templates or the WBS from a similar, completed project. Although every project is unique, many companies and industries perform the same kind of projects repeatedly. The deliverables are similar from project to project, and they generally follow a consistent path. WBS templates can be used in a case like this as a tool to simplify the WBS process, saving the project manager time.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

134 Chapter 3 ■ Developing the Project Scope Statement

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.

Exam Spotlight

Understand that rolling wave planning is a process of elaborating deliverables, project phases, or subprojects in the WBS to differing levels of decomposition depending on the expected date of the work. Work in the near term is described in more detail than work to be performed in the future.

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. The numbers are usually associated with the corporation’s chart of accounts, which is used to track costs by category. These codes are known as control accounts, and collectively, the control accounts 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 135

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

As mentioned earlier, the project manager is free to determine the number of levels in the WBS based on the complexity of the project. You need to include enough levels to accurately estimate project time and costs but not so many levels that it’s difficult to distinguish between the components. Regardless of the number of levels in a WBS, the lowest level in a WBS is called the work package level.

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 Define Activities 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.

This might seem self‐evident, but work packages not shown on the WBS are not included in the project. The same holds true for the project scope statement—if the deliverable isn’t noted there, it isn’t part of the project.

The lincoln Street Office building

Flagship International has just purchased a new building to house its growing staff. The folks at Flagship consider themselves very lucky to have won the bid on the property located in a prime section of the downtown area. The building is a historic building and is in need of some repairs and upgrades to make it suitable for office space. Constructing the renovations will require special handling and care, as outlined in the Historical Society Building Revisions Guide.

Alfredo Martini is the project manager assigned to the renovation project. Alfredo has already determined the deliverables for this project. In so doing, he has discovered

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

136 Chapter 3 ■ Developing the Project Scope Statement

that he will not be able to manage all the work himself. He will need several subproject managers working on individual deliverables, all reporting to him. Alfredo calls a meeting with the other project managers to develop the WBS. Let’s eavesdrop on the meeting.

“As you all know, we’re planning to move into the Lincoln Street building by November 1. There is quite a bit of work to do between now and then, and I’m enlisting each of you to manage a segment of this project. Take a look at this WBS.”

Here’s how a portion of the WBS that Alfredo constructed looks.

Lincoln Street Building Renovation

2.0 Facility Safety

2.1 Sprinkler System

2.2 Elevators

2.3 Emergency Evacuation Plans

3.0 Asbestos Abatement

3.1 Inspection and Identification

3.2 Plans for Removal

4.0 Office Space

4.1 Building Floor Plans

4.2 Plans for Office Space Allocation

4.3 Plans for Break Room Facilities

4.4 Plans for Employee Workout Room

Alfredo continues, “I’m going to manage the Facility Safety project. Adrian, I’d like you to take the Asbestos Abatement project, and Orlando, you’re responsible for the Office Space project.”

“Alfredo,” Adrian says, “asbestos abatement is going to take contractors and specialized equipment. We don’t have staff to do these tasks.”

“I understand. You’ll need to take charge of securing the contractor to handle this. Your responsibility will be to manage the contractor and keep them on schedule,” Alfredo answers.

Orlando reminds Alfredo that he has missed a deliverable on the WBS. “Part of the Office Space project needs to include the network communications and telecommunications equipment rooms. I don’t see that on here.”

“Good point, Orlando,” Alfredo says. “The level‐two and level‐three elements of this WBS are not complete. Each of you has been assigned to the subproject level, level one. Your first assignment is to meet back here in two weeks with a WBS for your subproject. I’d like to see some ideas about the staff assignments you’d make at the work package level and how long you think these components will take. We’ll refine those after we meet next.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 137

creating wBs Process outputs The Create WBS process has two outputs: the scope baseline and project documents updates. We’ll look at both of these next.

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 develop schedules, assign resources, and monitor and control the work of the project according to what’s described here. We’ve already talked about the project scope statement and the WBS, but let’s look at the WBS dictionary.

Exam Spotlight

The scope baseline is defined as the approved version of the detailed project scope state- ment, the WBS, and the WBS dictionary. Understand this concept for the exam. This process does not name the WBS as an output; the WBS is included as part of the scope baseline output.

wBs dictionary

The WBS dictionary, an element of the scope baseline, is where work component descriptions listed on the WBS 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

138 Chapter 3 ■ Developing the Project Scope Statement

■ Contract or agreements information

■ Constraints and assumptions

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.

If the WBS and the WBS dictionary are 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. 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.

Project documents updates Project documents updates might include updates to the requirements document, which can 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. The approved changes will likely change the project scope statement, the project management plan, and other project documents. These documents should be updated to reflect the approved changes.

I recommend reviewing Practice Standard for Work Breakdown Structures, Second Edition, published by PMI, to see examples of industry‐specific WBS templates, or you can modify the templates for particular business areas that may not be represented.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 139

Project Case Study: New Kitchen Heaven Retail Store

The project charter kickoff meeting was held and well attended. You’re ready to start gathering requirements and writing the project scope statement, and you have a question or two for Dirk. You knock on his door, and he invites you in.

“Shoot,” he says.

“I’m ready to define the deliverables and requirements for this project. I want to make sure I get the right folks involved in the meeting. Who are key stakeholders you recommend I speak with?”

“I can think of a few people right off that you don’t want to miss. There’s Jake Peterson over in facilities. He’s in charge of store furnishings, shelving, things like that—any supplies for the stores that aren’t retail products. He can help out with store build‐outs too. He supervised our last eight stores and did a terrific job.”

“Anyone else?” you ask.

“You should also talk to Jill Overstreet, the director in charge of retail products. She can help with the initial store stocking, and once the store is open, her group will take over the ongoing operations. All the district managers report to Jill.”

You thank Dirk and tell him you’re going to contact Jake and Jill and set up a brainstorming session to determine requirements.

A few days later.

You review your notes and reread the first draft of the project scope statement you’ve prepared for the Kitchen Heaven retail store before looking for Dirk. After your meetings with the stakeholders, you were better able to refine the project objectives and deliverables.

“Dirk, I’m glad I caught you. I’d like to go over the project scope statement with you before I give it to the stakeholders. Do you have a few minutes?”

“Sure,” Dirk says. “Let’s have it.”

“The project objective is to open the 50th Kitchen Heaven store in Colorado Springs by February 1. When I met with Jake, he confirmed it takes 120 days to do the store build‐ out. That includes having the shelves set up and in place, ready to stock with inventory.”

Dirk asks whether Jake told you about his store location idea.

“Yes, Jake gave me a contact name of the leasing agent, and I’ve left her a voicemail. The sooner we can get that lease signed, the better. It takes Jake 120 days to do the build‐out, and Jill said she needs two weeks lead time to order the initial inventory and stock the shelves. That puts us pretty close to our February 1 deadline, counting the time to get the lease papers signed.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

140 Chapter 3 ■ Developing the Project Scope Statement

“Sounds good so far,” Dirk replies. “What else?”

You continue, “I’ve included an updated description of the products and services the new store will offer, based on the documentation that was written from the last store opening. Jill reviewed the updates to the description, so we should be in the clear there. The store will include some new lines that we’ve decided to take on—cookware from famous chefs, that kind of thing.

“Jake has already made contact with a general contractor in Colorado Springs, and he is ready to roll once we’ve signed the lease.

“One more thing, Dirk. Since we’re including the big bash at the grand opening as part of the deliverables, I talked to some of your folks in marketing to get some ideas. They are thinking we should have some great giveaways as door prizes and that we will want the food catered. They also thought having some live cooking demonstrations with some local chefs would be a good attraction.”

“Sounds like you’re on the right track. So, what’s next?” Dirk asks.

“Once you approve the scope statement, I’d like to send a copy to the stakeholders. My next step is to break down the deliverables and requirements I’ve documented here into the WBS so we can get rolling on the work of the project.”

Project Case Study Checklist

The main topics discussed in the case study are as follows:

stakeholder analysis for requirements gathering: Jake Peterson and Jill Overstreet interviewed. Needs, wants, and expectations recorded and requirements prioritized.

organizational structure: Functional organization with a separate projectized department.

constraints: February 1 date to coincide with Garden and Home show.

assumptions: These are the assumptions:

■ A store build‐out usually takes 120 days.

■ Jill Overstreet will help with the initial store stocking.

■ Jake Peterson will provide supplies for the stores that aren’t retail products, such as store furnishings, shelving, and so on, and can help with the store build‐out as well.

■ The budget for the project will be between $1.5 and $2 million.

The project scope statement includes the following:

Project objectives: Open 50th store by February 1 in Colorado Springs.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How This Applies to Your Next Project 141

Project deliverables:

■ Build out storefront, including shelving.

■ Retail product line will be delivered two weeks prior to grand opening.

■ Have grand‐opening party with cooking demos.

Project requirements:

■ Sign lease within 14 days.

■ Offer new line of gourmet food products.

■ Have classroom space in back of store for cooking demos and classes.

constraints: February 1 date will coincide with Garden and Home Show.

fund limitations: Spend no more than $2 million on the project.

assumptions: (These are the same as listed earlier.) Decomposed deliverables into a WBS.

The WBS includes the following:

■ Level one is the project.

■ Level two is subprojects or deliverables.

■ Level three is deliverables.

■ Last level of WBS is the work package level, where time and cost estimates can be defined in the next 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 her 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

142 Chapter 3 ■ Developing the Project Scope Statement

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 document 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 document, and always get them signed.

Summary This chapter started you on the road to project planning via the Develop Project Management Plan process, the Plan Scope Management 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exam Essentials 143

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 primary output of the Plan Scope Management process is the scope management plan. This plan is an element of the project management plan that describes how the project team will go about defining project scope, validating the work of the project, and managing and controlling scope.

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 project scope statement is produced during the Define Scope process. It describes the project deliverables. The scope statement, along with the WBS and WBS dictionary, forms the scope baseline that 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 hierarchy 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

144 Chapter 3 ■ Developing the Project Scope Statement

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 scope 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 validated 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, 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 145

Review Questions You can find the answers to the questions in Appendix A.

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, monitored, and controlled. 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. The scope statement assesses the stability of the project scope and outlines how scope will be verified and used to control changes. The team members know that project scope is measured against the product requirements and that the scope management plan is based on the approved project scope.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

146 Chapter 3 ■ Developing the Project Scope Statement

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

c. 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 and that the scope management plan is based on the approved project charter.

d. 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 and that the scope management plan is based on the approved project charter.

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 147

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 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 generation techniques, which are a tool and technique of the Define Scope process.

9. Your company, Kick That Ball Sports, has appointed you as 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 may 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

148 Chapter 3 ■ Developing the Project Scope Statement

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 are a project manager working on a large, complex project. You’ve constructed the WBS for this project, and all of the work package levels are subprojects of this project. You’ve requested that the subproject managers report to you in three weeks with their individual WBSs constructed. Which statement is not true regarding your WBS?

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 149

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 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 are 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

150 Chapter 3 ■ Developing the Project Scope Statement

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed