The document outlines the six processes of project scope management, which include planning, collecting requirements, defining scope, creating a work breakdown structure, validating scope, and controlling scope. It emphasizes the importance of clear requirements to prevent scope creep and describes various techniques for collecting and documenting requirements. Additionally, it details the steps for managing both product and project scope to ensure all defined work is completed as planned.

1. Project Scope
Management
Knowledge
Area
6 Processes of Scope
Management in a Project

2. Project Scope
– Scope defines what work is required and
managing scope ensures that the defined
work is completed and only the defined work

3. The Project
Scope
Creates boundaries for the work
that will be performed on a
project
Scope relies on clear and
detailed requirements to help
avoid scope creep
There are six processes to the
Project Scope Management
Knowledge Area

4. Gold Plating / Scope
Creep
– Gold Plating is the process of delivering more than what is
required in the scope
– In many projects, customers will ask for things and insist
that they aren’t change requests, the Project Manager
must ensure that these requests are evaluated and will
not impact the scope
– Changes to the scope must go through a change control
process

5. Product and
Project Scope
PRODUCT SCOPE:
• Product scope are those
requirements that relate to the
output or the product that the
project produces
PROJECT SCOPE:
• Project scope is the work/activities
that the project team will perform in
order to deliver the work output or
the product

6. Overview of Project Scope
Management
6 Processes of Project Scope
Management
• 5.1 Plan Scope Management
• 5.2 Collect Requirements
• 5.3 Define Scope
• 5.4 Create WBS
• 5.5 Validate Scope
• 5.6 Control Scope
Exists in only two Project
Management Process Groups
• Planning
• Monitoring & Controlling

7. Process Groups and Project
Scope Management
• 5.1 Plan Scope Management
• 5.2 Collect Requirements
• 5.3 Define Scope
• 5.4 Create WBS
Planning
• 5.5 Validate Scope
• 5.6 Control Scope
Monitoring
& Controlling

8. 5.1 Plan Scope
Management
Belongs in the Planning Project Process Group

9. 5.1 Plan Scope Management
Plan Scope Management
Explains how the scope will be validated and
controlled
Process of creating a scope management plan
Outputs:
Scope Management Plan
Requirements Management Plan

10. Scope Management Plan
– Contains the process for defining the scope, how the scope
will be created, and how it will be controlled and verified
– Part of the Project Management plan and is used as in input
in creating the Project Management plan as part of the
Integration processes
– Facilitates the creation of the Work Breakdown Structure
(WBS)
– Describes the change request process

11. Requirements
Management Plan
– Describes how requirements will be collected
and documented
– Includes the explanation on planning,
tracking, and reporting of requirements
– Instructs on how to handle conflicting
requirements from stakeholders

12. 5.2 Collect
Requirements
Belongs in the Planning Project Process Group

13. 5.2 Collect Requirements
Belongs in the
Planning Project
Process Group
The main activity
of gathering the
requirements
from stakeholders
Should contain the
details of the
requirement

14. Collecting Requirements -
Techniques
INTERVIEWING:
• Meeting with
stakeholders to
question them
about their
requirements
FOCUS GROUPS:
• Meeting with
stakeholders within
a specific
area/realm; like a
user group, or
residents of an
impacted area
WORKSHOPS:
• Controlled or
facilitated meeting
to bring various
stakeholders
together to help
elicit requirements;
often through a
process designed to
help them think or
brainstorm ideas
BRAINSTORMING:
• A collaborative
process where
stakeholders work
together to
generate ideas and
discuss them with
each other in the
hopes of stimulating
more ideas

15. Collecting
Requirements
- Techniques
AFFINITY
DIAGRAM:
Group early ideas to
generate more specific
requirements
Assist in defining risks
with a group of
requirements
DELPHI METHOD:
Anonymous method for
collecting requirements
and refining them
Requests for
information are sent to
select stakeholders; As
ideas are collected the
requests are compiled
and sent to the
stakeholders again -
The process is repeated
until requirements are
narrowed down to the
most important items a
consensus is reached
MIND MAPPING:
Diagram ideas to help
classify information
This helps generate
new ideas
GROUP DECISION
MAKING:
Requirements are
evaluated by a group of
stakeholders and ideas
are debated

16. Collecting Requirements -
Techniques
SURVEYS:
• If interviewing is
cumbersome to the
large number of
stakeholders
• Questions are sent
out to stakeholders
asking them for ideas
OBSERVATION:
• Watch users to
identify possible
requirements
• This can be
particularly useful for
replacing old
software, process
improvement
projects, or
determining most
used features in a
product
PROTYPES:
• A light-weight model
used to generate
feedback from
stakeholders
NOMINAL GROUP
TECHNIQUE:
• Stakeholders rank the
ideas for
requirements
• Highest rank items
gain priority
• Can be used within
the brainstorming
requirements
collection to refine
ideas

17. Collecting
Requirements
- Techniques
• Compare the planned practices to
projects or organizations to help
identify best practices
BENCHMARKING:
• A scope model, a visual way to view
the scope
• Shows users visual way to interact
with the product
CONTEXT
DIAGRAMS:
• Analyze existing documentations of
older but similar projects to create
requirements in a new project
DOCUMENT
ANALYSIS:

18. Documentation of Requirements
– Upon requirements being finalized, requirements need to be documented
– Assumptions, Dependencies, Constraints
– Stakeholder Requirements
– Solution/Technical Requirements
– Business Requirements
– Project Requirements
– Requirements pertaining to transition events

19. Requirements
Traceability
Tracks requirements to ensure they
are completed
Lists the requirement source and the
resource responsibility

20. 5.3 Define Scope
Belongs in the Planning Project Process Group

21. 5.3 Define Scope
BELONGS IN THE PLANNING PROJECT
PROCESS GROUP
WORKS TO DEFINE THE LIMITS/BOUNDARIES
OF THE PROJECT
USES THE DOCUMENTED REQUIREMENTS,
PROJECT CHARTER, RISKS, ASSUMPTIONS,
AND CONSTRAINTS AS INPUTS IN HELPING
TO DEFINE THE PROJECT SCOPE

22. Scope Statement
The Scope Statement is the output of the Define Scope
Process
It defines the boundaries of the project and explains
what will be completed for the project
Includes:
The scope of the project output
Acceptance criteria for the final product
Possible risks to the scope, constraints, dependencies and assumptions
Defined exclusions to the scope

23. 5.4 Create WBS
Belongs in the Planning Project Process Group

24. 5.4 Create WBS
BELONGS IN THE PLANNING
PROJECT PROCESS GROUP
THE WORK BREAKDOWN
STRUCTURE PROCESS IS THE
PROCESS OF BREAKING
DOWN PROJECT WORK INTO
MORE MANAGEABLE PARTS
CREATES A HIERARCHY
STRUCTURE TO THE PROJECT
AND ALLOWS PROJECT
PHASES TO BE CREATED
PROVIDES A PATH TO
COMPLETING THE PROJECT
AND SHOWS THE SMALLER
DELIVERABLES
MAKES THE PROJECT WORK
EASIER TO VISUALIZE AND
UNDERSTAND

25. WBS Levels
PROJECT LEVEL: The Core
Purpose of the Project / Project
Name
CONTROL ACCOUNTS: The major
deliverables or phases of the
project
WORK PACKAGES: Small units of
work that are required to create
the deliverables or project phases
ACTIVITIES: Tasks to be assigned
in order to complete the Work
Packages

26. Generic WBS Example
Work Packages and Activities
Control Accounts
-Deliverables and Phases
The Main Objective/Project
CORE
PROJECT
Deliverable
1
Work
Package 1
Activity 1
Activity 2
Work
Package 2
Activity 1
Work
Package 3
Activity 1
Deliverable
2
Work
Package 1
Activity 1
Activity 2
Deliverable
3
Work
Package 1
Activity 1

27. WBS Dictionary
Provides a detailed
description of the
work that is required
to complete the work
packages
Each work package
should have detailed
information in the
WBS Dictionary

28. 5.5 Validate Scope
Belongs in the Monitoring & Controlling Project
Process Group

29. 5.5 Validate
Scope
Occurs during
the Monitoring
& Controlling
process group
Formalizing the
acceptance of
completed
project
deliverables
Deliverables
must be
prepared and
aligned to the
approved scope
Requirements
status must be
known and
presented

30. Validating
Scope
Outputs
– Accepted deliverables or phase project work
– May include change requests if the customer seeks a
modification, a defect is found, or deliverables rejected
for not meeting scope

31. Validate Scope
Process
Customer Accepts
or Rejects
Deliverable
Rejection may result in more change requests or defect repairs
Customer Inspects
Deliverable
Customer Inspects
Deliverable
Perform Defect
Repair or Change
Requests
Perform Defect
Repair or Change
Requests
Compare Scope to
Scope Baseline –
Control Scope
Compare Scope to
Scope Baseline –
Control Scope
Complete
Deliverables
Complete
Deliverables

32. 5.6 Control Scope
Belongs in the Monitoring & Controlling Project
Process Group

33. 5.6 Control Scope
Belongs in the
Monitoring &
Controlling Project
Process Group
Monitoring and
controlling the
scope of the
project
Compares the
current state of the
product to the
scope baseline
A clear definition of
the scope is
required
Work item or
package must be
completed

34. Control Scope
Measure against
the scope baseline
Determine any
variance from the
baseline
Determine if repairs
or corrections on
the deliverable is
needed
Update project
documents or
project plan as
required
Evaluate the impact
of any possible
changes

35. Sources
– A Guide to the Project Management Body of Knowledge – 6th Edition
– https://www.pmi.org/
Joshua Render
https://agile-mercurial.com