USA: +1(669)289-8683 
Sign in
this is a continuation of last weeks assignment
General Requirements
Reread the Kitchen Heaven Project Case Study in Heldman et al. pages 84-87 and 139-141 and read pages 283-285.
Complete the Assumptions (the yellow portion) of the Logical Framework template
Include at least two additional assumptions for the Goal.
Include at least two additional assumptions for the Purpose
Risk Register
No.
Risk
Description
Category
Threat or
Opportunity
Risk Response
Strategy
Root Cause
Triggers
Potential Responses
Risk Owner
Probability
(High, Med, Low)
Impact
Assessment
(High, Med, Low)
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
Status
Logical Framwork for
Objectives
Goal:
Open a new Kitchen Heaven store in Colorado
Springs within six months.
Purpose:
To meet the demand for a Kitchen Heaven store
in the Colorado Springs area.
Outcomes:
Successful opening of the new store, its
performance in the market, and the company’s
increased presence in the Colorado Springs area.
Complete the project set up within 6 months.
Generate positive return. Meet the estimated
buget of $2 million.
Give project reports. Conduct project
reviews. Track project plan and
schedule.
The success measure of the purpose will be the
store’s performance in the market.
Conducted through monitoring and
analyzing the store’s sales figures and
customer feedback.
Success measure of the outcomes will be the
successful opening and performance of the new
store, increased customer base and sales, timely
completion of the project and staying within the
budget.
Regular monitoring and analysis of sales
figures, customer feedback, The team
will also review the project progress
and track it against the project plan and
schedule.
Inputs:
Manpower, supplies and materials, permits and
approvals, and a suitable location for the new
store.
Action Steps
Resource
Site visit,
Identify and secure a suitable location for the new transportation,
store
logistics, move
Obtaining permits and approvals
Verification
Success Measures
The project budget of $2 million
to be obtained through the
company’s financing and
managed by the project
manager.
Budget
Monitor and track any deviations,
shortages f supplies, and delays to
ensure project outcomes are achieved.
Due Dates
$100000
5/10/2024
Business
licenses, safey
permits, and
building permits. $50000
7/30/2024
page 1 of 4
Logical Framwork for
Objectives
Hiring the new staff
Stocking the store with inventory including
purchase, transportation and workforce
Success Measures
Store managers,
sales associates,
and support
staff.
$150000
Verification
8/30/2024
Proper stocking
of kitchenware.
$900000
9/25/2024
Launching the stores
Marketing
Marketing
materials: flyers,
brochures,
business cards. $150000
27/9/2024
Advertising the store in the new area
Social media,
email marketing,
and online
advertising.
$250000
28/28/2024
page 2 of 4
Logical Framwork for
Assumptions
To reach Goal:
Identify and secure a suitable location for the new store. This will
require market research and scouting the area for potential
storefronts. Purchase and stocking the store with inventory.
To reach Purpose:
Careful planning and execution of all necessary tasks and activities,
such as securing a suitable location, obtaining permits, hiring new
staff, and stocking the store with inventory.
To produce Outcomes:
Ensure that the project objectives align with the company’s goals
and strategy. The project team will have to successfully execute all
the planned tasks and activities outlined in the project charter.
To obtain & manage Inputs:
Ensure project does not exceed the budget, manage workforce.
Suppies and materials to be utilized effectively.
page 3 of 4
Logical Framwork for
Assumptions
page 4 of 4
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
✓✓ 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 2024-04-19 19:15:43.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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).
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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:
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
■■
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.
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 2024-04-19 19:15:43.
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
eliminating them.
Focuses on finding inefficiencies in a process or activity and
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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 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
■■
■■
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
How planning, tracking, and reporting of requirements activities will occur
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.
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 2024-04-19 19:15:43.
Collecting Requirements
109
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
110
Chapter 3
■
Developing the Project Scope Statement
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
Ta b l e 3 .1
Requirements traceability matrix
Description of
Unique ID Requirement Source
Priority
001
B
Requirement
one
Project
objective
Test
Scenario
User
acceptance
Owner
Status
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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).
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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:
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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,
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 2024-04-19 19:15:43.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
■■
■■
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.
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 2024-04-19 19:15:43.
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.
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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
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 2024-04-19 19:15:43.
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
Copyright © 2015. John Wiley & Sons, Incorporated. All rights reserved.
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.”
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 2024-04-19 19:15:43.
Creating the Work Breakdown Structure
5.
129
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 f…
