5 - PROJEC T SC OPE MANAGEMENT

5
PROJECT SCOPE MANAGEMENT
Project Scope Management includes the processes required to ensure that the project includes all the
work required, and only the work required
5.1Plan Scope ManagementThe process of creating a scope management plan that documents
how the project scope will be defined, validated, and controlled.
5.2Collect RequirementsThe process of determining, documenting, and managing stakeholder
needs and requirements to meet project objectives.
5.3Define ScopeThe process of developing a detailed description of the project and product.
5.4Create WBSThe process of subdividing project deliverables and project work into smaller, more
manageable components.
5.5Validate ScopeThe process of formalizing acceptance of the completed project deliverables.
5.6Control ScopeThe process of monitoring the status of the project and product scope and
managing changes to the scope baseline.

Product scope. The features and functions that characterize a product, service, or result; and/or
Project scope. The work performed to deliver a product, service, or result with the specified features
and functions. The term project scope is sometimes viewed as including product scope.

. The scope baseline for the project is the approved version of the project scope statement, work
breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only
through formal change control procedures

Completion of 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

5.1Plan Scope Management

Plan Scope Management is the process of creating a scope management plan that documents how
the project scope will be defined, validated
The scope management plan is a component of the project or program management plan that describes how
the scope will be defined, developed, monitored, controlled, and verified.
This plan helps reduce the risk of project scope creep.

5.1.1 Plan Scope Management: Inputs

5.1.1.1 Project Management Plan
Approved subsidiary plans of the project management plan are used to create the scope management plan

5.1.1.2 Project Charter

Described in It provides the high-level project description and product characteristics from the project
statement of work.

5.1.2

Plan

Scope Management: Tools and Techniques

5.1.2.1 Expert Judgment
Expert judgment refers to input received from knowledgeable and experienced parties. Expertise may
be provided by any group or person with specialized education, knowledge, skill, experience, or training in
developing scope management plans.

5.1.2.2

Meetings

. Attendees at these meetings may include the project manager, the project sponsor, selected project
team members, selected stakeholders, anyone with responsibility for any of the scope management
processes, and others as needed.

5.1.3

Plan Scope Management: Outputs

5.1.3.1

Scope Management Plan

The scope management plan is a component of the project or program management plan that describes how
the scope will be defined, developed, monitored, controlled, and verified

Process for preparing a detailed project scope statement;

Process that enables the creation of the WBS from the detailed project scope statement;
Process that establishes how the WBS will be maintained and approved;
Process that specifies how formal acceptance of the completed project deliverables will be obtained; and
Process to control how requests for changes to the detailed project scope statement will be
processed. This process is directly linked to the Perform Integrated Change Control process (Section
4.5).
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the
needs of the project.

5.1.3.2 Requirements Management Plan

The requirements management plan is a component of the project management plan that describes
how requirements will be analyzed, documented, and managed.

5.2 Collect Requirements

Collect Requirements is the process of determining, documenting, and managing stakeholder needs
and requirements to meet project objectives. The key benefit of this process is that it provides the basis for
defining and managing the project scope including product scope.
. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and sometimes
procurement are all based upon these requirements.

5.2.1

Collect Requirements: Inputs

5.2.1.1 Scope Management Plan

Described in Section 5.1.3.1. The scope management plan provides clarity as to how project teams will
determine which type of requirements need to be collected for the project.

5.2.1.2
ements Management Plan
Described in Section 5.1.3.2. The requirements management plan provides the processes that will be
used throughout the Collect Requirements process to define and document the stakeholder needs.

Requir

5.2.1.3

Stakeholder Management Plan

Described in Section 13.2.3.1. The stakeholder management plan is used to understand stakeholder
communication requirements and the level of stakeholder engagement in order to assess and adapt to the level
of stakeholder participation in requirements activities.

5.2.1.4

Project Charter

provide the high-level description of the product, service, or result of the project so that detailed
requirements can be developed.

5.2.1.5

Stakeholder Register

Described in Section 13.1.3.1. The stakeholder register is used to identify stakeholders who can
provide information on the requirements.

5.2.2 Collect Requirements: Tools and Techniques

5.2.2.1 Interviews
An interview is a formal or informal approach to elicit information from stakeholders by talking to them
directly. interviewees. Interviewing experienced project participants, sponsors and other executives, and
subject matter experts can aid in identifying and defining the features and functions of the desired product
deliverables. Interviews are also useful for obtaining confidential information.

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

5.2.2.3 Facilitated Workshops

Facilitated workshops are focused sessions that bring key stakeholders together to define product
requirements. can lead to increased stakeholder consensus
example, facilitated
workshops called joint application design/development (JAD)
quality function deployment (QFD) is another example of a facilitated workshop technique
, also known as voice of the customer (VOC).

5.2.2.4

Group Creativity Techniques

Several group activities can be organized to identify project and product requirements.
Brainstorming. A technique used to generate and collect multiple ideas related to project and product
requirements..

Nominal group technique. A technique that enhances brainstorming with a voting process used to rank
the most useful ideas for further brainstorming or for prioritization.

Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions
are consolidated into a single map to reflect commonality and differences in understanding, and
generate new ideas.
Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for
review and analysis.
Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a
systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation,
to evaluate and rank many ideas.

5.2.2.5

Group Decision-Making Techniques

A group decision-making technique is an assessment process having multiple alternatives with an expected
outcome in the form of future actions..
There are various methods of reaching a group decision, such as:
Unanimity. A decision that is reached whereby everyone agrees on a single course of action. One
way to reach unanimity is the Delphi technique, in which 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.
Majority. A decision that is reached with support obtained from more than 50 % of the members
of the group. Having a group size with an uneven number of participants can ensure that a
decision will be reached, rather than resulting in a tie.
Plurality. A decision that is reached whereby the largest block in a group decides, even if a
majority is not achieved. This method is generally used when the number of options nominated is
more than two.
Dictatorship. In this method, one individual makes the decision for the group.

5.2.2.6 Observations
. It is particularly helpful for detailed processes when the people that use the product have difficulty or are
reluctant to articulate their requirements.
Observation is also known as job shadowing.

5.2.2.7 Prototypes
Prototyping is a method of obtaining early feedback on requirements
Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user
experimentation
Storyboards are used on a variety of projects in a variety of industries, such as film, advertising,
instructional design, and on agile and other software development projects..

5.2.2.8 Benchmarking
Benchmarking involves comparing actual or planned practices,.

5.2.2.9 Context Diagrams

The context diagram is an example of a scope model.

5.2.2.10
ment Analysis
1-Document analysis is used to elicit requirements by analyzing existing documentation and identifying
information relevant to the requirements
.2- Examples of documents that may be analyzed include, but are not limited to: business plans, marketing
literature, agreements, requests for proposal, current process flows, logical data models, business rules
repositories, application software documentation, business process or interface documentation, use cases, other
requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as
laws, codes, or ordinances, etc.

5.2.3

Collect Requirements: Outputs

Requirements Documentation

1-Requirements documentation describes how individual requirements meet the business need for the
project.
2- Requirements may start out at a high level and become progressively more detailed as more about the
requirements is known. Before being baselined,
3- requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and
acceptable to key stakeholders.

Docu

 Stakeholder requirements, including:

Impacts to other organizational areas;
Impacts to other entities inside or outside the performing organization; and
Stakeholder communication and reporting requirements.
Solution requirements, including:
Functional and nonfunctional requirements;
Technology and standard compliance requirements;
Support and training requirements;
Quality requirements; and
Reporting requirements, etc. (solution requirements can be documented textually, in models,
or both).
Project requirements, such as:
Levels of service, performance, safety, compliance, etc.; and
Acceptance criteria.
Transition requirements.
Requirements assumptions, dependencies, and constraints.

5.2.3.2 Requirements Traceability Matrix

1- The requirements traceability matrix is a grid that links product requirements from their origin to
the deliverables that satisfy them.
2- 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.
Finally,
3- it provides a structure for managing changes to the product scope.
Tracing includes, but is not limited to, tracing requirements for the following:
Business needs, opportunities, goals, and objectives;
Project objectives;
Project scope/WBS deliverables;
Product design;
Product development;
Test strategy and test scenarios; and
High-level requirements to more detailed requirements.

5.3 Define Scope

1- Define Scope is the process of developing a detailed description of
the project and product.
2- The key benefit of this process is that it describes the product,
service, or result boundaries by defining which of the requirements
collected will be included in and excluded from the project scope.

3- the Define Scope process selects the final project

requirements from the requirements documentation
delivered during the Collect Requirements process. It then
develops a detailed description of the project and product,
service, or result.
4- The Define Scope process can be highly iterative.

5.3.2 Define Scope: Tools and Techniques

5.3.2.1 Expert Judgment
Expert judgment is often used to analyze the information needed to
develop the project scope statement.
Other units within the organization;
Consultants;
Stakeholders, including customers or sponsors;
Professional and technical associations;
Industry groups; and
Subject matter experts.

5.3.2.2 Product Analysis

1- 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.3.2.3

Alternatives Generation

1- Alternatives generation is a technique used to develop as many

potential options as possible in order to identify different
approaches to execute and perform the work of the project.
2- A variety of general management techniques can be used, such
as brainstorming, lateral thinking, analysis of alternatives, etc.

5.3.2.4

Facilitated Workshops

Described in Section 5.2.2.3. The participation of key players with a variety of

expectations and/or fields of
expertise in these intensive working sessions helps to reach a crossfunctional and common understanding of the project objectives and its
limits.

5.3.3

Define Scope: Outputs

5.3.3.1 Project Scope Statement

1- The project scope statement is the description of the project
scope, major deliverables, assumptions, and constraints. The
project scope statement documents the entire scope,
including project and product scope.
2- It describes, in detail, the projects deliverables and the work
required to create those deliverables.
3- and provides the baseline for evaluating whether requests for
changes or additional work are contained within or outside the
projects boundaries.
includes the following:
Product scope description. Progressively elaborates the
characteristics of the product, service, or result described in the
project charter and requirements documentation.
Acceptance criteria. A set of conditions that is required to be met before
deliverables are accepted.
Deliverable. Any unique and verifiable product, result, or
capability to perform a service that is required to be produced
to complete a process, phase, or project. Deliverables also
include ancillary results, such as project management reports
and documentation. These deliverables may be described at a
summary level or in great detail.

 Project exclusion. Generally identifies what is excluded from

the project. Explicitly stating what is out of scope for the project
helps to manage stakeholders expectations.
. Constraints. A limiting factor that affects the execution of a project or
process. Constraints identified
with the project
scope statement list and describe the specific internal or external restrictions or limitations
associated with the project scope that affect the execution of the project, 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 an agreement,
contractual provisions will generally be constraints. Information on constraints may be listed in the
project scope statement or in a separate log
Assumptions. A factor in the planning process that is
considered to be true, real, or certain, without proof or
demonstration. Also describes the potential impact of
those factors if they prove to be false. Project teams
frequently identify, document, and validate assumptions as
part of their planning process. Information on assumptions
may be listed in the project scope statement or in a separate
log.
Although the project charter and the project scope statement are
sometimes perceived as containing a certain degree of redundancy, they
are different in the level of detail contained in each. The project charter
contains high- level information, while the project scope statement
contains a detailed description of the scope elements. These elements
are progressively elaborated throughout the project. Table 5-1 describes
some of the key elements for each document.
Table 5-1. Elements of the Project Charter and Project Scope
Statement
Project
Charter
Project Scope Statement
Project purpose or justification
Project scope description
Measurable project objectives
and related
successAcceptance
criteria
(progressively
elaborated)
criteria Project deliverables Project exclusions Project constraints
High-level requirementsProject
High-level
project description High-level risks
assumptions
Summary milestone schedule Summary budget
Stakeholder list
Project approval requirements (what constitutes success, who decides it, who signs off)
Assigned project manager, responsibility, and authority level
Name and authority of the sponsor or other person(s) authorizing the project charter

5.3.3.2

Project Documents Updates

Project documents that may be updated include, but are not limited to:
Stakeholder register,
Requirements documentation, and
Requirements traceability matrix.

5.4Create WBS
1- Create WBS is the process of subdividing project deliverables
and project work into smaller, more manageable components.
The key benefit of this process is that it provides a structured
vision of what has to be delivered
2- The WBS is a hierarchical decomposition of the total scope of
work to be carried out by the project team to accomplish the
project objectives and create the required deliverables.
3- the lowest level of WBS components, which are called work
packages.

5.4.1

Create WBS: Inputs

5.4.1.1 Scope Management Plan

Described in Section 5.1.3.1. The scope management plan specifies
how to create the WBS from the detailed project scope statement and
how the WBS will be maintained and approved.

5.4.1.2

Project Scope Statement

Described in Section 5.3.3.1. The project scope statement

describes the work that will be performed and the work that is
excluded. It also lists and describes the specific internal or external
restrictions or limitations that may affect the execution of the project.

5.4.1.3

Requirements Documentation

Described in Section 5.2.3.1. Detailed requirements documentation is

essential for understanding what needs to be produced as the result of
the project and what needs to be done to deliver the project and its
final products.

5.4.1.4

Enterprise Environmental Factors

Described in Section 2.1.5. Industry-specific WBS standards, relevant

to the nature of the project, may serve as external reference sources for
creation of the WBS. For example, engineering projects may reference
ISO/IEC 15288 on Systems Engineering System Life Cycle Processes
[6], to create a WBS for a new project.

5.4.1.5

Organizational Process Assets

Described in Section 2.1.4. 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.4.2 Create WBS: Tools and Techniques

5.4.2.1 Decomposition
1- Decomposition is a technique used for dividing and subdividing
the project scope and project deliverables into smaller, more
manageable parts. The work package is the work defined at
the lowest level of the WBS for which cost and duration can
be estimated and managed.
2- generally involves the following activities:
Identifying and analyzing the deliverables and related work;
Structuring and organizing the WBS;

 Decomposing the upper WBS levels into lower-level detailed components;

Developing and assigning identification codes to the WBS components;
and
Verifying that the degree of decomposition of the deliverables is
appropriate.
A portion of a WBS with some branches of the WBS decomposed
down through the work package level is shown in Figure 5-11.

5.4.2.2 Expert Judgment

the final decomposition of the project scope into the discrete work
packages that will be used to effectively manage the work of the
project.
A WBS structure may be created through various approaches. Some
the popular methods include the top- down approach, the use
organization-specific guidelines, and the use of WBS templates.
bottom-up approach can be used during the integration
subcomponents.

of
of
A
of

Using phases of the project life cycle as the second level of

decomposition, with the product and project deliverables
inserted at the third level, as shown in Figure 5-12;
Using major deliverables as the second level of decomposition, as shown
in Figure 5-13; and
Incorporating subcomponents which may be developed by
organizations outside the project team, such as contracted
work. The seller then develops the supporting contract WBS as
part of the contracted work.
1- a hierarchical breakdown.
2- excessive decomposition
can lead to nonproductive
management effort, inefficient
use of resources, decreased efficiency in performing the work,
and difficulty aggregating data over different levels of the WBS.
3- Decomposition may not be possible for a deliverable or
subcomponent that will be accomplished far into the future.
The project management team usually waits until the
deliverable or subcomponent is agreed on, so the details of
the WBS can be developed. This technique is sometimes referred
to as rolling wave planning.
4- nothing is left out and no extra work is performed. This is
sometimes called the 100 percent rule.

5.4.3

Create WBS: Outputs

5.4.3.1

Scope Baseline

The scope baseline is the approved version of a scope

statement, work breakdown structure (WBS), and its associated WBS
dictionary, that can be changed only through formal change control
procedures and is used as a basis for comparison. It is a component of
the project management plan. Components of the scope baseline
include:
Project scope statement. The project scope statement
includes the description of the project scope, major
deliverables, assumptions, and constraints

WBS.
1- A control account is a management control point where
scope, budget, actual 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 should be
associated with only one control account. A control
account may include one or more planning packages.
A planning package is a work breakdown structure
component below the control account with known work
content but without detailed schedule activities.

WBS dictionary. The WBS dictionary is a document that

provides detailed deliverable, activity, and scheduling
information about each component in the WBS.

may include, but is not limited to:

Code of account identifier,
Description of work,
Assumptions and constraints,
Responsible organization,
Schedule milestones,
Associated schedule activities,
Resources required,
Cost estimates,
Quality requirements,
Acceptance criteria,
Technical references, and

 Agreement information.

5.5Validate Scope
Validate Scope is the process of formalizing acceptance of the
completed project deliverables. The key benefit of this process is that it
brings objectivity to the acceptance process and increases the
chance of final product, service, or result acceptance by validating each
deliverable.
The verified deliverables obtained from the Control Quality process
are reviewed with the customer or sponsor to ensure that they are
completed satisfactorily and have received formal acceptance of the
deliverables by the customer or sponsor.
The Validate Scope process former 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. Control Quality is generally
performed before Validate Scope, although the two processes may be
performed in parallel.

5.5.1 Validate Scope: Inputs

5.5.1.1 Project Management Plan
The scope baseline (Section 5.4.3.1) includes the approved version
of a scope statement, work breakdown structure (WBS), and its
associated WBS dictionary,

5.5.1.2

Verified Deliverables

Described in Section 8.3.3.3. Verified deliverables are project

deliverables that are completed and checked for correctness through the
Control Quality process.

5.5.2

Validate Scope: Tools and Techniques

5.5.2.1

Inspection

Inspection includes activities such as measuring, examining, and

validating to determine whether work and deliverables meet
requirements and product acceptance criteria.

5.5.2.2

Group Decision-Making Techniques

Described in Section 5.2.2.5. These techniques are used to reach a

conclusion when the validation is performed by the project team and
other stakeholders.

5.5.3

Validate Scope: Outputs

5.5.3.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 projects deliverables is forwarded to the
Close Project or Phase process (Section 4.6).

5.5.3.2 Change Requests

a change request for defect repair. The change requests are
processed for review and disposition through the Perform Integrated
Change Control process (Section 4.5).

5.5.3.3 Project Documents Updates

. Verified project documents may require approvals from the
customer or sponsor in the form of signatures or signoffs.

5.6 Control Scope

Control Scope is the process of monitoring the status of the project
and product scope and managing changes to the scope baseline. The
key benefit of this process is that it allows the scope baseline to be
maintained throughout the project.
. The uncontrolled expansion to product or project scope without
adjustments to time, cost, and resources is referred to as scope
creep. Change is inevitable; therefore some type of change control
process is mandatory for every project.

5.6.1 Control Scope: Inputs

5.6.1.1 Project Management Plan
Described in Section 4.2.3.1. The following information from the
project management plan is used to control scope:
Scope baseline. The scope baseline is compared to actual
results to determine if a change, corrective action, or
preventive action is necessary.
Scope management plan. Sections from the scope
management plan describe how the project scope will be
monitored and controlled.
Change management plan. The change management plan
defines the process for managing change on the project.
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. This plan is a
component of the project management plan and describes
how the project requirements will be analyzed, documented,
and managed.

5.6.2 Control Scope: Tools and Techniques

5.6.2.1 Variance Analysis
Variance analysis is a technique for determining the cause and
degree of difference between the baseline and actual performance.

5.6.3.1 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,
defect repairs, or enhancement requests. Change requests are
processed for review and disposition according to the Perform Integrated
Change Control process (Section 4.5).