PMBOK VER 4

CHAPTER 5

PROJECT SCOPE MANAGEMENT

 PROJECT SCOPE MANAGEMENT

Project Scope Management includes the processes

required to ensure that the project includes all the
work required, and only the w0rk required, to
complete the project successfully.

Managing the project scope is primarily concerned with

defining and controlling what is and is not included in
the project.
 Project Scope Management Processes

5.1 Collect Requirements - The process of defining and

documenting stakeholders' needs to meet the project
objectives.
5.2 Define Scope-The process of developing a detailed
description of the project and product.
5.3 Create WBS-The process of subdividing project deliverables
and project work into smaller, more manageable components.
5.4 Verify Scope-The process of formalizing acceptance of the
completed project deliverables.
5.5 Control Scope-The process of monitoring the status of the
project and product scope and managing changes to the scope
baseline.
 Product Scope vs Project Scope
ln the project context, the term scope can refer to:
•Product scope. The features and functions that characterize a
product, service, or result; and/or
•Project scope. The work that needs to be accomplished to
deliver a product, service, or result with the specified features
and functions.
The processes used to manage project scope, as well as the
supporting tools and techniques, vary by application area and
are usually defined as part of the project Iife cycle.
The approved detailed project scope statement and its
associated WBS and WBS dictionary are the scope baseline for
the project.
This baselined scope is then monitored, verified, and c0ntrolled
throughout the lifecycle of the project.
 Product Scope vs Project Scope
Completion 0f the project scope is measured against the project
management plan (Section 4.2.3.1).

Completion of the product scope is measured against the

product requirements (Section 5.1).

The Project Scope Management processes need to be well

integrated with the other Knowledge Area processes, so that the
work of the project will result in delivery of the specified product
scope.
 5.1 Collect Requirements
Collect Requirements is the process of defining and documenting
stakeholders' needs and expectations to meet the project objectives.
The project's success is directly influenced by the care taken in
capturing and managing project and product requirements.
Requirements include the quantified and documented needs and
expectations of the sponsor, customer, and other stakeholders.
These requirements need to be elicited, analyzed, and recorded in
enough detail to be measured once project execution begins.
Requirements become the foundation of the WBS. Cost, schedule, and
quality planning are all built upon these requirements.
The development of requirements begins with an analysis of the
information contained in the project charter (Section 4.1 .3.1) and the
stakeholder register (Section 1 0.1 .3,1 ).
 5.1.1 Collect Requirements: lnputs
.1 Project Charter:
The project charter is used to provide the high-level project
requirements and high-level product description of the project so that
detailed product requirements can be developed.

.2 Stakeholder Register:
The stakeholder register is used to identify stakeholders that can provide
information on detailed project and product requirements.
The stakeholder register is described in Section 10.1 .
 5.1.2 Collect Requirements: Tools and Techniques
.1 Interviews:
An interview is a formal or informal approach to discover information from
stakeholders by talking to them directly. lt is typically performed by asking
prepared and spontaneous questions and recording the responses.
Interviews are often conducted "one-on-one," but may involve multiple
interviewers and/or multiple interviewees. Interviewing experienced project
participants, stakeholders, and subject matter experts can aid in identifying
and defining the features and functions of the desired project deliverables.

.2 Focus groups:
Focus groups bring together prequalified stakeholders and subject matter
experts to learn about their expectations and attitudes about a proposed
product, service, or result. A trained moderator
guides the group through an interactive discussion, designed to be more
conversational than a one-on-one interview.
 5.1.2 Collect Requirements: Tools and Techniques
.3 Facilitated Workshops:
Workshops are considered a primary technique for quickly
defining cross-functional requirements and reconciling
stakeholder differences.

Because of their interactive group nature, well-facilitated

sessions can build trust, foster relationships, and improve
communication among the participants which can lead to
increased stakeholder consensus.
 5.1.2 Collect Requirements: Tools and Techniques
. 4 Group Creativity Techniques:
• Brainstorming. A technique used to generate and collect multiple ideas related
to project and product requirements.
• Nominal group technique. This technique enhances brainstorming with a voting
process used to rank the most useful ideas for further brainstorming or for
prioritization.
• The Delphi Technique. A selected group of experts answers questionnaires and
provides feedback regarding the responses from each round of requirements
gathering. The responses are only available to the facilitator to maintain
anonymity.
• ldea/mind mapping. Ideas created through individual brainstorming are
consolidated into a single map to reflect commonality and differences in
understanding, and generate new ideas.
• Affinity diagram. This technique allows large numbers of ideas to be sorted into
groups for review and analysis.
 5.1.2 Collect Requirements: Tools and Techniques
.5 Group Decision Making Techniques:
Group decision making is an assessment process of multiple alternatives with
an expected outcome in the form of future actions resolution. These
techniques can be used to generate, classify,
and prioritize product requirements.

There are multiple methods of reaching a group decision, for example:

• Unanimity. Everyone agrees on a single course 0f action.
• Majority. Support from more than 50% of the members of the group.
• Plurality. The largest block in a group decides even if a majority is not
achieved.
• Dictatorship. 0ne individual makes the decision for the group.

Almost any of the decision methods described previously can be applied to the
group techniques used in the requirements gathering process.
 5.1.2 Collect Requirements: Tools and Techniques
.6 Questionnaires and Surveys:
Questionnaires and surveys are written sets of questions designed to quickly
accumulate information from a wide number of respondents.
Questionnaires and/or surveys are most appropriate with broad audiences,
when quick turnaround is needed, and where statistical analysis is
appropriate.

.7 0bservations:
0bservations provide a direct way of viewing individuals in their environment
and how they perform their jobs or tasks and carry out processes - lt is
particularly helpful for detailed processes when the people that use the
product have difficulty or are reluctant to articulate their requirements.
0bservation, also called "job shadowing," is usually done externally by the
observer viewing the user performing his or her job. lt can also be done by a
"participant observer" who actually performs a process or procedure
to experience how it is done to uncover hidden requirements.
 5.1.2 Collect Requirements: Tools and Techniques
.8 Prototypes:
Prototyping is a method of obtaining early feedback on requirements by
providing a working model of the expected product before actually
building it.

Since prototypes are tangible, it allows stakeholders to experiment with

a model of their final product rather than only discussing abstract
representations of their requirements. Prototypes support the concept
of progressive elaboration because they are used in iterative cycles
of mock-up creation, user experimentation, feedback generation, and
prototype revision. When enough feedback cycles have been
performed, the requirements obtained from the prototype are
sufficiently complete to move to a design or build phase.
 5.1.3 Collect Requirements Outputs
.1 Requirements Documentation:
Requirements documentati0n describes how individual
requirements meet the business need for the project.
Requirements may start out at a high level and become
progressively more detailed as more is known.

Before being baselined, requirements must be unambiguous

(measurable and testable), traceable, complete, consistent,
and acceptable to key stakeholders.

The format of a requirements document may range from a

simple document listing all the requirements categorized by
stakeholder and priority, to more elaborate forms containing
executive summary, detailed descriptions, and attachments.
 5.1.3 Collect Requirements Outputs
Components of requirements documentation can include, but, are not
limited to:
•Business need or opportunity to be seized, describing the limitations of
the current situation and why the project has been undertaken;
•Business and project objectives for traceability;
•Functional requirements, describing business processes, information,
and interaction with the product, as appropriate which can be
documented textually in a requirements list, in models, or both;
•Nonfunctional requirements, such as level of service, performance,
safety, security, compliance, supportability, retention/purge, etc. ;
 5.1.3 Collect Requirements Outputs

• Quality requirements;
• Acceptance criteria;
• Business rules stating the guiding principles of the organization;
• lmpacts to other organizational areas, such as the call center, sales
force, technology groups;
• Impacts to other entities inside or outside the performing organization;
• Support and training requirements; and
• Requirements assumptions and constraints.
 5.1.3 Collect Requirements Outputs
.2 Requirements Management Plan:

The requirements management plan documents how requirements will be

analyzed, documented, and managed throughout the project.
The phase-to-phase relationship, described in Section 2.1.3.2, strongly
influences how requirements are managed. The project manager must
choose the most effectlve relationship for the project and document this
approach in the requirements management plan. Many of the
requirements management plan components are based on that
relationship.
 5.1.3 Collect Requirements Outputs
Components of the requirements management plan can include, but
are not limited to:
•How requirements activities will be planned, tracked, and reported;
•Configuration management activities such as how changes to the
product, service, or result requirements will be initiated, how impacts
will be analyzed, how they will be traced, tracked, and reported, as
well as the authorization levels required to approve these changes;
• Requirements prioritization process;
•Product metrics that will be used and the rationale for using them;
and
•Traceability structure, that is, which requirements attributes will be
captured on the traceability matrix and to which other project
documents requirements will be traced.
 5.1.3 Collect Requirements Outputs
.3 Requirements Traceability Matrix:
The requirements traceability matrix is a table that links requirements to
their origin and traces them throughout the project life cycle.

The implementation of a requirements traceability matrix helps ensure

that each requirement adds business value by linking it to the
business and project objectives.

It provides a means to track requirements throughout the project life

cycle, helping to ensure that requirements approved in the
requirements documentation are delivered at the end of the project.
 5.2 Define Scope
Define Scope is the process of developing a detailed description
of the project and product. The preparation of a detailed project
scope statement is critical to project success and builds upon the
major deliverables, assumptions, and constraints that are
documented during project initiation.

During planning, the project scope is defined and described with

greater specificity as more information about the project is
known.

Existing risks, assumptions, and constraints are analyzed for

completeness; additional risks, assumptions, and constraints
are added as necessary.
 5.2.1 Define Scope: lnputs
.1 Project Charter:
The project charter provides the high-level project description
and product characteristics. lt also contains project approval
requirements.
.2 Requirements Documentation:
Described in Section 5.1 .3.1 .
.3 organizational Process Assets:
Examples of organizational process assets that can influence the
Define Scope process include, but are not limited to:
• Policies, procedures, and templates for a project scope
statement,
• Project files from previous projects, and
• Lessons learned from previous phases or projects.
 5.2.2 Define Scope: Tools and Techniques
.1 Expert Judgment:
Expert judgment is often used to analyze the information needed t0
develop the project scope statement. Such judgment and expertise
is applied to any technical details. Such expertise is provided by any
group or individual with specialized knowledge 0r training, and is
available from many sources.

.2 Product Analysis:
For projects that have a product as a deliverable, as opposed to a
service or result, product analysis can be an effective tool. Each
application area has one or more generally accepted methods
for translating high-level product descriptions into tangible
deliverables. Product analysis includes techniques such as product
breakdown, systems analysis, requirements analysis, systems
engineering, value engineering, and value analysis.
 5.2.2 Define Scope: Tools and Techniques
.3 Alternatives ldentification:
ldentifying alternatives is a technique used to generate different
approaches to execute and perform the work of the project. A
variety of general management techniques can be used such
as brainstorming, lateral thinking, pair wise comparisons, etc.

. 4 Facilitated Workshops:
Described in Section 5.1.2.3.
 5.2.3 Define Scope: 0utputs
.1 Project Scope Statement:
The project scope statement describes, in detail, the project's
deliverables and the work required to create those
deliverables.
The project scope statement also provides a common
understanding of the project scope among project
stakeholders.
It may contain explicit scope exclusions that can assist in
managing stakeholder expectations.
It enables the project team to perform more detailed planning,
guides the project team's work during execution, and
provides the baseline for evaluating whether requests for
changes or additional work are contained within or outside
the project's boundaries.
 5.2.3 Define Scope: 0utputs
The detailed project scope statement includes, either directly, or by
reference to other documents, the following:

•Product scope description. Progressively elaborates the characteristics

of the product, service, or result described in the project charter and
requirements documentation.
•Product acceptance criteria. Defines the process and criteria for
accepting completed products, services, or results.
•Project deliverables. Deliverables include both the outputs that
comprise the product or service of the project, as well as ancillary
results, such as project management reports and documentation. The
deliverables may be described at a summary level or in great detail.
 5.2.3 Define Scope: 0utputs
• Project exclusions. Generally identifies what is excluded as from the project.
Explicitly stating what is out of scope for the project helps to manage stakeholders'
expectations.

• Project constraints. Lists and describes the specific project constraints associated
with the project scope that limits the team's options, for example, a predefined
budget or any imposed dates or schedule milestones that are issued by the
customer or performing organization. When a project is performed under contract,
contractual provisions will generally be constraints. Information on constraints may
be listed in the project scope statement or in a separate log.

• Project assumptions. Lists and describes the specific project assumptions

associated with the project scope and the potential impact of those assumptions if
they prove to be false. Project teams frequently identify, document, and validate
assumptions as part of their planning process.
 5.2.3 Define Scope: 0utputs
.2 Proiect Document Updates
Project documents that may be updated include, but are not
limited to:
• Stakeholder register,
• Requirements documentation, and
• Requirements traceability matrix.
 5.3 Create WBS
Create WBS is the process of subdividing project deliverables and project work
into smaller, more manageable components. The work breakdown structure
(WBS) is a deliverable-oriented hierarchical decomposition of the work to be
executed by the project team to accomplish the project objectives and create
the required deliverables, with each descending level of the WBS representing
an increasingly detailed definition of the project work. The WBS organizes and
defines the total scope of the project, and represents the work specified in the
current approved project scope statement.

The planned work is contained within the lowest level WBS components, which
are called work packages.
A work package can be scheduled, cost estimated, monitored, and controlled.
In the context of the WBS, work refers to work products or deliverables that are
the result of effort and not to the effort itself.
 5.3.1 Create WBS: lnputs
.1 Project Scope Statement
Described in Section 5.2.3.1 .

.2 Requirements Documentation
Described in Section 5.1.3.1.

.3 Organizational Process Assets:

The organizational process assets that can influence the Create
WBS process include, but are not limited to:
• Policies, procedures, and templates for the WBS,
• Project files from previous projects, and
• Lessons learned from previous projects.-
 5.3.2 Create WBS: Tools and Techniques
.1 Decomposition
Decomposition is the subdivision of project deliverables into
smaller, more manageable components until the work and
deliverables are defined to the work package level.

The work package level is the Iowest level in the WBS, and is the
point at which the cost and activity durations for the work can
be reliably estimated and managed.

The level of detail for work packages will vary with the size and
complexity of the project.
 5.3.2 Create WBS: Tools and Techniques
The WBS structure can be created in a number of forms, such as:
• Using phases of the project life cycle as the first level of
decomposition, with the product and project deliverables
inserted at the second level, as shown in Figure 5-9;

• Using major deliverables as the first level of decomposition,

as shown in Figure 5-l 0; and

• Using subprojects which may be developed by organizations

outside the project team, such as contracted work. The seller
then develops the supporting contract work breakdown
structure as part of the contracted work.
 5.3.2 Create WBS: Tools and Techniques
As the work is decomposed to greater levels of detail, the ability to plan,
manage, and control the work is enhanced.
However, excessive decomposition can lead to non-productive management
effort, inefficient use of resources, and decreased efficiency in performing the
work.

The WBS represents all product and project work, including the project
management work. The total of the work at the lowest levels must roll up to the
higher levels so that nothing is Left out and no extra work is completed. This is
sometimes called the 100% rule.

Decomposition may not be possible for a deliverable or subproject that will be

accomplished far into the future. The project management team usually waits
until the deliverable or subproject is clarified so the details of the WBS can be
developed. This technique is sometimes referred to as “rolling wave planning”.
 5.3.3 Create WBS: 0utputs
. 1 WBS:
The WBS is a deliverable-oriented hierarchical decomposition of the
work to be executed by the project team, to accomplish the project
objectives and create the required deliverables, with each descending
level of the WBS representing an increasingly detailed definition of the
project work.
The WBS is finalized by establishing control accounts for the work
packages and a unique identifier from a code of accounts.
These identifiers provide a structure for hierarchical summation 0f
costs, schedule, and resource information.
A control account is a management control point where scope, cost,
and schedule are integrated and compared to the earned value for
performance measurement.
Control accounts are placed at selected management points in the
WBS. Each control account may include one or more work packages,
but each of the work packages must be associated with only one
control account.
 5.3.3 Create WBS: 0utputs
.2 WBS Dictionary:
The WBS dictionary is a document generated by the Create WBS process that
supports the WBS. The WBS dictionary provides more detailed descriptions of the
components in the WBS, including work packages and control accounts.
lnformation in the WBS dictionary includes, but is not limited to:
 Code of account identifier
 Description of work,
 Responsible organization
 List of schedule milestones,
 Associated schedule activities,
 Resources required,
 Cost estimates,
 Quality requirements,
 Acceptance criteria,
 Technrcal references, and
 Contract information.
 5.3.3 Create WBS: 0utputs
.3 Scope Baseline:
The scope baseline is a component of the project management plan.
Components of the scope baseline include:
• Project scope statement. The project scope statement includes the
product scope description, the project deliverables and defines the
product user acceptance criteria.
• WBS. The WBS defines each deliverable and the decomposition of
the deliverables into work packages.
• WBS dictionary. The WBS dictionary has a detailed description of
work and technical documentation for each WBS element.
 5.3.3 Create WBS: 0utputs
.4 Project Document Updates:
Project documents that may be updated include, but are not
limited to requirements documentation.
lf approved change requests result from the Create WBS
process, then the requirements documentation may need to
be updated to include approved changes.
 5.4 Verify Scope

Verify Scope is the process of formalizing acceptance of the

completed project deliverables. Verifying scope includes
reviewing deliverables with the customer or sponsor to ensure
that they are completed satisfactorily and obtaining formal
acceptance of deliverables by the customer or sponsor.
Scope verification differs from quality control in that scope
verification is primarily concerned with acceptance of the
deliverables, while quality control is primarily concerned with
correctness of the deliverables and meeting the quality
requirements specified for the deliverables.
Quality control is generally performed before scope verification,
but these two processes can be performed in parallel.
 5.4.1 Verify Scope: lnputs
.1 Project Management Plan:
The project management plan described in Section 4.2.3.1
contains the scope baseline. Components of the scope
baseline include:
• Project scope statement. The project scope statement
includes the product scope description, includes the project
deliverables, and defines the product user acceptance
criteria.
• WBS. The WBS defines each deliverable and the
decomp0sition of the deliverables into work packages.
• WBS dictionary. The WBS dictionary has a detailed description
of work and technical documentation for each WBS element.
 5.4.1 Verify Scope: lnputs
.2 Requirements Documentation:
The requirements documentation Iists all the project, product,
technical, and Other types of requirements that must be
present for the project and product, along with their
acceptance criteria.
Requirements documentation is described in Section 5.1 .3.1 .
.3 Requirements Traceability Matrix:
The requirements traceability matrix links requirements to their
origin and tracks them throughout the project life cycle,
which is described in Section 5.1.3,3.
.4 Validated Deliverables:
Validated deliverables have been completed and checked for
correctness by the Perform Quality Control Process.
 5.4.2 Verify Scope: Tools and Techniques
.1 lnspection:
lnspection includes activities such as measuring, examining, and
verifying to determine whether work and deliverables meet
requirements and product acceptance criteria. inspections
are sometimes called reviews, product reviews, audits, and
walkthroughs. ln some application areas, these different
terms have narrow and specific meanings.
 5.4.3 Verify Scope: Outputs
.1 Accepted Deliverables:
Deliverables that meet the acceptance criteria are formally signed off and
approved by the customer or sponsor.
Formal documentation received from the customer or sponsor
acknowledging formal stakeholder acceptance of the project's
deliverables is forwarded to the Close Project 0r
Phase process (4.6).
.2 Change Requests:
Those completed deliverables that have not been formally accepted are
documented, along with the reasons for non-acceptance. Those
deliverables may require a change request for defect repair.
.3 Project Document Updates
Project documents that may be updated as a result of the Verify Scope
process include any documents that define the product or report status
on product completion.
 5.5 Control Scope
Control Scope is the process of monitoring the status of the
project and product scope and managing changes to the scope
baseline.
Controlling the project scope ensures all requested changes and
recommended corrective or preventive actions are processed
through the Perform lntegrated Change Contr0l process (see
Section 4.5).
Project scope control is also used to manage the actual changes
when they occur and is integrated with the other control
processes.
Uncontrolled changes are often referred to as project scope
creep.
 5.5.1 Control Scope: lnputs
.1 Project Management Plan:
The project management plan described in Section 4.2.3,1
contains the following information that is used to control
scope:
• Scope baseline: The scope baseline is compared to actual
results t0 determine if a change, corrective action, or
preventive action is necessary.
• Scope management plan: The scope management plan
describes how the project scope will be managed and
controlled.
• Change management plan: The change management plan
defines the process for managing change on the project.
 5.5.1 Control Scope: lnputs
• Configuration management plan: The configuration management plan
defines those items that are configurable, those items that require
formal change control, and the process for controlling changes to
such items.

• Requirements management plan. The requirements management

plan can includes how requirements activities will be planned,
tracked, and reported and how changes to the product, service, or
result requirements will be initiated. lt also describes how impacts will
be analyzed and the authorization levels required to approve these
changes;
 5.5.1 Control Scope: lnputs
.2 Work Performance lnformation:
lnformation about project progress, such as which deliverables have
started, their progress and which deliverables have finished.
.3 Requirements Documentation:
Described in Section 5.1.3.1.
4 Requirements Traceability Matrix:
Described in Section 5.1 .3.3.
.5 0rganizational Process Assets
The organizational process assets that can influence the Control
Scope process include but are not limited to:
– Existing formal and informal scope control-related policies,
procedures, and guidelines,
– Monitoring and reporting methods to be used.
5.5.2 Control Scope: Tools and Techniques
.1 Variance Analysis:
Project performance measurements are used to assess the
magnitude of variation from the original scope baseline.
lmportant aspects of project scope control include
determining the cause and degree of variance relative to the
scope baseline (Section 5.3.3.3) and deciding whether
corrective or preventive action is required.
 5.5.3 Control Scope:0utputs
.1 Work Performance Measurements:
Measurements can include planned vs. actual technical
performance or other scope performance measurements.
This information is documented and communicated to
stakeholders.
.2 0rganizational Process Assets Updates:
0rganizational process assets that may be updated include, but
are not limited to:
• Causes of variances,
• Corrective action chosen and the reasons, and
• 0ther types of lessons learned from project scope control.
 5.5.3 Control Scope:0utputs
.3 Change Requests:
Analysis of scope performance can result in a change request to
the scope baseline or other components of the project
management plan.
Change requests can include preventive or corrective
actions or defect repairs.
Change requests are processed for review and disposition
according to the Perform lntegrated Change Control process
(Section 4.5).
 5.5.3 Control Scope:0utputs
.4 Project Management Plan Updates:
• Scope Baseline Updates. lf the approved change requests have an
effect upon the project scope, then the scope statement, the WBS,
and the WBS dictionary are revised and reissued to reflect the
approved changes.
• 0ther Baseline Updates. lf the approved change requests have an
effect on the project scope, then the corresponding cost baseline and
schedule baselines are revised and reissued to reflect the approved
changes.
.5 Project Document Updates
Project documents that may be updated include, but are not
limited to
• Requirements documentation, and
• Requirements traceability matrix.
END