2_Project Scope Management

PPROJECTROJECT SSCOPECOPE MMANAGEMENTANAGEMENT
PMBOKPMBOK
66thth EEditiondition
Copyright © 2018 by Knowledge valley Company. All rights reserved.
Hisham Haridy, MBA, PMP, PMI-RMP, PMI-SP

Scope ManagementScope Management
Plan Scope
Management
Collect
Requirements
Define
Scope
Create WBS
Validate
Scope
Control
Scope
“The processes involved in ensuring the project includes all the work required, and only
the work required, for completing the project successfully”
Project Scope Management PMBOK 6th Edition
Plan Scope
Management
Collect
Requirements
Define
Scope
Create WBS
Validate
Scope
Control
Scope
What is and is
not included in
the project and its
deliverables.
(Project Scope
Statement)
Requirements
are what
stakeholders
need for a
project
Is a deliverable
oriented grouping
of project
components that
organizes and
defines the total
scope of the project
(WBS & WBS
Dictionary)
The control scope
process involves
measuring project
and product scope
performance and
managing scope
baseline changes.
Is actually involved
frequent, planned-in
meetings with the
customer or sponsor to
gain Formal
Acceptance of the
deliverables during
monitoring and
control.
how requirements will
be managed throughout
a project lifecycle

Agile Work ProcessAgile Work Process
 The scope is often not understood at the beginning of the project.
 Agile spend less time to define scope in the early stage of the project and
spend more time establishing refinement.
 There is a gap between the real business requirements and the business
requirements that were originally stated.
 Agile builds and reviews prototypes and release versions in order to refine
the requirements.
 Scope is defined and redefined throughout the project.
 In agile approaches, the requirements constitute the backlog.
 The scope is often not understood at the beginning of the project.
 Agile spend less time to define scope in the early stage of the project and
spend more time establishing refinement.
 There is a gap between the real business requirements and the business
requirements that were originally stated.
 Agile builds and reviews prototypes and release versions in order to refine
the requirements.
 Scope is defined and redefined throughout the project.
 In agile approaches, the requirements constitute the backlog.

Product Scope Project Scope
Features and functions that are to be
included in a product or service
Work that MUST be done in order to
deliver a product with the specified
features and functions.
Successful completion of product scope is
measured against the Product Requirement.
Completion of project scope is measured
against the Project Plan.
Product Scope Vs. Project Scope
Successful completion of product scope is
measured against the Product Requirement.
Completion of project scope is measured
against the Project Plan.

Plan Scope ManagementPlan Scope Management
Inputs Tools and Techniques Outputs
1. Project charter
2. Project management plan
3. Enterprise environmental
factors
4. Organizational process Assets
1. Expert Judgment
2. Data Analysis
3. Meetings
1. Scope management plan
2. Requirements management
plan
“The process of creating a scope management plan that documents how the project scope
will be defined, validated, and controlled”.
1. Project charter
factors
1. Expert Judgment
2. Data Analysis
3. Meetings
1. Scope management plan
2. Requirements management
plan

INPUTSINPUTS
1. Project charter
 The project charter is such an important document that project CAN NOT be started
without one.
 A project charter may be created by the project manager but is issued by sponsor in
the initiating process group.
 It is abroad enough so it does not NEED to change as the project progresses.
 It provides the following benefits:
 The project charter formally recognizes (authorizes) the
existence of the project.
 It gives the project manager authority to spend money and
commit corporate resource.
 The project charter provides the high – level requirements for
the project.
 It links the project to the ongoing work of the organization.

INPUTSINPUTS

2. Project Management Plan
 A project management plan is an integration function-it integrates all the knowledge
area management plans into a cohesive whole.
 This plan includes the baselines for the project (Scope, Schedule, Cost) and also it
called performance measurement baselines.
 The project management plan includes:
 Quality management plan.
 Project life cycle description.
 Development approach.
INPUTSINPUTS
2. Project Management Plan
 A project management plan is an integration function-it integrates all the knowledge
area management plans into a cohesive whole.
 This plan includes the baselines for the project (Scope, Schedule, Cost) and also it
called performance measurement baselines.
 The project management plan includes:
 Quality management plan.
 Project life cycle description.
 Development approach.

3. Enterprise Environmental Factors
 Organization’s culture
 Infrastructure
 Personnel administration
 Marketplace conditions.
 Policies and procedures
 Historical information and lessons learned knowledge
base.
INPUTSINPUTS
3. Enterprise Environmental Factors
 Organization’s culture
 Infrastructure
 Personnel administration
 Marketplace conditions.
 Policies and procedures
 Historical information and lessons learned knowledge
base.

1. Expert Judgment
 Expertise may be provided by any group or person with specialized education,
knowledge, skill, experience, or training in developing scope management plans.
2. Data Analysis
 Alternatives analysis.
 Various ways of collecting requirements, elaborating the project and product scope,
creating the product, validating the scope, and controlling the scope are evaluated.
3. Meetings
 Project teams may attend project meetings to develop the scope management plan
 Attendees:
 Project manager
 Project sponsor
 Selected project team members
 Selected stakeholders.
TOOLS AND TECHNIQUESTOOLS AND TECHNIQUES
1. Expert Judgment
 Expertise may be provided by any group or person with specialized education,
knowledge, skill, experience, or training in developing scope management plans.
2. Data Analysis
 Alternatives analysis.
 Various ways of collecting requirements, elaborating the project and product scope,
creating the product, validating the scope, and controlling the scope are evaluated.
3. Meetings
 Project teams may attend project meetings to develop the scope management plan
 Attendees:
 Project manager
 Project sponsor
 Selected project team members
 Selected stakeholders.

OUTPUTSOUTPUTS
1. Scope Management Plan
 How the scope will be planned, executed, and controlled.
 How to achieve the scope
 What tools to use to plan how the project will accomplish the scope
 How to create the WBS
 What enterprise environmental factors and organizational process assets come in
play.
 How the scope will be managed and controlled to the project management plan.
 How to obtain acceptance of deliverables.
1. Scope Management Plan
 How the scope will be planned, executed, and controlled.
 How to achieve the scope
 What tools to use to plan how the project will accomplish the scope
 How to create the WBS
 What enterprise environmental factors and organizational process assets come in
play.
 How the scope will be managed and controlled to the project management plan.
 How to obtain acceptance of deliverables.
“If you cannot plan it, you cannot do it”

OUTPUTSOUTPUTS
2. Requirements management plan
 How requirements activities will be planned, tracked, and reported;
 Configuration management activities.
 Requirements prioritization process.
 Product metrics.
 Traceability structure.
2. Requirements management plan
 How requirements activities will be planned, tracked, and reported;
 Configuration management activities.
 Requirements prioritization process.
 Product metrics.
 Traceability structure.

Collect RequirementsCollect Requirements
1. Project charter
• Scope management plan
• Requirements management plan
• Stakeholder engagement plan
3. Project documents
• Assumption log
• Lessons learned register
• Stakeholder register
4. Business documents
• Business case
5. Agreements
factors
7. Organizational process assets
1. Expert judgment
2. Data gathering
• Brainstorming
• Interviews
• Focus groups
• Questionnaires and surveys
• Benchmarking
3. Data analysis
• Document analysis
4. Decision making
• Voting
• Multicriteria decision analysis
5. Data representation
• Affinity diagrams
• Mind mapping
6. Interpersonal and team skills
• Nominal group technique
• Observation/conversation
• Facilitation
7. Context diagram
8. Prototypes
1. Requirements documentation
2. Requirements traceability
matrix
“The process of defining and documenting stakeholders’ needs to meet the project objectives”
1. Project charter
• Stakeholder engagement plan
• Assumption log
• Business case
5. Agreements
factors
1. Expert judgment
2. Data gathering
• Brainstorming
• Interviews
• Focus groups
• Questionnaires and surveys
• Benchmarking
3. Data analysis
• Document analysis
4. Decision making
• Voting
5. Data representation
• Affinity diagrams
• Mind mapping
• Nominal group technique
• Observation/conversation
• Facilitation
7. Context diagram
8. Prototypes

INPUTSINPUTS
1. Project charter
 The project charter is used to provide the high-level
description of the product, service, or result of the project so
that detailed requirements can be developed.
Requirements
management plan
Stakeholder engagement plan
1. Project charter
 The project charter is used to provide the high-level
description of the product, service, or result of the project so
that detailed requirements can be developed.
Requirements
management plan
Stakeholder engagement plan
Provides clarity as to how
project teams will
determine which type of
requirements need to be
collected for the project.
Provides the processes
that will be used
throughout the Collect
Requirements process to
define and document the
stakeholder needs.
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.

INPUTSINPUTS
 A business document that can influence the Collect Requirements process is the
business case, which can describe required, desired, and optional criteria for
meeting the business needs.
Assumption log Lessons learned register Stakeholder register
Identified assumptions
about the product,
project, environment,
stakeholders, and other
factors that can influence
requirements.
Provides information on
effective requirements
collection techniques,
especially for projects that
are using an iterative or
adaptive product
development methodology.
Identify stakeholders who
can provide information on
the requirements. It also
captures requirements and
expectations that
stakeholders have for the
project.
 A business document that can influence the Collect Requirements process is the
business case, which can describe required, desired, and optional criteria for
meeting the business needs.
Identified assumptions
about the product,
stakeholders, and other
factors that can influence
requirements.
Provides information on
effective requirements
collection techniques,
especially for projects that
are using an iterative or
adaptive product
development methodology.
Identify stakeholders who
can provide information on
the requirements. It also
captures requirements and
expectations that
stakeholders have for the
project.

INPUTSINPUTS
5. Agreements
 Agreements can contain project and product
requirements.
6. Enterprise environmental factors
 Organization’s culture,
 Infrastructure,
 Personnel administration, and
 Marketplace conditions.
 Policies and procedures, and
 Historical information and lessons learned
repository with information from previous
projects.
5. Agreements
 Agreements can contain project and product
requirements.
 Infrastructure,
 Policies and procedures, and
 Historical information and lessons learned
repository with information from previous
projects.

Brainstorming Interviews Focus groups Questionnaires
and surveys
• Benchmarking
1. Expert judgment
 Expertise in Business analysis, Requirements elicitation, Requirements analysis,
Requirements documentation, Project requirements in previous similar projects,
Diagramming techniques, Facilitation, and Conflict management.
2. Data gathering
Brainstorming Interviews Focus groups Questionnaires
and surveys
• Benchmarking
Generate and
collect
multiple ideas
related to
project and
product
requirements.
A formal or
informal
approach to
discover
information
from
stakeholders
by talking
to them
directly.
It bring together
prequalified
stakeholders and
subject matter
experts to learn
about their
expectations and
attitudes about a
proposed product,
service or result.
Present
questions that
help identify
requirements
from the
respondents
and used for
large groups.
It focuses on
measuring an
organization’s
performance against
that of other
organizations in the
same industry.
However, It is very
time consuming and
costly.

3. Data Analysis
 Document analysis consists of reviewing and assessing any relevant documented
information.
 It is used to elicit requirements by analyzing existing documentation and
identifying information relevant to the requirements.
 There is a wide range of documents that may be analyzed to help elicit relevant
requirements.
 Agreements;
 Business plans;
 Business process or interface documentation;
 Business rules repositories;
 Current process flows;
 Marketing literature;
 Problem/issue logs;
 Policies and procedures;
 Regulatory documentation such as laws, codes, or ordinances, etc.;
 Requests for proposal; and
 Use cases.
3. Data Analysis
 Document analysis consists of reviewing and assessing any relevant documented
information.
 It is used to elicit requirements by analyzing existing documentation and
identifying information relevant to the requirements.
 There is a wide range of documents that may be analyzed to help elicit relevant
requirements.
 Agreements;
 Business plans;
 Business process or interface documentation;
 Business rules repositories;
 Current process flows;
 Marketing literature;
 Problem/issue logs;
 Policies and procedures;
 Regulatory documentation such as laws, codes, or ordinances, etc.;
 Requests for proposal; and
 Use cases.

Voting Multi-criteria decision analysis
 Collective decision-making technique and
an assessment process having multiple
alternatives with an expected outcome in
the form of future actions.
 These techniques can be used to generate,
classify and prioritize product requirements.
 Unanimity: Everyone agrees on a single
course of action.
 Majority: Support from more than 50% of
the members of the group.
 Plurality: The largest block in a group
decides even if a majority is not achieved.
 Dictatorship: One individual takes
responsibility for making the decision
 for the group.
 Technique that uses a decision
matrix to provide a systematic
analytical approach for
establishing criteria, such as risk
levels, uncertainty, and valuation,
to evaluate and rank many ideas.
4. Decision making
 Collective decision-making technique and
an assessment process having multiple
alternatives with an expected outcome in
the form of future actions.
 These techniques can be used to generate,
classify and prioritize product requirements.
 Unanimity: Everyone agrees on a single
course of action.
 Majority: Support from more than 50% of
the members of the group.
 Plurality: The largest block in a group
decides even if a majority is not achieved.
 Dictatorship: One individual takes
responsibility for making the decision
 for the group.
 Technique that uses a decision
matrix to provide a systematic
analytical approach for
establishing criteria, such as risk
levels, uncertainty, and valuation,
to evaluate and rank many ideas.

Affinity diagrams Mind mapping
It allows large numbers of ideas to be
sorted into groups for review and
analysis.
A mind map is a diagram of ideas or
notes to help generate, classify, or record
information.
5. Data Representation

Nominal group technique
Observation/
Conversation
Facilitation
 This technique enhances
brainstorming with a
voting process used to
rank the most useful
ideas for further
brainstorming or for
prioritization.
 Helps eliminate biases
and peer-pressure.
 Encourages participation
from all team members.
A direct way of
viewing individuals in
their environment and
how they perform
their jobs or tasks and
carry out processes.
It is helpful for
detailed processes.
Observation is also
known as “job
shadowing.
Focused sessions that bring
key stakeholders together to
define product requirements.
Workshops can be used to
quickly define cross-
functional requirements and
reconcile stakeholder
differences.
Issues can be discovered
earlier and resolved more
quickly.
 This technique enhances
brainstorming with a
voting process used to
rank the most useful
ideas for further
brainstorming or for
prioritization.
 Helps eliminate biases
and peer-pressure.
 Encourages participation
from all team members.
A direct way of
viewing individuals in
their environment and
how they perform
their jobs or tasks and
carry out processes.
It is helpful for
detailed processes.
Observation is also
known as “job
shadowing.
Focused sessions that bring
key stakeholders together to
define product requirements.
Workshops can be used to
quickly define cross-
functional requirements and
reconcile stakeholder
differences.
Issues can be discovered
earlier and resolved more
quickly.

7. Context Diagrams “Context flow level data flow diagram”
 Frequently used to define and model scope.
 It shows the boundaries of the product scope by highlighting the product and its
interfaces with people, processes, or systems.
8. Prototypes
 A prototype is a model of the proposed product. In this technique, the prototype is
presented to stakeholders for feedback.
 The prototype may be updated multiple times to incorporate the feedback until the
requirements have been solidified for the product.
7. Context Diagrams “Context flow level data flow diagram”
 Frequently used to define and model scope.
 It shows the boundaries of the product scope by highlighting the product and its
interfaces with people, processes, or systems.
8. Prototypes
 A prototype is a model of the proposed product. In this technique, the prototype is
presented to stakeholders for feedback.
 The prototype may be updated multiple times to incorporate the feedback until the
requirements have been solidified for the product.

OUTPUTSOUTPUTS
1. Requirements Documentation
 How individual requirements meet the business need for the project.
 Before being base-lined, requirements must be measurable and testable, traceable,
complete, consistent and acceptable to key stakeholders.
 The format of a requirements document may range from a simple document listing
all the requirements categorized by stakeholder and priority, to more elaborate
forms containing executive summary, detailed descriptions, and attachments.
 Business requirements.
 Stakeholder requirements.
 Solution requirements.
 Functional requirements.
 Nonfunctional requirements.
 Transition and readiness requirements.
 Project requirements.
 Quality requirements.
1. Requirements Documentation
 How individual requirements meet the business need for the project.
 Before being base-lined, requirements must be measurable and testable, traceable,
complete, consistent and acceptable to key stakeholders.
 The format of a requirements document may range from a simple document listing
all the requirements categorized by stakeholder and priority, to more elaborate
forms containing executive summary, detailed descriptions, and attachments.
 Business requirements.
 Stakeholder requirements.
 Solution requirements.
 Functional requirements.
 Nonfunctional requirements.
 Transition and readiness requirements.
 Project requirements.
 Quality requirements.

OUTPUTSOUTPUTS
2. Requirements Traceability Matrix
 Helps track the requirements over the life of the project to ensure they are
accomplished.
 The project manager uses the requirements traceability matrix to keep track of all
that information and to analyze requirements when there are proposed changes to
project or product scope.
 This matrix usually takes the form of a table with information like requirement
identification numbers, the source of each requirement, who is assigned to
manage the requirement, and the status of the requirement, including if it is
finished.
 Helps LINK the requirements to the objectives and the other requirements to
ENSURE the strategic goals are accomplished.
2. Requirements Traceability Matrix
 Helps track the requirements over the life of the project to ensure they are
accomplished.
 The project manager uses the requirements traceability matrix to keep track of all
that information and to analyze requirements when there are proposed changes to
project or product scope.
 This matrix usually takes the form of a table with information like requirement
identification numbers, the source of each requirement, who is assigned to
manage the requirement, and the status of the requirement, including if it is
finished.
 Helps LINK the requirements to the objectives and the other requirements to
ENSURE the strategic goals are accomplished.

OUTPUTSOUTPUTS
Example of a Requirements Traceability Matrix

Define ScopeDefine Scope
1. Project charter
• Assumption log
• Requirements documentation
• Risk register
factors
1. Expert judgment
2. Data analysis
• Alternatives analysis
3. Decision making
• Facilitation
5. Product analysis
1. Project scope statement
2. Project documents updates
• Assumption log
• Requirements traceability matrix
“The process of developing a detailed description of the project and
product.”
1. Project charter
• Assumption log
• Risk register
factors
1. Expert judgment
2. Data analysis
• Alternatives analysis
3. Decision making
• Facilitation
5. Product analysis
1. Project scope statement
• Assumption log

INPUTSINPUTS
1. Project charter
 The project charter provides the high-level project description and product
characteristics.
 The scope management plan which documents how the project scope will be
defined, validated, and controlled.
Requirements
documentation
1. Project charter
 The project charter provides the high-level project description and product
characteristics.
 The scope management plan which documents how the project scope will be
defined, validated, and controlled.
Assumption log
Requirements
documentation
Risk register
Identifies assumptions and
constraints about the product,
stakeholders, and other factors
that can influence the project
and product scope.
Identifies requirements
that will be
incorporated into the
scope.
Contains response strategies
that may affect the project
scope, such as reducing or
changing project and
product scope to avoid or
mitigate a risk

INPUTSINPUTS
 Infrastructure,
 Policies, procedures, and templates for a project scope statement;
 Project files from previous projects; and
 Lessons learned from previous phases or projects.
 Infrastructure,
 Policies, procedures, and templates for a project scope statement;
 Project files from previous projects; and
 Lessons learned from previous phases or projects.

1. Expert judgment
 Expertise should be considered from individuals or groups with knowledge of or
experience with similar projects.
2. Data analysis
 Alternatives analysis can be used to evaluate ways to meet the requirements and
the objectives identified in the charter.
3. Decision making
 Multicriteria decision analysis is a technique that uses a decision matrix to
provide a systematic analytical approach for establishing criteria, such as
requirements, schedule, budget, and resources, in order to refine the project and
product scope for the project.
1. Expert judgment
 Expertise should be considered from individuals or groups with knowledge of or
experience with similar projects.
2. Data analysis
 Alternatives analysis can be used to evaluate ways to meet the requirements and
the objectives identified in the charter.
3. Decision making
 Multicriteria decision analysis is a technique that uses a decision matrix to
provide a systematic analytical approach for establishing criteria, such as
requirements, schedule, budget, and resources, in order to refine the project and
product scope for the project.

 Facilitation is used in workshops and working sessions with key stakeholders
who have a variety of expectations or fields of expertise.
 The goal is to reach a cross-functional and common understanding of the project
deliverables and project and product boundaries.
5. Product analysis
 It includes asking questions about a product or service and forming answers to
describe the use, characteristics, and other relevant aspects of what is going to be
delivered.
 Each application area has one or more generally accepted methods for translating
high-level product or service descriptions into meaningful deliverables.
 Product breakdown,
 Requirements analysis,
 Systems analysis,
 Systems engineering,
 Value analysis, and
 Value engineering.
 Facilitation is used in workshops and working sessions with key stakeholders
who have a variety of expectations or fields of expertise.
 The goal is to reach a cross-functional and common understanding of the project
deliverables and project and product boundaries.
5. Product analysis
 It includes asking questions about a product or service and forming answers to
describe the use, characteristics, and other relevant aspects of what is going to be
delivered.
 Each application area has one or more generally accepted methods for translating
high-level product or service descriptions into meaningful deliverables.
 Product breakdown,
 Requirements analysis,
 Systems analysis,
 Systems engineering,
 Value analysis, and
 Value engineering.

OUTPUTSOUTPUTS
1. Project Scope Statement
 The project statement of work is created by the customer/sponsor and describes
their needs, product scope and how the project fits into their strategic plan.
 A written scope statement is necessary for both projects and subprojects.
 Forms the basis for an agreement between the project team and the customer by
identifying both the project objectives and the major product deliverables.
1. Project Scope Statement
 The project statement of work is created by the customer/sponsor and describes
their needs, product scope and how the project fits into their strategic plan.
 A written scope statement is necessary for both projects and subprojects.
 Forms the basis for an agreement between the project team and the customer by
identifying both the project objectives and the major product deliverables.
• Constraints • Assumptions
 Factors that limit the team's options,
such as limits on resources, budget,
schedule, and scope.
 Things that are assumed to be true but
that may not be true.
 Assumptions analysis is part of the
risk management process.

OUTPUTSOUTPUTS
• Product scope
description
• Deliverables
• Acceptance
criteria
• Project exclusions
Progressively
elaborates the
characteristics
of the product,
service, or result
described in the
project charter
and
requirements
documentation.
Any unique and verifiable
product, result, or capability
to perform a service that is
required to be produced to
complete a process, phase, or
project. Deliverables also
include ancillary results,
such as project management
reports and documentation.
These deliverables may be
described at a summary level
or in great detail.
A set of
conditions that
is required to
be met before
deliverables are
accepted.
Identifies what is
excluded from the
project.
Explicitly stating what
is out of scope for the
project helps manage
stakeholders’
expectations and can
reduce scope creep.
Progressively
elaborates the
characteristics
of the product,
service, or result
described in the
project charter
and
requirements
documentation.
Any unique and verifiable
product, result, or capability
to perform a service that is
required to be produced to
complete a process, phase, or
project. Deliverables also
include ancillary results,
such as project management
reports and documentation.
These deliverables may be
described at a summary level
or in great detail.
A set of
conditions that
is required to
be met before
deliverables are
accepted.
Identifies what is
excluded from the
project.
Explicitly stating what
is out of scope for the
project helps manage
stakeholders’
expectations and can
reduce scope creep.

OUTPUTSOUTPUTS
Project Charter Tools and Techniques
• Project purpose
• Measurable project objectives and related
success criteria
• High-level requirements
• High-level project description, boundaries,
and key deliverables
• Overall project risk
• Summary milestone schedule
• Preapproved financial resources
• Key stakeholder list
• Project approval requirements
• Project exit criteria
• Assigned project manager, responsibility,
and authority level
• Name and authority of the sponsor or other
person(s) authorizing the project charter
• Project scope description (progressively
• elaborated)
• Project deliverables
• Acceptance criteria
 The project charter contains highlevel information, while the project scope statement
contains a detailed description of the scope components.
 These components are progressively elaborated throughout the project.
• Project purpose
• Measurable project objectives and related
success criteria
• High-level requirements
• High-level project description, boundaries,
and key deliverables
• Overall project risk
• Summary milestone schedule
• Preapproved financial resources
• Key stakeholder list
• Project approval requirements
• Project exit criteria
• Assigned project manager, responsibility,
and authority level
• Name and authority of the sponsor or other
person(s) authorizing the project charter
• Project scope description (progressively
• elaborated)
• Project deliverables
• Acceptance criteria

OUTPUTSOUTPUTS
• Assumption log
• Requirements
documentation
• Requirements
traceability matrix
It is updated with
additional
assumptions or
constraints that
were identified
during this process.
It may be
updated
with additional
or changed
requirements.
It may be updated
to reflect updates
in requirement
documentation.
Where additional
information on existing or
new
stakeholders is gathered
as a result of this process,
it is recorded in the
stakeholder register.
It is updated with
additional
assumptions or
constraints that
were identified
during this process.
It may be
updated
with additional
or changed
requirements.
It may be updated
to reflect updates
in requirement
documentation.
Where additional
information on existing or
new
stakeholders is gathered
as a result of this process,
it is recorded in the
stakeholder register.

Create WBSCreate WBS
• Project Scope Statement
factors
1. Expert judgment
2. Decomposition
1. Scope baseline
• Assumption log
“Process of subdividing project deliverables and project work into smaller,
more manageable components.”
• Project Scope Statement
factors
1. Expert judgment
2. Decomposition
1. Scope baseline
• Assumption log

INPUTSINPUTS
 The scope management plan which documents how
the project scope will be defined, validated, and
controlled.
Project Scope Statement Requirements documentation
 The scope management plan which documents how
the project scope will be defined, validated, and
controlled.
It describes the work that will be
performed and the work that is
excluded.
Detailed requirements describe how
individual requirements meet the
business need for the project.

INPUTSINPUTS
 Industry-specific WBS standards that are relevant
to the nature of the project. These industry-specific
standards may serve as external reference sources
for creating the WBS.
 Policies, procedures, and templates for the WBS;
 Project flies from previous projects; and
 Lessons learned from previous projects.
 Industry-specific WBS standards that are relevant
to the nature of the project. These industry-specific
standards may serve as external reference sources
for creating the WBS.
 Policies, procedures, and templates for the WBS;
 Project flies from previous projects; and
 Lessons learned from previous projects.

1. Expert judgment
 Expert judgment is often used to analyze the information needed to decompose the
project deliverables down into smaller component parts in order to create an
effective WBS.
 Expert judgment can also come in the form of predefined templates that provide
guidance on how to effectively break down common deliverables. Such templates
may be industry or discipline specific or may come from experience gained in
similar projects
1. Expert judgment
 Expert judgment is often used to analyze the information needed to decompose the
project deliverables down into smaller component parts in order to create an
effective WBS.
 Expert judgment can also come in the form of predefined templates that provide
guidance on how to effectively break down common deliverables. Such templates
may be industry or discipline specific or may come from experience gained in
similar projects

2. Decomposition
 The technique of subdividing major project deliverables into smaller, more
manageable components until the deliverables are defined in sufficient detail to
support development of project activities.
 Many organizations will consider a activity defined clearly enough to estimate cost
and duration if the activity duration is between 8 and 80 hours.
 In some cases, the item is defined clearly enough to assign to an organization unit,
such as a specific department, and will then be budgeted and scheduled by that
unit.
 Some items cannot be further defined until a later phase of the project.
 You can decompose the project using a WBS
2. Decomposition
 The technique of subdividing major project deliverables into smaller, more
manageable components until the deliverables are defined in sufficient detail to
support development of project activities.
 Many organizations will consider a activity defined clearly enough to estimate cost
and duration if the activity duration is between 8 and 80 hours.
 In some cases, the item is defined clearly enough to assign to an organization unit,
such as a specific department, and will then be budgeted and scheduled by that
unit.
 Some items cannot be further defined until a later phase of the project.
 You can decompose the project using a WBS

OUTPUTSOUTPUTS
1. Scope Baseline
 The approved version of a scope statement, WBS, and its associated WBS
dictionary, which can be changed only through formal change control procedures
and is used as a basis for comparison.
• Project scope
statement
• WBS • Work Package • Planning package
The description of
the project scope,
major
deliverables,
assumptions, and
constraints.
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
he lowest level of
the WBS is a work
package with a
unique identifier.
A work breakdown
structure component
below the control
account and above the
work package with
known work content
but without detailed
schedule activities.
The description of
the project scope,
major
deliverables,
assumptions, and
constraints.
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
he lowest level of
the WBS is a work
package with a
unique identifier.
A work breakdown
structure component
below the control
account and above the
work package with
known work content
but without detailed
schedule activities.

OUTPUTSOUTPUTS
Work Breakdown Structure “WBS”
 A deliverable oriented grouping of project components that organizes and defines
the total scope of the project.
 It breaks project into smaller and more manageable pieces.
 The WBS organizes and defines the total scope of the project.
 It subdivides the project work into smaller, more manageable pieces of work.
 Each descending level of the WBS represents an increasingly detailed definition of
the project work.
 The planned work contained within the lowest-level WBS components are called
work packages.
 Work packages can be scheduled, cost estimated, monitored, and controlled.
Work Breakdown Structure “WBS”
 A deliverable oriented grouping of project components that organizes and defines
the total scope of the project.
 It breaks project into smaller and more manageable pieces.
 The WBS organizes and defines the total scope of the project.
 It subdivides the project work into smaller, more manageable pieces of work.
 Each descending level of the WBS represents an increasingly detailed definition of
the project work.
 The planned work contained within the lowest-level WBS components are called
work packages.
 Work packages can be scheduled, cost estimated, monitored, and controlled.

OUTPUTSOUTPUTS
Identifies all
the
deliverables
to be
completed
Is the
foundation
upon which
the project is
built.
Is VERY
important.
Should exist
for every
project.
Forces you to
think through
all aspects of
the project.
WBS
Is a graphical
picture of the
hierarchy of
the project.
Identifies all
the
deliverables
to be
completed
Can be reused
for other
projects.
Does NOT
show
dependencies
.

OUTPUTSOUTPUTS
Widget Mgmt. System
1
Initiation
1.1
Planning
1.2
Execution
1.3
Control
1.4
Create Preliminary Scope
Statement
1.2.1
Closeout
1.5
Evaluation & Recommendations
1.1.1
Develop Project Charter
1.1.2
Deliverable: Submit Project
Charter
1.1.3
Project Sponsor Reviews
Project Charter
1.1.4
Determine Project Team
1.2.2
Project Team Kickoff Meeting
1.2.3
Project Kickoff Meeting
1.3.1
Verify & Validate User
Requirements
1.3.2
Design System
1.3.3
Project Management
1.4.1
Project Status Meetings
1.4.2
Risk Management
1.4.3
Update Project Management
Plan
1.4.4
Audit Procurement
1.5.1
Document Lessons Learned
1.5.2
Update Files/ Records
1.5.3
Project Sponsor Reviews
Project Charter
1.1.4
Project Charter
Signed/Approved
1.1.5
Develop Project Plan
1.2.4
Submit Project Plan
1.2.5
Milestone: Project Plan
Approved
1.2.6
Procure Hardware/Software
1.3.4
Install Development System
1.3.5
Testing Phase
1.3.6
Install Live System
1.3.7
User Training
1.3.8
Go Live
1.3.9
Update Project Management
Plan
1.4.4
Gain Formal Acceptance
1.5.4
Archive Files/ Documents
1.5.5

OUTPUTSOUTPUTS
Helps prevent work slipping through the cracks.Helps prevent work slipping through the cracks.
Provides project team with understanding of the pieces.Provides project team with understanding of the pieces.
Gives project team indication of the impact of their work.Gives project team indication of the impact of their work.
Benefits of WBS
Gives project team indication of the impact of their work.Gives project team indication of the impact of their work.
Facilitates communication and cooperation among team andFacilitates communication and cooperation among team and
stakeholders.stakeholders.
Helps prevent changes.Helps prevent changes.

OUTPUTSOUTPUTS
The WBS dictionary
 Provides a description of the work to be done for each WBS work package and helps
make sure the resulting work better matches what is needed.
The WBS dictionary contains:
 Code of account identifier,
 Description of work,
 Assumptions and constraints,
 Responsible organization,
 Schedule milestones,
 Associated schedule activities,
 Resources required,
 Cost estimates,
 Quality requirements,
 Acceptance criteria,
 Technical references, and
 Agreement information.
The WBS dictionary contains:
 Code of account identifier,
 Description of work,
 Assumptions and constraints,
 Responsible organization,
 Schedule milestones,
 Associated schedule activities,
 Resources required,
 Cost estimates,
 Quality requirements,
 Acceptance criteria,
 Technical references, and
 Agreement information.

OUTPUTSOUTPUTS
WBS
Control
Accounts
Work Package:
 The lowest level of the WBS is a work package with a unique
identifier.
 These identifier 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.
 The level they feel appropriate to manage the project.
Work
Packages
Activities
Work Package:
 The lowest level of the WBS is a work package with a unique
identifier.
 These identifier 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.
 The level they feel appropriate to manage the project.
Control Accounts
 A management control point where scope, budget, and schedule
are integrated and compared to the earned value for performance
measurement.
 It has two or more work packages, though each work package is
associated with a single control account.

OUTPUTSOUTPUTS
• Assumption log • Requirements documentation
It is updated with additional assumptions
or constraints that were identified during
the Create WBS process.
It may be updated to include approved
changes resulting from the Create WBS
process.

Validate ScopeValidate Scope
• Requirements management
plan
• Scope baseline
• Quality reports
3. Verified deliverables
4. Work performance data
1. Inspection
2. Decision making
• Voting
1. Accepted deliverables
2. Work performance information
3. Change requests
4. Project document updates
“Process of formalizing acceptance of the completed project deliverables.”
• Requirements management
plan
• Scope baseline
• Quality reports
1. Inspection
2. Decision making
• Voting
3. Change requests

INPUTSINPUTS
Scope management plan
Requirements
management plan
Scope baseline
Specifies how formal
acceptance of the
completed project
deliverables will be
obtained.
Describes how the project
requirements are validated.
Compared to actual
results to determine if a
change, corrective action,
or preventive action is
necessary.
Specifies how formal
acceptance of the
completed project
deliverables will be
obtained.
Compared to actual
necessary.

INPUTSINPUTS
Lessons learned
register
Quality reports
Requirements
documentation
Requirements
traceability
matrix
Lessons learned earlier
in the project can be
applied to
later phases in the
project to improve the
efficiency and
effectiveness of
validating deliverables.
All quality assurance
issues managed or
escalated by the team,
recommendations for
improvement, and the
summary of findings
from the Control
Quality process.
Requirements are
compared to the
actual results to
determine if a
change, corrective
action, or
preventive action
is necessary.
The requirements
traceability
matrix contains
information about
requirements,
including how
they will be
validated.
applied to
later phases in the
project to improve the
efficiency and
effectiveness of
validating deliverables.
All quality assurance
issues managed or
escalated by the team,
recommendations for
improvement, and the
summary of findings
from the Control
Quality process.
Requirements are
compared to the
actual results to
determine if a
change, corrective
action, or
preventive action
is necessary.
The requirements
traceability
matrix contains
information about
requirements,
including how
they will be
validated.

INPUTSINPUTS
 Verified deliverables are project deliverables
that are completed and checked for correctness
through the Control Quality process.
 Work performance data can include the degree of compliance with requirements,
number of nonconformities, severity of the nonconformities, or the number of
validation cycles performed in a period of time.
 Work performance data can include the degree of compliance with requirements,
number of nonconformities, severity of the nonconformities, or the number of
validation cycles performed in a period of time.

1. Inspection
 It includes activities such as measuring,
examining, and validating to determine whether
work and deliverables meet requirements and
product acceptance criteria.
 Inspections are sometimes called reviews, product
reviews, and walkthroughs.
 In some application areas, these different terms
have unique and specific meanings.
2. Decision Making
 Voting is used to reach a conclusion when the
validation is performed by the project team and
other stakeholders.
1. Inspection
 It includes activities such as measuring,
examining, and validating to determine whether
work and deliverables meet requirements and
product acceptance criteria.
 Inspections are sometimes called reviews, product
reviews, and walkthroughs.
 In some application areas, these different terms
have unique and specific meanings.
2. Decision Making
 Voting is used to reach a conclusion when the
validation is performed by the project team and
other stakeholders.

OUTPUTSOUTPUTS
 Deliverables that meet the acceptance criteria are formally
signed off and approved by the customer or sponsor.
 Formal documentation received from the customer or
sponsor acknowledging formal stakeholder acceptance of the
project’s deliverables is forwarded to the Close Project or
Phase process
 Deliverables that meet the acceptance criteria are formally
signed off and approved by the customer or sponsor.
 Formal documentation received from the customer or
sponsor acknowledging formal stakeholder acceptance of the
project’s deliverables is forwarded to the Close Project or
Phase process
 Information about project progress, such as which deliverables have started, their
progress, which deliverables have finished, or which have been accepted.

OUTPUTSOUTPUTS
3. Change requests
 Those completed deliverables that have NOT been formally
accepted are documented, along with the reasons for non-
acceptance.
• Requirements
traceability matrix
• Lessons learned register • Requirements documentation
• Requirements
traceability matrix
Updated with information on
challenges encountered and
how they could have been
avoided as well as
approaches that worked well
for validating deliverables.
Updated with the actual results
of validation activity.
Of particular interest is when the
actual results are better than the
requirement or where a
requirement was waived.
Updated with the
results of the
validation,
including the
method used and
the outcome.

OUTPUTSOUTPUTS
Validated and
approved
change request
Direct and
Manage
Project Work
Quality
Control
ChangeChange
RequestRequest
DeliverablesDeliverables
Relationship between Validate Scope and Control Quality
Validated and
approved
change request
Quality
Control
Validate
Scope
ChangeChange
RequestRequest
AcceptedAccepted
VerifiedVerified
Close Project
or Phase

Control ScopeControl Scope
• Change management plan
• Configuration management plan
• Scope baseline
• Performance measurement
baseline
1. Data analysis
• Variance analysis
• Trend analysis
2. Change requests
updates
• Scope baseline
• Schedule baseline
• Cost baseline
baseline
• Requirements traceability
matrix
“Process of monitoring the status of the project and product scope and
managing changes to the scope baseline.”
• Change management plan
• Configuration management plan
• Scope baseline
baseline
1. Data analysis
• Variance analysis
• Trend analysis
2. Change requests
updates
• Scope baseline
• Schedule baseline
• Cost baseline
baseline
• Requirements traceability
matrix

INPUTSINPUTS
Scope management plan
Requirements
management plan
Change management plan
Documents how the project
and product scope will be
controlled.
Describes how the project
requirements will be
managed.
Defines the process
for managing change on
the project.
Configuration management
plan
Scope baseline Performance
measurement baseline
Configuration management
plan
Scope baseline Performance
measurement baseline
Defines those items that are
configurable, those items
that require formal change
control, and the process for
controlling changes to such
items.
Compared to actual
necessary.
Compared to actual
necessary.

INPUTSINPUTS
Lessons learned
register
Requirements
documentation
Requirements traceability matrix
applied to later phases
in the project to
improve scope control.
Requirements
documentation is used
to detect any deviation
in the agreed-upon
scope for the project or
product.
he requirements traceability matrix
helps to detect the impact of any
change or deviation from the scope
baseline on the project objectives. It
may also provide status of
requirements being controlled.
applied to later phases
in the project to
improve scope control.
Requirements
documentation is used
to detect any deviation
in the agreed-upon
scope for the project or
product.
he requirements traceability matrix
helps to detect the impact of any
change or deviation from the scope
baseline on the project objectives. It
may also provide status of
requirements being controlled.

INPUTSINPUTS
 The number of change requests
received, the number of requests
accepted, and the number of
deliverables verified, validated, and
completed.
 Existing formal and informal
scope, control-related policies,
procedures, guidelines; and
 Monitoring and reporting
methods and templates to be
used.
 The number of change requests
received, the number of requests
accepted, and the number of
deliverables verified, validated, and
completed.
 Existing formal and informal
scope, control-related policies,
procedures, guidelines; and
 Monitoring and reporting
methods and templates to be
used.

1. Data Analysis
Variance analysis Trend analysis
Compare the baseline to the actual results
and determine if the variance is within the
threshold amount or if corrective or
preventive action is appropriate.
Examines project performance over time
to determine if performance is
improving or deteriorating.
Compare the baseline to the actual results
and determine if the variance is within the
threshold amount or if corrective or
preventive action is appropriate.

OUTPUTSOUTPUTS
 Correlated and contextualized information on how the project and product scope
are performing compared to the scope baseline.
 It can include the categories of the changes received, the identified scope variances
and their causes, how they impact schedule or cost, and the forecast of the future
scope performance.
 Correlated and contextualized information on how the project and product scope
are performing compared to the scope baseline.
 It can include the categories of the changes received, the identified scope variances
and their causes, how they impact schedule or cost, and the forecast of the future
scope performance.
2. Change requests
 Analysis of project performance may result in a change request
to the scope and schedule baselines or other components of the
project management plan.

OUTPUTSOUTPUTS
3. Project management plan updates
Scope management plan Scope baseline Schedule baseline
Updated to reflect a change
in how the scope is managed.
Changes to the scope
baseline are incorporated
in response to approved
changes in scope, scope
statement, the WBS, or the
WBS dictionary.
Changes to the schedule
changes in scope,
resources, or schedule
estimates.
Changes to the scope
changes in scope, scope
statement, the WBS, or the
WBS dictionary.
Changes to the schedule
changes in scope,
resources, or schedule
estimates.
Cost baseline Performance measurement baseline
Changes to the cost baseline
are incorporated in response
to approved changes in
scope, resources, or cost
estimates.
Changes to the performance measurement baseline are
incorporated in response to approved changes in scope,
schedule performance, or cost estimates.

OUTPUTSOUTPUTS
Lessons learned register
Requirements
documentation
Requirements traceability
matrix
Updated with techniques that
are efficient and effective in
controlling scope, including
causes of variances and
corrective actions chosen.
Updated with additional
or changed requirements.
Updated to reflect updates
in requirement
documentation.
Updated with techniques that
are efficient and effective in
controlling scope, including
causes of variances and
corrective actions chosen.

Scope CreepScope Creep
 Scope creep refers to the change in a project's scope after the project work has started.
Typically, the scope expands by the addition of new features to an already approved
feature list. As a result, the project drifts away from its original purpose, timeline,
and budget. The main causes of scope creep are:
 Poor Requirements Analysis.
 Not Involving the Users Early Enough.
 Lack of proper initial identification of what is required.
 Disingenuous customer with a determined "value for free" policy.
 Underestimating the Complexity of the Project.
 Lack of Change Control.
 Poor communication between parties.
 Weak project manager or executive sponsor.
 Scope creep refers to the change in a project's scope after the project work has started.
Typically, the scope expands by the addition of new features to an already approved
feature list. As a result, the project drifts away from its original purpose, timeline,
and budget. The main causes of scope creep are:
 Poor Requirements Analysis.
 Not Involving the Users Early Enough.
 Lack of proper initial identification of what is required.
 Disingenuous customer with a determined "value for free" policy.
 Underestimating the Complexity of the Project.
 Lack of Change Control.
 Poor communication between parties.
 Weak project manager or executive sponsor.
Project manager uses WBS Dictionary as a tool of project
management to prevent scope creep.

Scope CreepScope Creep

 This term is given to the practice of exceeding the scope of a project in the belief
that value is being added.
 You should give the customer what they asked for, no more and no less. Giving
any extras is a waste of time and adds NO benefit to the Project.
 Gold Plating increases risk and uncertainty and may inject a host of potential
problems into the project.
Gold PlatingGold Plating
 This term is given to the practice of exceeding the scope of a project in the belief
that value is being added.
 You should give the customer what they asked for, no more and no less. Giving
any extras is a waste of time and adds NO benefit to the Project.
 Gold Plating increases risk and uncertainty and may inject a host of potential
problems into the project.

RefreshmentsRefreshments
Q1: Which of the following statements is true about the work breakdown
structure (WBS)?
A. 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.
B. The WBS is a simple list of project activities in chart form.
C. The WBS is the same as the organizational breakdown structure (OBS).
D. The WBS is the bill of materials (BOM) needed to accomplish the project
objectives and create the required deliverables.
Q1: Which of the following statements is true about the work breakdown
structure (WBS)?
A. 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.
B. The WBS is a simple list of project activities in chart form.
C. The WBS is the same as the organizational breakdown structure (OBS).
D. The WBS is the bill of materials (BOM) needed to accomplish the project
objectives and create the required deliverables.

Q2: Which of the following Is true .about the Validate Scope process?
A. It is the process of formalizing acceptance of the completed project
deliverables.
B. It is not necessary if the project completes on time and within budget.
C. It occurs primarily when revisions or changes are made to project scope.
D. Scope validation is primarily concerned with correctness of the
deliverables, whereas quality control is primarily concerned with
acceptance of the deliverables and meeting the quality requirements
specified for the deliverables.
Q2: Which of the following Is true .about the Validate Scope process?
A. It is the process of formalizing acceptance of the completed project
deliverables.
B. It is not necessary if the project completes on time and within budget.
C. It occurs primarily when revisions or changes are made to project scope.
D. Scope validation is primarily concerned with correctness of the
deliverables, whereas quality control is primarily concerned with
acceptance of the deliverables and meeting the quality requirements
specified for the deliverables.

Q3: One of the stakeholders on the project contacts the project manager to
discuss some additional scope they would like to add to the project. The
project manager asks for details in writing and then works through the
Control Scope process. What should the project manager do NEXT when the
evaluation of the requested scope is complete?
A. Ask the stakeholder if there are any more changes expected.
B. Complete integrated change control.
C. Make sure the impact of the change is understood by the stakeholder.
D. Find out the root cause of why the scope was not discovered during
project planning.
Q3: One of the stakeholders on the project contacts the project manager to
discuss some additional scope they would like to add to the project. The
project manager asks for details in writing and then works through the
Control Scope process. What should the project manager do NEXT when the
evaluation of the requested scope is complete?
A. Ask the stakeholder if there are any more changes expected.
B. Complete integrated change control.
C. Make sure the impact of the change is understood by the stakeholder.
D. Find out the root cause of why the scope was not discovered during
project planning.

Q4: Agile scope planning is especially useful when:
A. Solution requirements are emerging all the time.
B. Quality requirements are not stable.
C. Business requirements are not stable.
D. Scope is well understood at the beginning .
Q5: Which of the following is CORRECT in regard to the Control Scope
process?
A. Effective scope definition can lead to a more complete project scope
statement.
B. The Control Scope process must be done before scope planning.
C. The Scope Control process must be integrated with other control
processes.
D. Controlling the schedule is the most effective way of controlling scope.
Q4: Agile scope planning is especially useful when:
A. Solution requirements are emerging all the time.
B. Quality requirements are not stable.
C. Business requirements are not stable.
D. Scope is well understood at the beginning .
Q5: Which of the following is CORRECT in regard to the Control Scope
process?
A. Effective scope definition can lead to a more complete project scope
statement.
B. The Control Scope process must be done before scope planning.
C. The Scope Control process must be integrated with other control
processes.
D. Controlling the schedule is the most effective way of controlling scope.

2_Project Scope Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 2_Project Scope Management

Similar to 2_Project Scope Management (20)

More from Hisham Haridy MBA, PMP®, RMP®, SP®

More from Hisham Haridy MBA, PMP®, RMP®, SP® (20)

Recently uploaded

Recently uploaded (15)

2_Project Scope Management