Unit 3: Scope Management (Pmbok: Guide, Chapter 5)

Unit 3: Scope Management
(PMBOK® Guide, Chapter 5)
Scope management ensures that a project includes all the work required but only the
work required to complete the project successfully. In other words, proper scope
management carefully identifies what is and what is not included in the project. The
following six processes comprise scope management and course slide #3-1 also
provides an overview of scope management.
Major Processes
5.1 Plan Scope Management (creating a scope management plan that documents
how project scope will be defined, validated, and controlled)
5.2 Collect Requirements (defining and documenting stakeholders’ needs to meet
project objectives)
5.3 Define Scope (developing a detailed description of the project and product)
5.4 Create WBS (subdividing project deliverables into smaller components)
5.5 Validate Scope (formalizing acceptance of completed project deliverables)
5.6 Control Scope (monitoring status of the project and product scope, and managing
changes to the scope baseline)
There are two kinds of scope (PMBOK® Guide, p. 105):
• Product scope: The features and functions embodied in the product, service,
or result. Product scope is measured against the product requirements
(Sections 5.2 and 5.3: Collect Requirements and Define Scope).
• Project scope: The management activities required to deliver the product,
service, or result. Project scope is measured against the project
management plan (Section 4.2).
The scope baseline consists of the approved versions of the project scope statement,
the WBS (work breakdown structure), and the WBS dictionary. The approved scope
baseline should only be changed using formal change control procedures. The
approved baseline is the basis for deciding whether scope requirements are being met
(especially relevant during the processes for validating and controlling scope).
5.1 Plan Scope Management (PMBOK® Guide, p. 107)
The scope management plan documents how project scope will be defined, validated,
and controlled. In essence, it provides guidance on how the other five scope
management processes are to be accomplished.
© CMF Solutions and ESI July 2013 PMC:DJ4:EN:000 ver.2.0 3-1

Plan Scope Management
Inputs Tools Outputs
1. Project management plan 1. Expert judgment 1. Scope management plan

2. Project charter 2. Meetings 2. Requirements management plan
3. Enterprise environmental factors
4. Organizational process assets
Four Key Inputs for Plan Scope Management (PMBOK® Guide, p. 108):
1. Project Management Plan: The most recently approved subsidiary plans of

the project management plan (scope, schedule, cost, quality, human resource,
and so on) are used to help create the scope management plan. The information
in the project charter (next input) is also considered at this point.
2. Project Charter: Described in the PMBOK® Guide, p. 66, Section 4.1, the
charter provides high-level project and product requirements. As such, it forms a
starting point for the development of detailed requirements.
3. Enterprise Environmental Factors: Environmental factors that may

influence scope management planning include:
• Organizational culture
• Infrastructure (resource availability)
• Personnel administration
• Marketplace conditions
4. Organizational Process Assets: Organizational process assets that may

influence scope management planning include:
• Policies and procedures

• Historical information and lessons learned
3-2 PMC:DJ4:EN:000 ver.2.0 © CMF Solutions and ESI July 2013

Two Key Tools for Plan Scope Management (PMBOK® Guide, p. 109):
1. Expert Judgment: Used to elicit information from knowledgeable and

experienced parties.
2. Meetings: The project manager, sponsor, selected team members, and other
selected stakeholders may attend meetings to develop the scope management
plan.
Two Key Outputs for Plan Scope Management (PMBOK® Guide, p. 109):
1. Scope Management Plan: Is part of the overall project management plan

and describes how scope will be defined, monitored, controlled, and verified.
Components of the scope management plan include:
• Process for preparing a detailed scope statement

• Process for creating the WBS from the scope statement
• Process for maintaining the WBS
• Process for formal acceptance of project deliverables
• Process for how scope changes will be handled
2. Requirements Management Plan: Documents how requirements will be

analyzed, documented, and continuously managed throughout the project. A
requirements management plan may include, but is not limited to:
• How requirements will be planned, tracked, and reported

• Configuration management process for handling changes to the
requirements
• Requirements prioritization processes
• Product metrics
• Traceability structure: which requirements will be traced and to which
other requirements documents
5.2 Collect Requirements (PMBOK® Guide, p. 110)
Collecting requirements involves determining, documenting, and managing

stakeholders’ needs and requirements. These requirements must be captured in
sufficient detail to be measured during project execution. Requirements become the
foundation for many other vital project management activities:

• Requirements become the foundation of the WBS.

• Cost, schedule, quality, and procurement plans are built upon these
requirements.
PMI groups requirements into the following categories:
• Business requirements: Higher-level needs of the organization such as
business opportunities and purpose of the project.
• Stakeholder requirements: Perceived needs of specific stakeholders.
Includes impacts to various organizational areas and stakeholder reporting
requirements.
• Solution requirements: Features, functions, and characteristics of the
product, service, or result that will satisfy business and stakeholder
requirements (similar to the notion of product scope mentioned at the
beginning of the unit). Includes functional, non-functional, technology,
compliance, support, training, quality, and reporting requirements.
• Project requirements: Levels of service, performance, and safety. Also
includes acceptance criteria and delivery requirements.
• Transition requirements: Activities such as training and data conversion to
move from the previous “as-is” state to the future “to-be” outcome.
Collect Requirements
1. Scope management plan 1. Interviews 1. Requirements documentation

2. Requirements management 2. Focus groups 2. Requirements traceability matrix
plan 3. Facilitated workshops
3. Stakeholder management 4. Group creativity techniques
plan 5. Group decision-making
4. Project charter techniques
5. Stakeholder register 6. Questionnaires and surveys
7. Observations
8. Prototypes
9. Benchmarking
10. Context diagrams
11. Document analysis

Five Key Inputs for Collect Requirements (PMBOK® Guide, p. 113):
1. Scope Management Plan: Clarifies which types of requirements need to be

collected for the specific project.
2. Requirements Management Plan: Identifies the processes to be used in

defining and documenting stakeholder needs. Specific elements of the
requirements were provided in the outputs to Plan Scope Management, Section
5.1.3.2.
3. Stakeholder Management Plan: Established in Section 13.2.3.1, the

stakeholder management plan identifies required levels of stakeholder
communication and stakeholder engagement.
4. Project Charter: Described in PMBOK® Guide, p. 66, Section 4.1, the charter
provides high-level project and product requirements. As such, it forms a starting
point for the development of detailed requirements.
5. Stakeholder register: Described in Section 13.1, the stakeholder register

identifies key stakeholders who can provide information needed to develop
detailed requirements.
Eleven Key Tools for Collect Requirements (PMBOK® Guide, p. 114):
1. Interviews: Used to elicit information from stakeholders by talking to them

directly. One-on-one or group interviews with appropriate subject matter experts
are used to identify features and functions of desired deliverables.
2. Focus Groups: Interactive, conversational discussions guided by trained

moderators with pre-selected stakeholders and subject matter experts. The
purpose of this exercise is to document stakeholder expectations and attitudes
about a proposed product, service, or result.
3. Facilitated Workshops: Workshops are interactive, group-oriented

discussions aimed at quickly defining cross-functional requirements and,
hopefully, reconciling stakeholder differences. Well-facilitated sessions can build
trust, improve communications, and uncover issues more quickly than numerous
individual sessions. The PMBOK® Guide provides two examples:
• Joint Application Development (JAD): Sometimes called Joint

Application Design, these joint sessions bring users and developers
together to improve requirements in the software development industry.

• Quality Function Deployment (QFD): QFD is used by engineers to

develop requirements for new product developments. The process first
determines customer needs, then prioritizes them, and establishes goals
for achieving them. User stories describe the stakeholder who benefits
(role), what the stakeholder needs to accomplish (goal), and the
resulting benefit (motivation).
4. Group Creativity Techniques: The following examples are all ways for
groups to generate ideas about any desired topic. In this case, the groups are
identifying and documenting requirements.
• Brainstorming: A group-oriented technique for quickly generating
ideas about both project and product requirements.
• Nominal Group Technique: An enhanced version of brainstorming
which includes voting and prioritizing the group’s ideas.
• Idea/Mind Mapping: The non-linear diagramming of different ideas in a
group into a single map for the purpose of highlighting agreements and
differences and also generating new ideas.
• Affinity Diagram: A technique for sorting a large number of detailed,
specific ideas into logical groups.
• Multicriteria Decision Analysis: Uses a decision matrix to establish
and apply criteria such as risk levels and uncertainty.
5. Group Decision-Making Techniques: Assessment of multiple alternatives

using one of the following decision techniques:
• Unanimity: Everyone (100%) agrees on a course of action.
• Majority: A decision made with support from more than 50% of the
group.
• Plurality: Decision determined by the largest voting block in the group
(even if it represents less than 50%).
• Dictatorship: One individual makes the decision for the group (much
like the autocratic form of leadership).
6. Questionnaires and Surveys: Written sets of questions that help reach large
audiences quickly and also enable statistical analysis of data.
7. Observations: Directly viewing individuals performing project activities and

carrying out processes (sometimes called “job shadowing”). This technique is
especially helpful when people are experiencing difficulty in articulating
requirements.

8. Prototypes: The use of mock-ups and physical working models to assist

stakeholders in progressively elaborating requirements. Rapid prototyping is a
technique used specifically for elaborating requirements during the development
phase of a project.
9. Benchmarking: Compares planned or actual practices to other organizations

to 1) generate ideas for improvement and 2) provide standards for measuring
performance.
10. Context Diagrams: Context diagrams are visual depictions of product scope
such as processes, equipment or computer systems. The diagram shows how
various entities (people and other systems) interact to produce inputs and
outputs.
11. Document Analysis: A variety of documents may contain information

relevant to project requirements, including but not limited to:
• Business plans and marketing literature
• RFPs (requests for proposal), agreements (contracts, MOAs, etc.)
• Policy, procedure, and regulatory documentation
• Laws, codes, or ordinances
• Business process documentation
Two Key Outputs for Collect Requirements (PMBOK® Guide, p. 117):
1. Requirements Documentation: Describes how individual requirements meet

business needs. Requirements often start as high-level information and become
progressively more detailed as more becomes known. Before requirements are
accepted as baselines, they should be measureable, testable, traceable,
complete, and acceptable to stakeholders. The format may be a simple listing of
requirements categorized by stakeholders; or a more detailed, elaborate
approach including an executive summary, detailed descriptions, and
attachments. As previously described on study guide, p. 4, requirements may be
grouped into the following categories:
• Business
• Stakeholder
• Solution (product, service, or result)
• Project
• Transition

2. Requirements Traceability Matrix: A table that links each requirement to a

business need or project objective. The matrix provides a way to track
requirements during the project and also provides assistance in checking that
requirements have been met for purposes of project closure. The matrix must be
updated when there are changes to requirements. The tracing matches
requirements to:
• Business needs or opportunities

• Project objectives
• Project scope and WBS deliverables
• Product design and development
• Testing of deliverables
Finally, high-level requirements are matched to the more detailed requirements

that follow. An example of a traceability matrix is shown in Figure 5-6, p. 119,
PMBOK® Guide.
5.3 Define Scope (PMBOK® Guide, p. 120)
Scope definition produces a written, detailed scope statement that is crucial to project
success. This statement represents an agreement between the project team and the
customer and defines which requirements collected earlier will actually be included in
the scope and which will be excluded. The project team and appropriate stakeholders
conduct a needs assessment and use it as the basis to develop written project
requirements. Assumptions, constraints, and risks are identified and validated as
necessary. The level of uncertainty (difficulty) in defining scope will naturally be greater
with more complex projects.
Define Scope
1. Scope management plan 1. Expert judgment 1. Project scope statement

2. Project charter 2. Product analysis 2. Project documents updates
3. Requirements documentation 3. Alternatives generation
4. Organizational process assets 4. Facilitated workshops

Four Key Inputs for Define Scope (PMBOK® Guide, p. 121):
1. Scope Management Plan: Described previously, this plan establishes how

project scope will be developed, monitored, and controlled.
2. Project Charter: The high-level project description in the charter is used as a

basis for developing the detailed project scope statement.
3. Requirements Documentation: Produced by the previous process as

described in Section 5.2.
4. Organizational Process Assets: Organizational Process Assets that may

affect detailed scope definition include:
• Existing procedures and templates for project scope statements

• Project files from previous projects
• Lessons learned from previous phases or similar projects
Four Key Tools for Define Scope (PMBOK® Guide, p. 122):
1. Expert Judgment: At this step, expert judgment with respect to technical

details is especially relevant.
2. Product Analysis: This tool is helpful when the project is producing a product
rather than a service or other result. These techniques help translate project
objectives into measurable deliverables and requirements. Examples of these
techniques include product breakdown, requirements analysis, systems
engineering, value engineering, and value analysis. Project engineers use these
techniques to better understand and develop product requirements.
3. Alternatives Generation: Techniques such as brainstorming, lateral thinking

(“thinking outside the box”), and analysis of alternatives are used to identify
different possible approaches to the project.
4. Facilitated Workshops: Described previously as a tool of Collect

Requirements, PMBOK® Guide, Section 5.2.
Two Key Outputs for Define Scope (PMBOK® Guide, p. 123):
1. Project Scope Statement: The scope statement provides a detailed

description of project deliverables and the work required to create those
deliverables. Importantly, it may identify specific exclusions from project scope,

which helps improve the accuracy of stakeholder expectations. The scope

statement:
• Provides a common understanding of project scope for key stakeholders

• Describes major objectives
• Supports subsequent detailed planning
• Guides execution of the project work and provides a basis for making
future project decisions
• Provides a baseline to evaluate whether requested changes are within
the original scope or not
The scope statement typically includes directly or by reference:
• Product scope description: Characteristics of the product, service, or

result. The characteristics are subject to progressive elaboration (less
detail in earlier phases and more detail in later phases).
• Product acceptance criteria: Defines the process and explicit criteria
for acceptance of the finished work.
• Project deliverables: Includes major product deliverables and project
management deliverables such as reports and documentation.
• Project exclusions: States explicitly what is excluded from the
project.
• Project constraints: Lists any restrictions on the project such as
funding limits, imposed deadlines, or limitations on work calendars for
the team (e.g. can’t work in client facility at night)
• Project assumptions: Factors believed to be true so that planning can
be completed. The analysis also considers the resulting impact in the
event that an assumption proves to be incorrect. Assumptions
potentially pose risks both because any assumption might be incorrect
and because they are dealing with unknowns. The assumptions at this
point in the project life cycle are usually more numerous and detailed
than those listed earlier in the charter.
2. Project Documents Updates: Specific documents that may be updated

include:
• Stakeholder register
• Requirements documentation
• Requirements traceability matrix

5.4 Create WBS (PMBOK® Guide, p. 125)
The WBS is a hierarchical decomposition of the work to be accomplished. The

WBS organizes and defines the total scope of the project. Work that is not in the
WBS is outside the scope of the project!
Key points:
• The WBS subdivides the work into smaller components (this process is
called decomposition). Each descending level of the WBS represents an
increasingly detailed description of the work.
• Tasks (items) at the lowest level of the WBS are called work packages.
• The work package is the level at which the work can be adequately
scheduled, cost estimated, monitored, and controlled. Accurate work
packages are a major factor in accurate project planning.
• The recommended size of a work package is 80 hours.
• A detailed description of each work package is contained in a WBS
dictionary.
• A code of accounts provides a unique numerical identifier for each task in
the WBS. Similarly, a chart of accounts groups project expenses into
specific categories for the accounting system in the performing
organization. Even though this distinction exists, some people use the
terms interchangeably.
• An OBS (organizational breakdown structure) shows which work
packages have been assigned to which organizational units.
• An important benefit of decomposing the project into smaller components
is that project participants are forced to carefully think through all aspects
of the pending effort. This process reduces the chance that activities
might be overlooked during the initial planning.
Create WBS
1. Scope management plan 1. Decomposition 1. Scope baseline

2. Project scope statement 2. Expert judgment 2. Project documents updates
3. Requirements documentation
4. Enterprise environmental factors
5. Organizational process assets

Five Key Inputs for Create WBS (PMBOK® Guide, p. 127):
1. Scope Management Plan: Specifies how to create the WBS from the
detailed scope statement (previous process) and how to maintain the WBS
throughout the project.
2. Project Scope Statement: Described in PMBOK® Guide, Section 5.3.3.1, the

scope statement identifies major project deliverables which, in turn, may assist in
developing the high-level portion of the WBS.
3. Requirements Documentation: Establishes objectives and basic

requirements that make it possible to break the work into smaller components.
4. Enterprise Environmental Factors: Industry-specific standards for

developing a WBS are available in some instances, e.g., engineering projects
may use ISO/IEC 15288 which provides guidelines for systems engineering.

affect creation of the WBS include:
• Existing procedures and templates for the WBS

• Project files from previous projects
• Lessons learned from previous projects
Two Key Tools for Create WBS (PMBOK® Guide, p. 128):
1. Decomposition: The process of breaking project deliverables into smaller

and smaller pieces, in other words, finding the level of detail at which tasks can
be adequately planned and managed. Again, the desired level of detail is the
work package and is the level at which the cost and schedule for the work can be
reliably estimated. Be familiar with the following key factors about
decomposition:
• Generally, greater levels of decomposition improve the ability to plan,

manage, and control the work.
• However, excessive decomposition can lead to non-productive
management (tracking and reporting at an excessive level of detail).
• The WBS represents all work to be accomplished:
• Project management work is included in the WBS.

• When all detailed work is rolled up into higher levels, all the
work should be accounted for (PMI refers to this as the 100%
rule).
• Work should be decomposed to a level at which:
• It can be accurately estimated.
• It is not logical to subdivide it further.
• Individual responsibility can be assigned.
• Different deliverables can have different levels of decomposition (one
deliverable may be at level 4 while another is at level 6). Course slide
#3-5 shows an example.
The PMBOK® Guide indicates that the first level of decomposition can be
displayed in the following ways:
• Major deliverables
• Major subprojects done by organizations outside the project team
• Phases of the project life cycle
• Hybrid mixtures of all the above (e.g., phases at the first level of
decomposition and then deliverables within each phase)
2. Expert Judgment: Technical knowledge of the work is helpful in determining

the appropriate level of decomposition. Also, templates are often available and
may represent previous experience on similar projects. PMI has a document
called the Practice Standard for Work Breakdown Structures and other industry-
specific WBS guides also exist.
The WBS may be displayed variously as an outline (appropriately indented task

list in your project management software), an organization chart, or any other
hierarchical method so that the levels of detail are visible. The correctness of the
decomposition must be verified by those who understand the work sufficiently.
Two Key Outputs for Create WBS (PMBOK® Guide, p. 131):
1. Scope Baseline: The scope baseline includes the following components:
• Project Scope Statement: The approved detailed scope statement

from the define scope process (identifies project scope, major
deliverables, assumptions, and constraints).

• WBS:
The WBS is a hierarchical decomposition of the total scope of the
work and includes:
Work packages: the lowest level of detail shown in the WBS

and is also the level at which individual responsibility for the
work is assigned. Work packages must be assigned to a control
account.
Control accounts: also historically referred to as cost accounts,
is the lowest level in the WBS at which organizational
responsibility is assigned. Control accounts are management
control points where cost, schedule, and scope data are
summarized and compared to earned value for performance
management. Control accounts contain one or more work
packages and may also contain planning packages.
Planning packages: a WBS component below the control
account with known work content but lacking detailed schedule
activities associated with work packages. Some practitioners
use planning packages for estimating work farther in the future
(rolling wave planning).
Code of accounts: provides a unique numerical identifier for
each WBS activity. Some people use the term “chart of
accounts” interchangeably.
Note: The numerical identifiers provide a mechanism for

summarizing cost, schedule, and resource information.
• WBS dictionary: A companion document to the WBS, containing a

detailed description of each work package and including information such
as:
Description of the work and technical requirements

Estimated cost and duration, list of schedule milestones
Responsible resources, deliverables
Predecessor activities (for sequencing the work)
Code of accounts identifier (the numbering system)
Acceptance criteria and quality requirements

2. Project Documents Updates: Approved change requests may require

updates to the requirements documentation.
See course slides #3-2 through #3-6 for more WBS information.
5.5 Validate Scope (PMBOK® Guide, p. 133)
Scope validation is the process of obtaining formal acceptance of the project scope by
stakeholders. It involves reviewing work results to see whether tasks were completed
correctly. If a project is terminated early, scope verification should document the extent
of the work completed. Scope verification differs from quality control in that verification
is primarily concerned with acceptance of the work whereas quality control is primarily
concerned with correctness of the work. Quality control is usually performed slightly
ahead of verification, but the two processes may overlap somewhat.
Validate Scope
1. Project management plan 1. Inspection 1. Accepted deliverables

2. Requirements documentation 2. Group decision-making 2. Change requests
3. Requirements traceability matrix techniques 3. Work performance information
4. Verified deliverables 4. Project documents updates
5. Work performance data
Five Key Inputs for Validate Scope (PMBOK® Guide, p. 134):
1. Project Management Plan: The project management plan contains the

scope baseline which identifies all the work that must be performed. This
process verifies that the required work has, in fact, been completed correctly.
Components of the project management plan that may be used at this point
include:
• Scope management plan: The scope management plan specifies how

formal acceptance of completed deliverables will be obtained.
• Scope baseline: The scope baseline contains the scope statement
(product description and product acceptance criteria), the WBS
(deliverables and associated decomposition), and the WBS dictionary
(detailed description for each work package).

2. Requirements Documentation: Lists all requirements and acceptance

criteria for the project to be considered complete.
3. Requirements Traceability Matrix: Described in PMBOK® Guide, Section

5.2.3.2, this matrix links requirements to their origin (business need or
opportunity).
4. Verified Deliverables: Verified deliverables have been completed and

checked for correctness as part of the Control Quality process.
5. Work Performance Data: Described in Section 4.3.3.2, data collected at this

point may include:
• Number of nonconformities and degree of compliance

• Severity of the nonconformities
Two Key Tools for Validate Scope (PMBOK® Guide, p. 135):
1. Inspection: Activities such as measuring, examining, and validating

undertaken to determine whether work results conform to requirements.
Alternative names for inspection include reviews, product reviews, audits, and
walkthroughs.
2. Group Decision-Making Techniques: Described previously as part of

Collect Requirements, these techniques help the project team and other
stakeholders reach conclusions during validation decisions (unanimity, majority,
plurality, and dictatorship).
Four Key Outputs for Validate Scope (PMBOK® Guide, p. 135):
1. Accepted Deliverables: Accepted deliverables have met the acceptance

criteria and are formally signed off by an authorized person. The formal
documentation is forwarded to the Close Project or Phase process.
2. Change Requests: Deliverables that are not accepted must be documented

as such, including the reasons for non-acceptance. In some cases, those
deliverables may require a change request for defect repair. As usual, these
change requests are processed using integrated change control.
3. Work Performance Information: Relevant information would include 1)

which tasks have started and the extent of progress and 2) which activities have
finished and have been accepted.

4. Project Documents Updates: Any documents that describe the product or

report on actual status of the work may be updated.
5.6 Control Scope (PMBOK® Guide, p. 136)
This process monitors the status of project and product scope and also manages any
changes to the scope baseline. This process uses integrated change control to deal
with all requested changes and recommended corrective or preventive actions. As
described in the integrated change control process, scope change control is concerned
with:
• Assuring that requested changes and recommended corrective or preventive

actions are processed through integrated change control (uncontrolled
changes are known as “scope creep”).
• Managing changes when they occur (following established processes).
Establishing proper documentation, tracking, and approval levels.
• Always evaluating changes and never automatically accepting or rejecting.
Control Scope
1. Project management plan 1. Variance analysis 1. Work performance information

2. Requirements documentation 2. Change requests
3. Requirements traceability matrix 3. Project management plan updates
4. Work performance data 4. Project documents updates
5. Organizational process assets 5. OPA updates
Five Key Inputs for Control Scope (PMBOK® Guide, p. 138):
1. Project Management Plan: The scope baseline is the object being controlled
and it consists of the scope statement, WBS, and WBS dictionary. Other
relevant portions of the project management plan include the scope, change,
configuration, and requirements management plans.
2. Requirements Documentation: Described in Section 5.2.3.1. Requirements

should ideally be measurable, testable, traceable, consistent, complete, and
acceptable to stakeholders.

3. Requirements Traceability Matrix: Described in Section 5.2.3.2. The

traceability is useful in understanding the potential effect of changes in
requirements upon project needs/objectives. Recall that this matrix links each
requirement to a business opportunity or need.
4. Work Performance Data: Relevant work performance data at this point may
include the number of change requests received, number of requests accepted,
and the number of deliverables completed.

affect scope control include:
• Existing formal and informal procedures for scope control

• Monitoring and reporting methods
One Key Tool for Control Scope (PMBOK® Guide, p. 139):
1. Variance Analysis: Used to assess the magnitude of variations from the

planned scope baseline and decide whether corrective action is necessary.
Five Key Outputs for Control Scope (PMBOK® Guide, p. 139):
1. Work Performance Information: Addresses how project scope is

progressing compared to the scope baseline. The information includes scope
variances, scope changes, and forecasts of future scope performance.
2. Change Requests: If change requests occur during scope control activities,

they should be processed using integrated change control. Change requests
may result in preventive or corrective action, defect repair, or enhancement
requests. Change requests may either expand or reduce the scope of the
project.
Change requests are often the result of:

• An external event (change in a regulation)
• An error in defining the scope (omitted a required feature of the
product or omitted required tasks)
• A value-adding change (a way is found to do something better, faster,
or cheaper; for example, new technology becomes available). Value
analysis or value engineering are common examples.

3. Project Management Plan Updates: Approved changes may affect the

project triple constraint and, accordingly, the scope, cost, and schedule baselines
should be updated as required.
4. Project Documents Updates: Specific documents that may require updating

because of scope changes include requirements documentation and the
requirements traceability matrix.
5. Organizational Process Assets Updates: The historical database should be

updated with the causes of variances that have occurred, the corrective action
employed, and any other lessons learned associated with scope change control.
Other Topics: There are no additional topics for this chapter!

This page intentionally blank

Self-Study
Drill Practice: Scope Management
Question Answer
1. Product specifications should be 1. project engineers or technical staff

developed by ______. (p. 3-9, Tool #2)
All page references are to the study guide or
course slides.
2. What is Define Scope? 2. Developing a detailed description of the

project and product. Results in a detailed,
written scope statement (p. 3-8).
3. As project complexity increases, what 3. It will probably increase (p. 3-8).

will happen to the level of uncertainty in
defining the project scope?
4. What is the difference between product 4. Product scope is the features and
scope and project scope? functions designed into the product or
service (measured against product
requirements). Project scope is
management activities performed by the
team (measured against the project
management plan) (p. 3-1).
5. What is the primary tool for scope 5. Inspection (p. 3-16)

validation?
6. What is scope creep? 6. Scope creep is a common name used

for uncontrolled changes that are not
managed in accordance with the
guidelines of scope control (p. 3-17).
7. What is a WBS dictionary? 7. It contains a detailed description of

each work package (pp. 3-11/14).
8. As used in a WBS, what does the term 8. A cost category that represents the
“cost account” mean? work assigned to a single responsible
organizational unit, i.e., the lowest level in
the WBS at which organizational
responsibility is assigned. Also called a
control account (p. 3-14).

9. What is the WBS numbering system 9. Code of Accounts or Chart of Accounts

called and what does it provide?
Provides:
1. Allocation of budget to specific tasks
2. Tracking of performance/spending
against specific work packages (tasks)
3. Identifying the level of detail for
specific tasks (pp. 3-11/14)
10. What role do stakeholders play in 10. Defining stakeholders’ needs is the
collecting requirements? primary purpose of the process called
Collect Requirements. Knowing who the
stakeholders are and interviewing them in
various ways is how requirements are
documented (pp. 3-3 and 3-5, inputs #3 & #5).
11. What are the tools of collect 11.

requirements? Interviews and Focus groups
Facilitated workshops
Group creativity techniques
Group decision-making techniques
Questionnaires and surveys
Observations
Prototypes
Benchmarking
Context diagrams
Document analysis (pp. 3-5 to 3-7).
12. How does an OBS differ from a WBS? 12. OBS = Organizational breakdown
structure and is used to show which work
elements (tasks) have been assigned to
which organizational units (p. 3-11)
13. Activities at the lowest level of the 13. work packages (pp. 3-11/13)
WBS are referred to as ______.
14. A recommended size for work 14. 80 hours (p. 3-11)

packages is ______.
15. What is scope validation? 15. The process of formalizing

acceptance of completed project
deliverables (p. 3-15).

16. What is the difference between scope 16. Scope validation is primarily
validation and quality control? concerned with acceptance of the work;
quality control is concerned with the
correctness of the work (p. 3-15).
17. What is scope control (the formal 17. Monitoring the status of the project
name of the process is control scope)? and product scope and managing changes
to the scope baseline (p. 3-17)
18. What is a WBS? 18. A hierarchical decomposition of the

work to be accomplished and defines the
total scope of the project -–work not in the
WBS is outside the scope of the project
(p. 3-11).
19. What is the tool for control scope? 19.

Variance analysis (p. 3-18)
20. What is the scope management plan? 20. Documents how project scope will be
defined, validated, and controlled (pp. 3-1/3)
21. What two important issues does 21. As part of control scope:
performance measurement deal with?
a ) Identifying the magnitude of variances
(plan versus actual)
b) Deciding whether corrective action is

needed (p. 3-18)
22. Change requests are outputs for 22. Validate scope and control scope.
which two scope management processes? Change requests may be issued as a
result of either of these activities and
should be handled using integrated
change procedures (pp. 3-16/18).
23. Collecting requirements is 23. Defining and managing stakeholder

fundamentally about ______. expectations (p. 3-3).
24. The subdivision of project deliverables 24. decomposition (pp. 3-11/12)

into smaller components is called ______.
25. What are the inputs for collect 25. The scope management plan,
requirements? requirements management plan,
stakeholder management plan, project
charter and stakeholder register (p. 3-5).

26. What is the Code of Accounts and 26. A numbering system used to identify
what is another name for it? each element of the WBS. Also known as
a Chart of Accounts (pp. 3-11/14).
27. What is a requirements traceability 27. A table that links each requirement to
matrix? its origin such as business needs or
opportunities, project goals, etc. (p. 3-8)
28. What is the scope baseline composed 28. The scope statement, the WBS, and
of? the WBS dictionary (pp. 3-13/14).
29. What is alternatives generation and 29. Alternatives generation is a tool of

what is it used for? define scope and is used to ensure that all
approaches to doing the work have been
considered. The PMBOK® Guide, p. 123,
identifies brainstorming, lateral thinking,
and analysis of alternatives as examples
of how to perform alternatives generation.
(p. 3-9).
30. Changes in the scope may affect the 30. scope, schedule, and cost. (p. 3-19,
other components of the triple constraint. output #3, control scope)
The triple constraint of project
management includes __________.

Unit 3: Scope Management (Pmbok: Guide, Chapter 5)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 3: Scope Management (Pmbok: Guide, Chapter 5)

Uploaded by

Copyright:

Available Formats

Unit 3: Scope Management

(PMBOK® Guide, Chapter 5)

There are two kinds of scope (PMBOK® Guide, p. 105):

5.1 Plan Scope Management (PMBOK® Guide, p. 107)

© CMF Solutions and ESI July 2013 PMC:DJ4:EN:000 ver.2.0 3-1

Plan Scope Management

Inputs Tools Outputs

1. Project management plan 1. Expert judgment 1. Scope management plan

1. Project Management Plan: The most recently approved subsidiary plans of

3. Enterprise Environmental Factors: Environmental factors that may

4. Organizational Process Assets: Organizational process assets that may

• Policies and procedures

3-2 PMC:DJ4:EN:000 ver.2.0 © CMF Solutions and ESI July 2013

1. Expert Judgment: Used to elicit information from knowledgeable and

1. Scope Management Plan: Is part of the overall project management plan

• Process for preparing a detailed scope statement

2. Requirements Management Plan: Documents how requirements will be

• How requirements will be planned, tracked, and reported

5.2 Collect Requirements (PMBOK® Guide, p. 110)

Collecting requirements involves determining, documenting, and managing

© CMF Solutions and ESI July 2013 PMC:DJ4:EN:000 ver.2.0 3-3

• Requirements become the foundation of the WBS.

Inputs Tools Outputs

1. Scope management plan 1. Interviews 1. Requirements documentation

3-4 PMC:DJ4:EN:000 ver.2.0 © CMF Solutions and ESI July 2013

Five Key Inputs for Collect Requirements (PMBOK® Guide, p. 113):

1. Scope Management Plan: Clarifies which types of requirements need to be

2. Requirements Management Plan: Identifies the processes to be used in

3. Stakeholder Management Plan: Established in Section 13.2.3.1, the

5. Stakeholder register: Described in Section 13.1, the stakeholder register

Eleven Key Tools for Collect Requirements (PMBOK® Guide, p. 114):

1. Interviews: Used to elicit information from stakeholders by talking to them

2. Focus Groups: Interactive, conversational discussions guided by trained

3. Facilitated Workshops: Workshops are interactive, group-oriented

• Joint Application Development (JAD): Sometimes called Joint

© CMF Solutions and ESI July 2013 PMC:DJ4:EN:000 ver.2.0 3-5

• Quality Function Deployment (QFD): QFD is used by engineers to

5. Group Decision-Making Techniques: Assessment of multiple alternatives

7. Observations: Directly viewing individuals performing project activities and

3-6 PMC:DJ4:EN:000 ver.2.0 © CMF Solutions and ESI July 2013

8. Prototypes: The use of mock-ups and physical working models to assist

9. Benchmarking: Compares planned or actual practices to other organizations

11. Document Analysis: A variety of documents may contain information

Two Key Outputs for Collect Requirements (PMBOK® Guide, p. 117):

1. Requirements Documentation: Describes how individual requirements meet

© CMF Solutions and ESI July 2013 PMC:DJ4:EN:000 ver.2.0 3-7

2. Requirements Traceability Matrix: A table that links each requirement to a

• Business needs or opportunities

Finally, high-level requirements are matched to the more detailed requirements

5.3 Define Scope (PMBOK® Guide, p. 120)

Inputs Tools Outputs

1. Scope management plan 1. Expert judgment 1. Project scope statement

3-8 PMC:DJ4:EN:000 ver.2.0 © CMF Solutions and ESI July 2013

Four Key Inputs for Define Scope (PMBOK® Guide, p. 121):

1. Scope Management Plan: Described previously, this plan establishes how

2. Project Charter: The high-level project description in the charter is used as a

3. Requirements Documentation: Produced by the previous process as

4. Organizational Process Assets: Organizational Process Assets that may

• Existing procedures and templates for project scope statements

Four Key Tools for Define Scope (PMBOK® Guide, p. 122):

1. Expert Judgment: At this step, expert judgment with respect to technical

3. Alternatives Generation: Techniques such as brainstorming, lateral thinking

4. Facilitated Workshops: Described previously as a tool of Collect

Work packages: the lowest level of detail shown in the WBS

Description of the work and technical requirements