PROJECT SCOPE

MANAGEMENT
 Introduction

 This knowledge area ensures that the

project includes all the work required,
and only the work required, to complete
the project successfully.
 Key concepts Predictive lifecycle Adaptive/agile lifecycle
1. Product scope: Deliverables defined at Deliverables defined
• The features and functions that characterize a the start through multiple
product, service, or result. iterations
• Completion measured against product Scope changes Scope in detail is defined
requirements progressively managed at the start of each
2. Project scope: iteration
• The work performed to deliver a product, Scope baseline Backlog (requirements +
service, or result with the specified features user stories)
and functions. Scope planning process Repeat scope planning
• Completion measured against project performed toward the process every iteration
management plan. beginning and updated as
3. Requirements: necessary
• Conditions or capabilities that are required to Scope control ongoing Scope control & validation
be present in a product, service, or result to Validate each deliverable repeated every iteration
satisfy an agreement or other formally
imposed specification.
The term “project scope” is
sometimes viewed as including
product scope.
 Practice trends
1 Collaboration
Determine problems and identify
business needs

2 Solutions
Identify and recommend viable
solutions for meeting those needs

3 Manage requirements
Elicit, document, and manage
stakeholder requirements

4 Implementation
Facilitate the successful implementation of
the product, service, or end result of the
program or project

Partnership
5 Requirement-related activities are the responsibility
of the business analyst if assigned to project
 Agile/Adaptive Environments

 Agile practice in scope knowledge area:

1. Deliberately spend less time to agree on scope.

2. Build and review prototypes and release versions in order to

refine the requirements

3. Scope is defined and redefined throughout the project

Project Scope Management Processes
Monitoring
Monitoring &
Initiation Planning Execution and Closing
Controlling
Controlling
Plan Scope Management

5.1
 Creating a scope management plan
that documents how:
1. project scope
2. product scope.
 will be defined, validated, and
controlled

 Guidance and direction on how

scope will be managed throughout
the project

S1. Project charter analysis.

S2. Approved subsidiary plans.
S3. OPA.
S4. EEF
 5.1 Plan Scope Management
Inputs Tools & Outputs
techniques

.1 Project charter .1 Expert judgment .1 Scope

.2 Project .2 Data analysis management
management plan plan
• Alternatives analysis
.3 Enterprise .2 Requirements
.3 Meetings
environmental management
factors plan
.4 Organizational
process assets
 5.1.1 Plan Scope Management: Inputs
5.1.1.1 Project Charter 5.1.1.2 Project Management Plan

project purpose Quality management plan

high-level • Quality policy, methodologies, and standards
requirements are implemented on the project.
constraints

High-level assumptions
Project life cycle description
project
description • The series of phases that a project passes

Development approach
• The development approach will be used.
5.1.1.3 EEF 5.1.1.4 OPA

Organization’s
culture, 1. Polices
2. Procedures
3. Templates
Infrastructure
4. Historical Info.
5. Lesson learned.
Personnel
administration,

Marketplace
conditions.
 5.1.2 Plan Scope Management: Tools and
Techniques
5.1.2.1 Expert Judgment 5.1.2.3 Meetings
Previous similar projects.  Develop scope plan meetings.
Information in the industry.  Attendees are who has
Information in discipline. responsibility in scope
Information in application area.

5.1.2.2 Data Analysis

Alternative analysis:
1. Collecting requirements
2. Elaborating scope
3. Validate & control the scope.
 5.1.3 Plan Scope Management: Outputs
5.1.3.1 Scope Management Plan

Formal or informal, broadly

framed or highly detailed
 Describes how the scope will be
project scope
statement process
defined, developed, monitored,
controlled, and validated.
WBS creation
process

Scope baseline
establishment
& maintenance Formal acceptance of the
completed project
deliverables process
5.1.3.2 Requirements Management Plan

 Describes how project and product requirements will be

analyzed, documented, and managed.

Planning, tracking,
reporting activities

Configuration
management
activities

Requirements
prioritization process

Metrics Traceability structure

Collect Requirements

5.2
  Requirements:
 Determining, documenting, and Conditions or capabilities that
are required to be present in a
managing stakeholder needs and
product, service, or result to
requirements to meet objectives. satisfy an agreement or other
formally imposed specification

 Provides the basis for defining the

product scope and project scope.
Requirements are foundation for:
Requirements need to be elicited, 1. WBS.
analyzed, and recorded in enough 2. Cost.
3. Schedule.
detail to be included in the scope 4. Quality planning.
baseline and to be measured 5. Procurement

Product requirements are industry

specific.
 5.2 Collect Requirements
Inputs Tools & techniques Outputs

.1 Project charter .1 Expert judgment .1 Requirements

.2 Project management .2 Data gathering documentation
plan .3 Data analysis .2 Requirements
.3 Project documents traceability
.4 Decision making
.4 Business documents matrix
analysis
.5 Agreements .5 Data representation
.6 Enterprise .6 Interpersonal and team skills
environmental .7 Context diagram
factors .8 Prototypes
.7 Organizational
process assets
 5.2.1 Collect Requirements: Inputs
5.2.1.1 Project Charter 5.2.1.3 Project Documents

1. High-level project description.

Stakeholder • Identify stakeholders who can provide
2. High-level requirements Register information on the requirements.

Assumption • Assumptions that can influence

Log requirements.
5.2.1.2 Project Management Plan
Lessons
Scope • Information on effective
management learned
how the project scope will be defined and requirements collection techniques
plan developed register

Requirements
management how project requirements will be collected,
plan analyzed, and documented
Stakeholder stakeholder engagement in order to assess and
engagement adapt to the level of stakeholder participation in
plan requirements activities
5.2.1.4 Business Documents 5.2.1.6 EEF

 Business case which describes:  Organization’s culture.

1. Required criteria.
2. Desired criteria.  Infrastructure.
3. Optional criteria.  Personnel administration.
for meeting the business needs.
 Marketplace conditions.

5.2.1.7 OPA
5.2.1.5 Agreements
 Policies and procedures.
 Contain project and product
 Historical information.
requirements.
 lessons learned repository.
 5.2.2 Collect Requirements: Tools and
Techniques
5.2.2.1 Expert Judgment 5.2.2.2 Data Gathering

Business
analysis.
generate and collect

Brainstorming multiple ideas.

. aid in identifying and

Requirements
analysis,
Interviews defining the features
and functions
documentation,
elicitation . expectations and attitudes of
Focus groups prequalifies stakeholders & SME

Questionnaires written sets of questions accumulate

& surveys information from a large number of
Diagramming respondents
techniques.
Benchmarking.
comparing actual or planned products,
processes, and practices to those of
comparable organizations
5.2.2.3 Data Analysis 5.2.2.4 Decision Making
 Document analysis: consists of  Voting:
reviewing and assessing any
1. Collective decision-making technique and an
relevant documented information.
assessment process.
2. generate, classify, and prioritize product
requirements.
Problem/issue
Agreements 3. E.g.:
logs
a. Unanimity: everyone agrees.
b. Majority: more than 50%.
c. Plurality: largest block in a group.
Marketing 4. Autocratic:
Business plans
literature a. an individual takes decision

5. Multicriteria decision analysis:

a. decision matrix.
Business rules Current b. systematic analytical approach.
repositories process flows
5.2.2.5 Data Representation

 Affinity diagrams:  Mind mapping:

large numbers of ideas to be Consolidates ideas into a single
classified into groups for review map to reflect commonality and
and analysis. differences
5.2.2.6 Interpersonal and Team Skills 5.2.2.7 Context Diagram
 Scope model.
 Nominal group technique:  Visually depict the product scope by:
A structured form of brainstorming to rank the 1. Showing a business system.
most useful ideas for further brainstorming or 2. How people and other systems interact with
for prioritization. it.
 Observation/conversation:  Context diagrams show:
viewing individuals in their env. and how they 1. Inputs to the business system.
perform their jobs or tasks and carry out 2. The actor(s) providing the input.
processes. 3. The outputs from the business system.
 Facilitation 4. The actor(s) receiving the output.
used with focused sessions used to quickly
define cross-functional requirements and 5.2.2.8 Prototypes
reconcile stakeholder differences. Situations
are: Is a method of obtaining early feedback on
1. Joint application design/development requirements by providing a model of the
(JAD). expected product before actually building
2. Quality function deployment (QFD) it.
3. User stories Storyboarding is a prototyping technique
showing sequence or navigation through a
series of images or illustrations.
 5.2.3 Collect Requirements: Outputs
5.2.3.1 Requirements Documentation
Business requirements
Describes how individual Higher-level needs of the organization as a whole
requirements meet the business Stakeholder
requirements Stakeholder or stakeholder group needs
need for the project.
Forms: Solution requirements
Features, functions, and characteristics
1. Simple. • Functional requirements; describe the behaviors of the product
2. Elaborated • Nonfunctional requirements; supplement functional requirements and
describe the environmental conditions or qualities
requirements need to be:
1. Unambiguous.
2. Traceable.
Transition and readiness Temporary capabilities needed to transition from the
requirements. current as-is state to the desired future state
3. Complete.
4. Consistent, Project requirements Actions, processes, or other conditions the project
5. Acceptable to key stakeholders. needs to meet

Quality requirements Condition needed to validate the successful

completion of a project deliverable.
5.2.3.2 Requirements Traceability Matrix

Is a grid that links product  Traceability items, such as:

requirements from their origin to the
1. Business needs, opportunities, goals,
deliverables that satisfy them.
and objectives.

1. Helps ensure that each requirement 2. Project objectives.

adds business value. 3. Project scope and WBS deliverables.

2. Helping to ensure that 4. Product design.

requirements delivered at the end
5. Product development.
of the project.
6. Test strategy and test scenarios.
3. Provides a structure for managing
changes to the product scope.
Define Scope

5.3
 Developing a detailed description of
the project and product

 Description of the product, service,

or result:
1. Boundaries Define Scope process can
2. Acceptance criteria
be highly iterative
 selects the final project
requirements from the
requirements documentation

Detailed project scope statement build upon:

• Major deliverables, assumptions, and constraints- initiation
• Existing risks, assumptions, and constraints are analyzed
 5.3 Define Scope
Inputs Tools & Outputs
techniques

.1 Project charter .1 Expert judgment .1 Project scope

.2 Project .2 Data analysis statement
management plan .3 Decision making .2 Project
.3 Project documents
analysis
documents updates
.4 Interpersonal and team
.4 Enterprise skills
environmental .5 Product analysis
factors
.5 Organizational
process assets
 5.3.1 Define Scope: Inputs
5.3.1.1 Project Charter 5.3.1.3 Project Documents
1. Level project description. Assumption log
2. Product characteristics.
3. Approval requirements. • identifies assumptions and constraints and other
factors that can influence the project and product
scope
5.3.1.2 Project Management Plan Requirements documentation
• Identifies requirements that will be incorporated
into the scope.
1. Scope Mgmt. plan. Risk register
• Contains response strategies that may affect the
• project scope,
5.3.1.4 EEF

1. Organization’s culture.
2. Infrastructure.
3. Personnel
administration.
4. Marketplace conditions.

5.3.1.5 OPA

1. Policies, procedures, and templates for a project

scope statement.
2. Project files from previous projects.
3. Lessons learned from previous phases or
projects.
 5.3.2 Define Scope: Tools and Techniques
5.3.2.1 Expert Judgment 5.3.2.3 Decision Making

Who has knowledge of or • Multicriteria decision

experience with similar analysis
projects. Uses a decision matrix to
provide a systematic
analytical approach for
5.3.2.2 Data Analysis
establishing criteria
• Alternatives analysis:
Evaluate ways to meet the
requirements and the
objectives identified in
the charter.
5.3.2.4 Interpersonal and Team Skills 5.3.2.5 Product Analysis

Facilitation: Used to define products and

Used in workshops and working services
sessions with key stakeholders
who have a variety of Translating high-level product
expectations or service descriptions into
meaningful deliverables.
Reach a cross-functional and
PRODUCT Product breakdown
common understanding of: ANALYSIS
1. Project deliverables. Requirements analysis
2. Project and product boundaries.
Systems analysis
Systems engineering
Value analysis
Value engineering
 5.3.3 Define Scope: Outputs
5.3.3.1 Project Scope Statement
provides a
Description of the project common Baseline to
understanding of evaluate changes
scope, major deliverables, the project scope
assumptions, and constraints.

Project scope statement

includes:
contain explicit guides the project
Product scope description scope exclusions team’s work during
execution
Deliverables
Project exclusions
Enable detailed
Acceptance criteria planning
5.3.3.2 Project Documents Updates

Requirements Requirements
Assumption log Stakeholder register
documentation traceability matrix

Updated Additional Updates in Info. Of existing

assumptions requirements requirement stakeholders
Updated constraints Changed documentation
Info. Of new
requirements stakeholders
Create WBS

5.4
 WBS:
 Subdividing project deliverables
hierarchical
and project work into smaller, more
decomposition of the
manageable components.
total scope of work to be
carried out by the project
 Provides a framework of what has to
team to accomplish
be delivered
the project objectives and
 The WBS organizes and defines the
create the required
total scope of the project.
deliverables.
 Represents the work specified in the
Work package:
current approved project scope
lowest level of WBS
statement
components

Work refers to work products or

deliverables that are the result of
activity and not to the activity itself
 5.4 Create WBS
Inputs Tools & techniques Outputs

.1 Project .1 Expert judgment .1 Scope baseline

management plan .2 Decomposition .2 Project
.2 Project documents documents
documentation updates
.3 Enterprise
environmental
factors
.4 Organizational
process assets
 5.4.1 Create WBS: Inputs
5.4.1.1 Project Management Plan 5.4.1.2 Project Documents
Scope management plan: Project scope statement
Documents how the WBS will describes the work that will be
be created from the project performed and the work that is
scope statement excluded
Requirements documentation:
describe how individual
requirements meet the business
need
5.4.1.3 EEF

industry-specific WBS:
serve as external reference
sources for creating the WBS

5.4.1.4 OPA

1. Policies, procedures, and templates.

2. Project files from previous projects.

3. Lessons learned from previous projects.

 5.4.2 Create WBS: Tools and Techniques
5.4.2.1 Expert Judgment 5.4.2.2 Decomposition

knowledge of or experience  is a technique used for dividing and

with similar projects. subdividing the project scope and
project deliverables into smaller,
more manageable parts.

Decomposition level is often guided by

the degree of control needed

The WBS represents all product and

project work, including the project
management work.
 Decomposition forms:
Decomposition activities 1. Phase:
a. Second level, phases of project lifecycle.
b. Third level, deliverables.
• Deliverables &
Identification
related work
2. deliverables:
Second level, major deliverables
3. Contracted work:
• Structuring and
Structure
organizing the WBS
Incorporating subcomponents outside
the project team
• Decomposing the
Decompose
upper WBS levels into
lower-level

• Developing and
Code assigning
identification codes

• The appropriateness of
Verification
the degree of
decomposition
100 percent rule

Rolling wave
 5.4.3 Create WBS: Outputs
5.4.3.1 Scope Baseline

Project scope statement

 Approved version of a scope • the description of the project scope, major deliverables, assumptions, and constraints

statement, WBS, and its WBS.

associated WBS dictionary • Hierarchical decomposition of the total scope of work

Work package
 Control account • Provide a structure for hierarchical summation of costs, schedule, and resource
information and form a code of accounts
 management control point
where scope, budget, and Planning package
• WBS component below the control account and above the work package with known
schedule are integrated and work content but without detailed schedule activities
compared to the earned value WBS dictionary
for performance measurement • is a document that supports the WBS
5.4.3.2 Project Documents Updates

Assumption log:

Updated with additional assumptions or constraints

Requirements documentation

May be approved change requests

Validate Scope

5.5
 Formalizing acceptance of the The verified deliverables
completed project deliverables reviewed with the customer
or sponsor to ensure they
are:
 It brings objectivity to the 1. Completed satisfactorily
acceptance process. 2. Have received formal
 Increases the probability of final acceptance
deliverable acceptance by validating
each deliverable
The basis are:
1. Requirements
documentation.
2. scope baseline
3. work performance data
 5.5 Validate Scope
Inputs Tools & techniques Outputs

.1 Project management .1 Inspection .1 Accepted

plan .2 Decision making deliverables
.2 Project documents • Voting .2 Work performance
.3 Verified deliverables information
.4 Work performance .3 Change requests
data .4 Project document
updates
• Lessons learned
register
• Requirements
documentation
• Requirements
traceability
matrix
 5.5.1 Validate Scope: Inputs
5.5.1.1 Project Management Plan 5.5.1.2 Project Documents
Scope management plan
Lessons learned Applying lessons to improve efficiency and
register
How formal acceptance will be obtained effectiveness of validating deliverables

Quality reports
Should be reviewed before product acceptance
Requirements management plan • All quality assurance issues managed or escalated
• Recommendations for improvement
How the project requirements are validated • Summary of findings from the control quality process

Scope baseline Requirements

documentation
compared to the actual results
Compared to actual results Requirements
traceability Information about requirements, including
matrix how they will be validated
5.5.1.3 Verified Deliverables 5.5.1.4 Work Performance Data

 Deliverables that are completed and

checked for correctness degree of severity of the
compliance nonconformities

Control Quality is performed before 01 02 03 04

Validate Scope.
Quality control concern with
correctness. number number of
Validate scope concern with of nonconformities validation cycles

acceptance
 5.5.2 Validate Scope: Tools and Techniques
5.5.2.1 Inspection 5.5.2.2 Decision Making
Voting:
To reach a conclusion

Measurement, validation, & examination

Requirements &
Work &
Product
Deliverables
acceptance criteria
 5.5.3 Validate Scope: Outputs
5.5.3.1 Accepted Deliverables 5.5.3.2 Work Performance Information
 Signed off and approved
deliverables by the
customer or sponsor.
 Formal documentation  Project progress.
received from the customer  Accepted deliverables.
or sponsor  Non accepted deliverables.
 Deliverables forwarded to
the Close Project or Phase
process
5.5.3.3 Change Requests 5.5.3.4 Project Documents Updates

 Defect repair for non

accepted deliverables
Control Scope

5.6
1. Monitoring the status of the project and product scope.

2. Managing changes to the scope baseline

Maintain scope baseline throughout the project .

Used to manage the actual changes when they occur.

Scope creep:
Uncontrolled expansion to product or project scope
without adjustments to time, cost, and resources
 5.6 Control Scope
Inputs Tools & techniques Outputs

.1 Project .1 Data analysis ..1 Work

management plan performance
.2 Project documents information
.3 Work performance .2 Change
data requests
.4 Organizational .3 Project
process assets management
plan
updates
.4 Project
documents
updates
 5.6.1 Control Scope: Inputs
5.6.1.1 Project Management Plan 5.6.1.2 Project Documents
Scope management plan.
Lessons learned
Requirements management plan. register
Change management plan.
Requirements
Configuration management plan. documentation
Scope baseline
Requirements
Performance measurement baseline traceability matrix
5.6.1.3 Work Performance Data 5.6.1.4 Organizational Process Assets

1. Number of change requests

received. 1. Scope control-related
2. Number of requests policies, procedures,
accepted. guidelines.
3. Number of deliverables 2. Monitoring and reporting
verified, validated, and methods and templates
completed
 5.6.2 Control Scope: Tools and Techniques
5.6.2.1 Data Analysis

Variance analysis Trend analysis

1. Compare the baseline to 1. Examines project performance over

the actual results. time
2. variance & threshold. 2. Is performance improving or
deteriorating.
 5.6.3 Control Scope: Outputs
5.6.3.1 Work Performance Information 5.6.3.2 Change Requests
 Correlated and 1. Scope baseline.
contextualized
information of project & 2. Schedule baseline.
scope performance. 3. Project management
plan.
1. Categories of the
changes received.
2. Identified scope
variances their cause &
impact
3. Forecast,
5.6.3.3 Project Management Plan 5.6.3.4 Project Documents Updates
updates

Scope management plan. Lessons learned

register
Scope baseline

Schedule baseline Requirements

documentation
Cost baseline

Performance measurement baseline Requirements

traceability matrix