Project Scope Management

1
Process Name Scope management process Process Group(PG)
Plan Scope Develop a plan for how you will plan, Planning
Management manage, and control scope and
requirements on the project
Collected Determine requirements, making sure all Planning
Requirements requirements support the project’s business
case as described in the project charter
Define Scope Sort and balance the needs of the Planning
stakeholders to determine scope
Create WBS Create a WBS to break the scope down to Planning
smaller, more manageable pieces, and
define each pieces in the project charter
Validate Scope Obtain validation that the completed scope M&C
is acceptable to the customer
Control Scope Measure scope performance, and adjust as M&C
needed

2
Plan Scope Management : Iputs

Project management plan components include but are not limited to:

 Quality management plan. The way the project and product scope will be
managed can be influenced by how the organization’s quality policy,
methodologies, and standards are implemented on the project.

 Project life cycle description. The project life cycle determines the series of
phases that a project passes through from its inception to the end of the project.

 Development approach. The development approach defines whether waterfall,

iterative, adaptive, agile, or a hybrid development approach will be used.

3
 Plan Scope Management : Outputs
Scope It is a major input into the develop project management plan process and
Management other scope management processes. It includes
Plan • Process for repairing a detailed project scope statement
• Process that enables the creation of WBS and establishes how the
WBS will be maintained and approved
• Process that specifies how formal acceptance of the completed
project deliverables will be obtained
• Process to control how request for changes to scope statement will be
processed (Linked with perform integrated change control process)

Requirements Describes how requirements will be analyzed, documented, and

Management managed. Plan can include not but limited to:
Plans • How requirements activities will be planned, tracked and reported
• Configuration management activities, How changes will be initiated,
impacts will analyzed, traced, tracked, reported, authorization levels
to approval etc.
• Requirements prioritization process
• Product metrics that will be used and the rationale for using them
• Traceability Structure

4
Collect Requirements
• Collect requirements is the process of determining, documenting and
managing stakeholder needs and requirements to meet project
objectives (PMI).
• Project success is directly influenced by
• active stakeholder involvement
• discovery and decomposition their needs into requirements
• determining, documenting and managing the requirements into
product, service or result
• Requirements become the foundation of
• WBS
• Cost
• Schedule
• Quality Planning
• Procurements (If applicable)

5
Collect Requirements: Input
Project management plan components include but are not limited
to:

 Scope management plan. The scope management plan

contains information on how the project scope will be defined
and developed.
 Requirements management plan. The requirements
management plan has information on how project requirements
will be collected, analyzed, and documented.
 Stakeholder engagement plan. The stakeholder engagement
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.

6
Collect Requirements: Input
Project documents that can be considered as inputs for this process
include but are not limited to:

 Assumption Log: The assumption log identified assumptions about the

product, project, environment, stakeholders, and other factors that can
influence requirements.
 Lessons learned register: The lessons learned register is used to
provide information on effective requirements collection techniques,
especially for projects that are using an iterative or adaptive product
development methodology.
 Stakeholder Register: The stakeholder register is used to identify
stakeholders who can provide information on the requirements. It also
captures requirements and expectations that stakeholders have for the
project.

7
Collect Requirements: TT
Data-gathering techniques:
 Brainstorming.
 Interviews.
 Focus groups
 Questionnaires and surveys..
 Benchmarking.

Decision-making techniques:
 Voting.
 Unanimity, Everyone agrees (100%), can be reached by Delphi
Technique
 Majority, Reach with support obtained from more than 50%
 Plurality, Reached whereby the largest block of group
decides,30% yes, 40% no and remaining 30% neutral (Decision:
No)
 Autocratic decision making.
 Multicriteria decision analysis.

8
Collect Requirements: TT
DATA REPRESENTATION

 Affinity diagrams. Affinity diagrams allow large numbers of ideas to be

classified into groups for review and analysis.

 Mind mapping. Mind mapping consolidates ideas created through

individual brainstorming sessions into a single map to reflect
commonality and differences in understanding and to generate new
ideas.

Context Diagrams:
Visually depict the product scope by showing a business system, and how
people and other system interact with it.

9
Collect requirements : Affinity Diagram
Why the customer service substandard

10
Collect requirements : Mind/Idea mapping

11
Collect Requirements: Output
Requirements documentation describes how individual requirements meet
the business need for the project. Requirements documentation can
include, but, are not limited to:

Business requirements, such as business issues or opportunities

Stakeholder requirements, defined by stakeholder or stakeholder group
Solution requirements, such as features, functions, and characteristic of product,
service or result.
Functional requirements, such as process, data and interactions
Nonfunctional requirements, such as reliability, security, safety etc.
Project requirements, such as actions, processes or other condition project
need to meet
Quality requirements, condition or criteria needed to validate the successful
completion of a project deliverable

12
Collect Requirements: Output
Requirements Traceability Matrix, is a grid that links product
requirements from their origin to the deliverables that satisfy
them. It includes but not limited to

• Business needs, opportunities, goals and objectives

• Project objectives
• Project Scope/WBS deliverables
• Product design
• Product development
• Test strategy and test scenarios
• High‐level requirements to more detailed requirements

13
Define Scope:

Define scope is the process of developing a detailed description of the

project and product. The key benefits of this process is that it describes the
project, service, or result boundaries by defining which of the requirements
collected will be included in and excluded from the project scope.

14
 Define Scope: Inputs

Scope Component of the project management plan that establishes the

Management activities for developing, monitoring and controlling the project
Plan scope

Project Charter High level project description and product characteristics with project
approval requirements. Comparable information needs to be
acquired or developed and used as a basis for detailed scope
planning, if formal project charter is not available.
Requirements Will be used to select the requirements that will be included in the
Documentation project

Organizational Can influence how scope is defined. Include but not limited to:
Process Assets • Policies, procedures and templates for scope statement
• Project files from previous projects
• Lessons learned from previous phases or projects

15
Define Scope: Inputs

PROJECT DOCUMENTS

 Assumption log. The assumption log identifies assumptions and

constraints about the product, project, environment, stakeholders, and
other factors that can influence the project and product scope.
 Requirements documentation. Requirements documentation identifies
requirements that will be incorporated into the scope.
 Risk register. The risk register contains response strategies that may
affect the project scope, such as reducing or changing project and
product scope to avoid or mitigate a risk.

16
Define Scope : TT

PRODUCT ANALYSIS:

 Product breakdown.
 Requirements analysis.
 Systems analysis.
 Systems engineering.
 Value analysis, and Value engineering.

17
 Define Scope : Outputs
Project Scope Statement, is the description of the project scope, major
deliverables assumptions and constraints This document in effect says
“Here is what we will do on this project” or Here is the approved project
and product scope for this project”. It includes the following:

 Product scope description, progressively elaborates the

characteristics of the product, service or result describe in the charter
and requirements documentation
 Acceptance criteria, is set of condition that is required to be met
before deliverables are accepted
 Deliverable, any unique and verifiable product, result or capability
that is required to be the produced to complete a process, phase or
project.
 Project exclusion, identifies what is excluded from the project.

18
Create WBS
Create WBS is the process of subdividing project deliverables and project
work into smaller, more manageable components.

• It is a hierarchical decomposition of the total scope of work.

• It visualizes the entire project.
• It organizes and defines the total scope of the project.
• It serves as the foundation for planning, estimating and project
control
• It builds team consensus and buy‐in to the project
• The WBS serves as a control mechanism to keep the project on track.
• It serves as a deterrent to scope change.

The planned work is contained within the lowest level of WBS

components, which are called work packages.

19
 Create WBS: Inputs

Scope Specifies how to create the WBS and how will be maintained and
Management approved
Plan

Project Scope Describes the work that will be performed and the work that is
Statement excluded and internal or external restrictions that may affect the
execution.

Requirements For understanding what needs to be produced for project, and what
Documentation needs to be done to deliver the final products

Industry‐specific WBS standards may serve as reference. Like ISO

Enterprise standard, ITIL standard
Environmental
Factors

Include but not limited to:

Organizational • Policies, procedures and templates for WBS
Process • Project files and lessons learned from previous project
Assets

20
Create WBS: TT
Decomposition, is subdivision of project deliverables into
smaller, more manageable components. It generally involves:

• Identifying and analyzing the deliverables and related works

• Structuring and organizing the WBS
• Decomposing the upper WBS levels in lower‐level detailed
components
• Developing and assigning identification codes to the WBS
components
• Verifying the degree of decomposition

21
Creating WBS

22
Creating WBS: Output
Project Documents Updates, like requirements documentation for
including approved changes

• Project Scope statement, description of the project scope, major deliverables,

assumption and constraints
• WBS, hierarchical decomposition of the total scope for creating, monitoring,
controlling required deliverables (using control account).
• WBS dictionary, which provides detailed deliverable, activity and scheduling
information about each component in the WBS. It may include:
• Description of work and Code of account identifier
• Assumption and constraints
• Responsible organization
• Schedule milestones, resource required cost estimates
• Quality requirements etc
Project Documents Updates, like requirements documentation for including
approved changes

23
Creating WBS: Output
Scope Baseline, is approved version of scope statement, work breakdown
structure (WBS) and WBS dictionary before the project work begins.

 Project scope statement. The project scope, major deliverables, assumptions,

and constraints
 WBS. 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.
 Work package. The lowest level of the WBS is a work package with a unique
identifier. These identifiers provide a structure for hierarchical summation of costs,
schedule, and resource information and form a code of accounts. Each work
package is part of a control account. A control account is a management control
point where scope, budget, and schedule are integrated and compared to the
earned value for performance measurement. A control account has two or more
work packages, though each work package is associated with a single control
account.
 Planning package. A control account may include one or more planning packages.
A planning package is a work breakdown structure component below the control
account and above the work package with known work content but without detailed
schedule activities

24
Validate Scope

Validate scope process actually involves frequent, planned meetings with

the customer or sponsor to gain formal acceptance of deliverables during
project monitoring and controlling.

25
 Validate Scope: Inputs

Project It contains scope management plan and scope baselines which

Management specifies the process of formal acceptance, approved version of
Plan scope statement, WBS and WBS dictionary

Requirements Lists all the project, product and other types of requirements and
Documentation their acceptance criteria

Requirements Links requirements to their origin and tracks them throughout the
Traceability project life cycle
Matrix

Verified That are completed and checked for correctness through the
Deliverables control quality process

Include the degree of compliance with requirements, number of

Work nonconformities, severity of the nonconformities, number of
Performance validation cycle performed in period of time
Data
Developed by Md. Zikrul Islam MCIPS, PMP & Rashed Morshed MCIPS, PEng.

26
Validate Scope: TT

Inspection Includes activities such as measuring, examining, and

validating to determine whether work and deliverables
meet requirements. It might be reviews, product
reviews, audits and work throughs.
Group Decision Used to reach a conclusion after validation by project
Making team and stakeholders
Techniques

27
 Validate Scope: Output

Accepted Deliverables that meet the acceptance criteria. Required formally

Deliverables signed off and approved by the customer or sponsor

Change That have not been formally accepted are documented with the
Requests reason for non acceptance. Deliverables may require change
request for defect repair.

Work Includes information about project progress, such as deliverable

Performance have started, finished, or accepted
Information

Project Any documents that define the product or report status on product
Documents completion.
Updates

28
 Control Scope

• Scope creep means uncontrolled changes that

cause the team to do extra work .
• Gold plating providing extra features that is not
asked from the customers with or without
checking the impact
• To avoid scope creep and gold plating plan your
changes completely and check impact of your
changes through change control process.
• Remember both are considered very bad change
and should be avoided .

29
Control Scope: ITTO

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

30
 Control Scope: Inputs
Project Various information from scope baseline, scope management plan,
Management Plan Change management plan, Configuration management plan and
Requirements management plan are used.

Requirements Well documented requirements (unambiguous, measurable,

Documentation testable, traceable, complete, consistent and acceptable by key
stakeholders) make it easier to detect any deviation

Requirements Helps to detect the impact of any change or deviation from the
Traceability Matrix scope baseline on the project objectives

Work Performance Include the number of change requests received, the number of
Data requests accepted or the number of deliverables completed

Organizational Include but not limited to:

Process Assets • Existing formal and informal scope control‐related policies etc
• Monitoring and reporting methods and templates etc

31
 Control Scope: Outputs
Work Correlated and contextualized information on how project scope is
Performance performing compared to scope baseline, changes received,
Information identified scope variances and their causes, impact on schedule or
cost and forecast of the future scope performance.

Change Can include preventive or corrective actions, defect repairs or

Requests enhancement requests.
Project Scope and other baselines may need to updates, revised and
Management reissued to reflect the approved change requests.
Plan Updates
Project Include but not limited to
Documents • Requirements documentation and requirements traceability
Updates • matrix
Organizational Include but not limited to
Process Assets • Causes of variances
Updates • Corrective action chosen and the reasons
• Lessons learned from project scope control

32
33