In Scope

Out Of Scope

PROJECT SCOPE
MANAGEMENT
“ What Exactly you should be working on ? “
Unit Objectives
After completing this unit, you should be able to:

Have an increased understanding of Project Scope

Management processes and how they relate to the
overall project

Understand the five Project Scope Management

processes
• Plan Scope
• Collect Requirement
• Define Scope
• Create WBS
• Validate Scope
• Control Scope
 What is a Scope Management
Project Scope Management: Includes the processes required
to ensure that the project includes all the work required, and only
the work required, to complete the project successfully.

Primarily concerned with defining and controlling what is or is not in the project.

• In the project context the term scope can refer to:

Product scope
• The Features and functions that characterize a product, service or
result.

Project scope
• The work that needs be accomplished to deliver a product, service,
or result within the specified features and functions.
5
Scope Management
5.1 Plan Scope
Processes
The process of creating scope management plan that
document how the scope will be defined , validated and
controlled.
5.2 Collect Requirements
The process of defining and documenting stakeholders’ needs
to meet the project objectives.

5.3 Define Scope

The process of developing a detailed description of the project
and product.

5.4 Create WBS

The process of subdividing project deliverables and project
work into smaller, more manageable components.

5.5 Validate Scope

The process of formalizing acceptance of the completed
project deliverables.

5.6 Control Scope

The process of monitoring the status of the project and
product scope and managing changes to the scope baseline.
SCOPE PLAN (5.1)
 The process of creating scope management plan that document
how the scope will be defined , validated and controlled.

 The key Benefit of this process is that it provides guidance and

direction on how scope will be managed throughout the project .

 Inputs , Tools and techniques and outputs of the processes

should be defined .
SCOPE PLAN (5.1)
Project Charter ( Inputs)
The project charter is used to provide the high-
level project requirements and high-level
product description of the project.

Project Plan ( Inputs)

Document that describes how the project will
be executed, monitored, and controlled. It
integrates and consolidates all of the
subsidiary plans and baselines from the
planning processes.
Organizational Process Assets
(Inputs)
•Policies, procedures, and templates for a project
scope statement,
•Historical Information & Lessons learned from
previous phases or projects.
Environmental Factors (Inputs)
•Organization’s Culture , Personal Administration
•Infrastructure , Marketplace conditions
SCOPE PLAN(5.1)
Expert judgment (Tools & Techniques)

Refers to input received from

knowledgeable and experienced parties.
Expertise may be provided by any group or
person with specialized education,
knowledge, skill, experience, or training in
developing scope management plans.

Meetings (Tools & Techniques)

•Team may attend project meetings to
develop scope plan ( Project manager ,
Team members , stakeholders , any one
involved in scope management )
SCOPE PLAN(5.1)
• Scope Plan (Output)
• Document used to describe how the scope will
be defined , developed , monitored and controlled ,
verified :
• Process of preparing detailed project scope
statement .
• How to create WBS Work breakdown
structure
• How scope will be changed .
• How formal acceptance of the completed
project deliverables will be obtained;

• Requirements Management Plan (Output)

•How requirements will be, analyzed, documented
and managed throughout the project.
•Requirements prioritization process
•Product metrics that will be used
•Traceability Structure
SCOPE PLAN(5.1)
COLLECT REQUIREMENTS (5.2)
 The process of defining and documenting stakeholders’
needs to meet the project objectives.
 The project’s success is directly influenced by the care taken
in capturing and managing project and product requirements.
 Requirements become the foundation of the Scope Baseline .
 Cost , Schedule, and Quality planning are all built upon
these requirements.

 Project Requirement : 1. Business Requirements, 2. Project

Management Requirements, 3. Delivery Requirements, and 4.
Political Requirements.
 Product Requirement : 1. Technical Requirements, 2. Security
Requirements, 3. Performance Requirements, 4. Cost Requirements,
and 5. Quality Requirements.
COLLECT REQUIREMENTS (5.2)
• Project Charter ( Inputs)
The project charter is used to provide the high-
level project requirements and high-level product
description of the project.

• Scope Plan (Inputs )

Document used to describe how the scope will be
defined , developed , monitored and controlled ,
verified

• Stakeholder Register ( Inputs)

The stakeholder register is used to identify
stakeholders that can provide information on
detailed project and product requirements

• Requirement Plan ( Inputs)

How requirements will be, analyzed, documented
and managed throughout the project.
COLLECT REQUIREMENTS (5.2)
Interviews (Tools & Techniques)
 Prepared Questions & Response
( Open Question / Closed Question . Ex Yes/No )

Focus groups (Tools & Techniques)

bring together prequalified stakeholders and
experts to learn about their expectations .

Facilitated Workshops (Tools & Techniques)

Requirements workshops are sessions that
bring key cross-functional stakeholders
together to define product requirements .
( Ex. Pilot , JAD Joint Application Design )
 Collect Requirements (5.2)
GROUP CREATIVITY TECHNIQUES (TOOLS &
TECHNIQUES)

• Brainstorming.
• Nominal group technique.
• The Delphi technique.
• Idea/ mind mapping.

Questionnaires and Surveys

(Tools & Techniques)

Observations (Tools & Techniques)

Prototypes (Tools & Techniques)

 Collect Requirements (5.2)
GROUP DECISION MAKING TECHNIQUES (TOOLS &
TECHNIQUES)

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 makes the decision for the group.
COLLECT REQUIREMENTS (5.2)
•Requirement Documentation (Output)
describes how individual requirements meet the
business need for the project.
• Product and project requirements register
• Functional Requirement , Non-Functional
• Acceptance Criteria .
• Quality Requirement
• Business Rules
• Impacts ( Inside – Outside )
• Support / Training.
• Assumptions / Constrains

•Requirements Traceability Matrix (Output)

Is a table that links requirements to their origin and
traces them throughout the project life cycle.
Attributes :
•Unique Identifier , Textual Description
•Owner Source , Priority , Status , Date
Complete
COLLECT REQUIREMENTS ).5
inputs
Project charter . 1
Stakeholder register . 2

Tools & techniques outputs

Interviews . 1 Requirements . 1
Focus groups . 2 documentations
Facilitated workshops . 3
Requirements . 2
Group creativity techniques . 4
management plan
Group decision making techniques . 5
Questionnaires and surveys . 6 Requirements . 3
Observations . 7 traceability matrix
prototypes .8
COLLECT REQUIREMENTS (5.2)
DEFINE SCOPE (5.3)

 The process of developing a detailed

description of the project and product.

 Preparation of a detailed project scope

statement is critical to the success of the
project and builds on the major deliverables,
assumptions, and constraints documented
during project initiation
DEFINE SCOPE (5.3)
Project Charter (Inputs)
The project charter is used to provide the high-
level project requirements and high-level product
description of the project.

Requirements Documentation (Inputs)

Product and project requirements register

Organizational Process Assets (Inputs)

Examples of organizational process assets that can
influence the Define Scope process include, but are not
limited to:

•Policies, procedures, and templates for a project scope

statement,
•Project files from previous projects, and
•Lessons learned from previous phases or projects.
DEFINE SCOPE (5.3)
Expert judgment (Tools & Techniques)
Judgment & Expertise applied to any technical details

Product Analysis (Tools & Techniques)

•For projects that have a product as a deliverable, as

opposed to a service or result, product analysis can be an
effective tool.

•Product analysis includes techniques such as product

breakdown, systems analysis, systems engineering.

Alternatives Identification (Tools & Techniques)

•Identifying alternatives is a technique used to generate

different approaches to execute and perform the work of
the project.

Facilitated Workshop
DEFINE SCOPE (5.3)
Project Scope Statement (Outputs)

The project scope statement describes, in detail, the project’s

deliverables and the work required to create those deliverables
• Product scope description : Progressively elaborates the
characteristics of the product, service, or result that as described in
the project charter
• Project deliverables : Deliverables include both the outputs
that comprise the product or service of the project, The deliverables
may be described at a summary level or in great detail
• Project boundaries : Generally identifies what is included
within the project. It states explicitly what is out of scope for the
project.
• Product acceptance criteria : Defines the process and
criteria for accepting completed products
• Project constraints and Assumptions :Lists and describes the
specific project constraints and assumptions associated with the
project scope that limits the team’s options
DEFINE SCOPE (5.3)
DEFINE SCOPE (5.3)

inputs
Project charter . 1
Requirements documentation . 2
Organizational process assets . 3

Tools & techniques

Expert judgment . 1
Product analysis . 2
Alternatives identification . 3
Facilitated workshops . 4
outputs
Project scope statement . 1
Project document updates . 2
DURING WHAT PART OF THE PROJECT
MANAGEMENT PROCESS IS THE
PROJECT SCOPE STATEMENT
CREATED ?

A ) Initiating.

B ) Planning.

C ) Executing.

D ) Monitoring and controlling.

DEFINE SCOPE (5.3)
CREATE WBS (5.4)

 Process of subdividing the major project

deliverables and project work into smaller,
more manageable components
 A deliverable-oriented hierarchical
decomposition of the work to be executed by
the project team to accomplish the project
objectives and create the required
deliverables
 Organizes and defines the total scope of the
project
 WBS represents the work specified in the
current approved project scope statement
CREATE WBS (5.4)
Project Scope Statement ( Inputs)
Project Deliverables & the work required to create
those deliverables , acceptance criteria , exclusions ,
constraints .

Requirements Documentation ( Inputs)

Describes how individual
Requirements meet
The business need for the
Project

Organizational Process
Assets (Inputs)
1. Policies , Procedures , Templates
2. Lessons learnt & Project files from previous
projects
CREATE WBS (5.4)
Decomposition (Tools & Techniques)
A planning technique that subdivides the project scope and project deliverables
into smaller, more manageable components, until the project work associated with
accomplishing the project scope and providing the deliverables is defined in
sufficient detail to support executing , monitoring and controlling the work .

Generally involves five steps:

1. Identify the deliverables and related work
2. Structure and organize the WBS
3. Decompose the upper WBS levels into lower
detailed components
4. Develop and assign identification codes to the
WBS components
5. Verify that the degree of decomposition of the
work is necessary and sufficient
 Project

Phase 1 Phase 2 Deliverable 3 Subproject4 Subproject 5

Deliverable 2.1 Deliverable 2.2 Deliverable 2.3 Deliverable 4.1 Deliverable 4.2

Deliverable 2.2.1 Deliverable 2.2.2 Deliverable 4.1.1 Deliverable 4.1.2 Deliverable 4.1.x

Work package Work package

Work package 2.2.2.1 Work package
2.2.1.1 3.1 4.1.2.1

Work package Work package

Work package Work package
2.2.2.2 3.2
2.2.1.2 4.1.2.2

Work package
Work package 3.3 Work package
2.2.1.3 Work package 4.1.2.3
2.2.2.2.1
Work package
3.4
Work package
2.2.2.2.2
Estimate Cost , Resource , Time

The heuristic (rule of thumb) used in project decomposition

is 80 hours (work packages).
 Sample of WBS in IT Projects
Tabular form

1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support
 IF A PROJECT TEAM IS SUBDIVIDING PROJECT
WORK PACKAGES INTO SMALLER, MORE
MANAGEABLE COMPONENTS, THEY ARE :

A ) Creating a WBS.

B ) Decomposing.

C ) Network diagramming.

D ) Activity sequencing.
 A WBS IS BEST DESCRIBED AS A TOOL FOR
TRACKING :

A ) The schedule.

B ) Resources.

C ) Cost.

D ) Scope.
 WHICH OF THE FOLLOWING IS DONE
DURING CREATE WBS ?

A ) Product analysis.

B ) Project selection.

C ) Decomposition.

D ) Alternatives analysis.
CREATE WBS (5.4)
Scope Baseline (Output)
The scope baseline is a component of the project
management plan. Components of the scope;
baseline include :
 Project scope statement. The project scope
statement includes the product scope description,
and the project deliverables, and defines the product
user acceptance criteria.
 WBS. The WBS defines each deliverable and the
decomposition of the deliverables into work
packages .
 WBS Dictionary. The WBS dictionary has a
detailed description of work and technical
documentation for each WBS element.
 THE SCOPE BASELINE CAN BEST BE SAID
TO INCLUDE THE ?

A ) WBS and Project Scope statement .

B ) Scope Management Plan & Project scope statement.

C ) Scope Management Plan & WBS .

D ) WBS & Project Charter .

 CREATE WBS (5.4)
Work Package (Output)
Is a deliverable or project work component at the lowest level
of each branch of the work breakdown structure .

•The work package includes the schedule

activities and schedule milestones required to
complete the work package deliverable or project
work component
•Level at which the cost and schedule for the work
can be reliably estimated, monitored, and controlled
( Significant point at the project )
•Deliverable at the lowest level of WBS. They are
control points in the work packages and are used for
task assignments, cost and schedule estimates, risk
identifications etc. They are further divided into
schedule activities.
CREATE WBS (5.4)

WBS Dictionary (Output)

For each WBS component, the WBS dictionary includes a:

• Code of account identifier

• Description of work
• Responsible organization
• List of schedule milestones

It may include:

• Contract information
• Quality requirements
• Technical references to facilitate performance of the work
• List of associated schedule activities
• Resources required
• Estimate of cost
CREATE WBS (5.4)

inputs
Project scope statement . 1
Requirements documentation . 2
Organizational process assets . 3

outputs
WBS . 1
WBS dictionary . 2
Tools & techniques Scope baseline . 3
decomposition . 1 Project document updates . 4
CREATE WBS (5.4)
VALIDATE SCOPE (5.5)
 The process of formalizing acceptance of the
completed project deliverables.

 Requires reviewing deliverables and results to

ensure that all were completed correctly and
satisfactorily

 Differs from quality control in that it is primarily

concerned with acceptance of the
deliverables while quality control is primarily
concerned with meeting the quality
requirements specified for the deliverables
Validate Scope (5.5)
Inspection (Tools & Techniques)
Technique for examining or measuring to verify whether an activity, component,
product, result or service conforms to specified requirements.

• Includes activities to determine whether results

conform to requirements.
• Are often called product reviews, audits, and
walkthroughs.
• Purpose is to specifically identify deficiencies,
gaps and errors against the project
documentation.
• The inspection activity should encompass the
accuracy, completeness and acceptability
of the object under review.
Validate Scope (5.5)
Is the project Ready to go
Every deliverables should be inspected including all project management documents .

If not Acceptable

Ship it & Approvals

Change Control Process

 Validate Scope (5.5) Outputs
1. Accepted Deliverables (Outputs)
• Deliverables that meet the acceptance criteria are formally signed
off and approved by the customer .

2. Change request (Outputs)

• Non-Accepted Deliverables can make a Change request for
defect repair .

3. Project Documents update (Outputs)

• Status Report Update
 WHICH OF THE FOLLOWING BEST
DESCRIBES SCOPE VERIFICATION ?

A ) It provides assurances that the deliverables meets the specifications, is an

input to the project management plan and output of perform quality control.

B ) It ensures that the deliverable is completed on time, ensure customer

acceptance, and shows that the deliverable meets specifications.

C ) It ensures customer acceptance, shows that the deliverable meets

specifications and provides a chance for differences of opinion to come to light.

D ) It is an output of perform quality control, occurs before define scope and

ensures customer acceptance.
 A PROJECT MANAGER IS IN THE PROCESS OF
VALIDATE SCOPE OF A DELIVERABLE WITH
THE CUSTOMER. WHAT IS THE MOST
IMPORTANT THING THE PROJECT MANAGER
SHOULD ENSURE?

A ) Accuracy.

B ) Timeliness.

C ) Acceptance.

D ) Completeness.
 A CUSTOMER WAS NOT HAPPY WITH A
PROJECT DELIVERABLES . WHAT IS THE BEST
COURSE OF ACTION ?

A ) Tell the customer the deliverable meets the scope of work

and get the customer’s agreement to proceed .

B )Determine why the customer is unhappy with the deliverable

C ) Meet with the team to determine the change needed .

D ) Meet with the customer and offer a substitute project

deliverable .
VALIDATE SCOPE (5.5)

inputs
Project Management Plan . 1
Requirements Documentation . 2
Requirements Traceability Matrix . 3
Verified Deliverables . 4

outputs
Accepted deliverables . 1
Change requests . 2
Project document . 3
updates

Tools & techniques

inspection . 1
VALIDATE SCOPE (5.5)
Control Scope (5.6)

Good Change :
A good change makes the product better with very little
downside .

Bad Change :
A bad change makes the product worst with very big
downside .

Gold Plating :
Gives Customers more than what was
required.
 Control Scope (5.6)

 The process of monitoring the status of the project and

product scope and managing changes to the scope
baseline.

• Assure that all requested changes and recommended

corrective actions are processed through the Integrated
Change Control process

• Manage the actual changes when and if they occur

• Integrated with other control processes

 Control Scope (5.6)
Variance Analysis (Tools & Techniques)
• Project performance measurements are
used to assess the magnitude of variation
from the original scope baseline.

• Important aspects of project scope control

include determining the cause and degree
of variance relative to the scope baseline
and deciding whether Corrective or
Preventive Action is required.

“ Every Scope change goes through the control scope process “

 Control Scope (5.6) Outputs
1. Work Performance Measurement (Outputs)
• Planned vs. Actual technical performance .
2. Organizational Process Assets Update (Outputs)
• Causes Of Variances
• Corrective Action Chosen
• Lessons learn from scope control
3. Change request (Outputs)
• Analysis can make a Change request to scope baseline &
Corrective action or preventive action or defect repair .
4. Project Management Plan update (Outputs)
• Scope Baseline OR Other baselines .
5. Project Documents update (Outputs)
• Requirement Documentation .
• Requirement Traceability Matrix
 A PROJECT MANAGER BELIEVES THAT
MODIFYING THE PROJECT SCOPE MAY PROVIDE
ADDED VALUE FOR THE CUSTOMER.
WHAT SHOULD THE PROJECT MANAGER DO ?

A ) Change the scope baseline.

B ) Contact the customer to determine if the change adds value.

C ) Call a meeting of the change control board.

D ) Change the project objectives.

 WHICH OF THE FOLLOWING BEST DESCRIBES
WHEN THE BASELINE CAN BE CHANGED?

A ) Only under emergency conditions.

B ) The original baseline is always maintained throughout the project.

C ) With any approved changes.

D ) When the project sponsor determines it is appropriate.

 THE CUSTOMER WANTS TO EXPAND THE PRODUCT
SCOPE AFTER THE PERFORMANCE MEASUREMENT
BASELINE HAS BEEN ESTABLISHED . WHICH
DOCUMENT MUST BE SUBMITTED ?

A ) A change Request .

B ) Project Scope Statement .

C ) Performance Measurement .

D ) Activity Attributes .
 Control Scope (5.6)

inputs outputs
Project management plan . 1 Work performance . 1
Work performance information . 2 measurements
Requirements documentation . 3 Organizational . 2
process assets
Requirement traceability matrix . 4
updates
Organizational process assets . 5
Change requests . 3
Project management . 4
plan updates
Project document . 5
updates
Tools & techniques
Variance analysis . 1
Control Scope (5.6)
 Work Performance Types
# WPI - Work Performance Information:
The work performance information is “the performance data collected from
various controlling processes, analyzed in context and integrated based on
relationships across areas; e.g. status of deliverables, and forecasted
estimates to complete, etc.”

# WPD - Work Performance Data:

The work performance data is “the raw observations and measurements
identified during activities performed to carry out the project work; e.g. actual
cost, actual duration, and percent of work physically completed.”

# WPM - Work Performance Measurements: Results from measurements

when comparing PLANNED Vs ACTUAL Technical Performance.

# Task: Work not necessarily listed in the WBS and is the lowest level of
effort on the project.
WHICH OF THESE PROCESSES IS NOT A
PART OF SCOPE MANAGEMENT:

A ) Scope Identification .

B ) Collect Requirement .

C ) Control Scope .

D ) Scope Verification .
THANK YOU