Chapter 5

Scope
Management
Exclusions
• This teaching notes does not contain the following elements
• Repeated tools that is already explained in the previous
chapters
• Lists that do not require further explanation or interpretation
such as list of
• Organization Process asset
• Enterprise Environmental factors
• Expert Judgement
• Details of calculations if any ( As the detailed lecture is sent
as videos)
What is Project Scope Management ?
• Scope
• Scope can be defined as the sum of products /
services / results to be provided in/as a project.
• All the work included and only the work included.
• So Project Scope Management ensures all the project
work and only the project work are completed
successfully
• PMI includes phrase “ only the project work” in the
definition to emphasis that the primary aim of scope
management
• To define the exact scope of work
• To prevent scope creep (additional requirements
added without any proper control) or
• To prevent gold-plating (added by the project team
with a view to impressing stakeholders).

Glossary Term : Scope creep is the uncontrolled

expansion to product or project scope without
adjustments to time, cost and resources.
Product Scope Vs Project Scope
Product Scope Vs Project Scope :

PRODUCT SCOPE PROJECT SCOPE

Features and functions that The work performed to
characterize a product, deliver a product, service or
service or result. result with the specified
features & functions.

Measured against product Measured against project

requirements management plan

Please note : Although we differentiate these two terms , the

term project scope in fact is inclusive of product scope.
Example :
A project manager is tasked with providing a new data
center for an organization.
• Product scope would include the tangible details of the
final deliverable:
• the computers & servers,
• office space,
• network connectivity and
• requisite software.
The overall product is the data center itself, and the
product scope consists of the component parts that
together make up the new data center.
• Project scope, however, would focus more on the process
of getting from empty space to a fully functioning data
center. It would include
• corresponding with contractors and designers,
• acquiring each of the physical parts mentioned above,
• providing project documents to managers and team
members
• and setting overall budgets
• timeframes for final delivery.
Scope Management in Adaptive Environment

• Very Less time is spent on defining or

Product
approving scope in the beginning as
Backlog requirements are uncertain.
• Detailed Scope defined at start of
every iteration.
Prototype • Deliverables are developed through
iterations.
• Product backlog is created and team
delivers deliverables as per priority
Customer
Engagement • Agile methods build prototypes and
release versions in order to refine the
requirements.
• Customer and Sponsors engaged
continuously throughout the project and
feedbacks received.

What is Product Backlog ?

• It is ordered list of everything that is known to be needed in
the product.
• The list may include list of the new features, changes to
existing features, bug fixes, infrastructure changes or other
activities that a team may deliver in order to achieve a
specific outcome.
• It is a single authoritative source of requirements for any
changes to be made to the product.
 Product Back Log - Mind Map & Example

ID As a .. I want to be So that . . . Priority Sprint Status

(User) able to . . . (Benefit)
(Requirement)
1 Admin Add new Security levels Must 1 Done
security are appropriate
groups
2 Member Update my Not bombarded Should 1 WIP
email with junk emails
preferences
3 Member Share content I can promote Could 2 WIP
to social what I find
networks interesting
4 Visitor Contact the Directly submit a Could 2 Yet to
administrators query Start
Scope Management – Predictive Vs Adaptive
Comparison
Predictive Life Cycle Adaptive Life Cycle
Project deliverables are The overall scope will be
defined at the beginning of decomposed into product
the project. backlogs.

Scope Baseline can be Product Backlogs are used

changed only through formal to reflect the current needs
change control procedures . of the stakeholders

Collect requirements, Define Collect requirements, Define

scope and Create WBS scope and Create WBS
processes- are performed in processes are repeated for
the beginning and updated each iteration.
using integrated change
control.

Validate scope occurs with Validate Scope – repeated

each deliverable or phase for each iteration.
review.

Control scope- ongoing Control scope repeated for

process each iteration.
Tailoring Considerations
• For any given project, the project manager, in collaboration
with the project team, is always responsible for determining
which processes are appropriate, and the appropriate degree
of rigor for each process.
• Project managers and their teams should carefully address
each process and its inputs and outputs.
• Following are tailoring considerations in Scope management
processes. Project Manager asks the following questions and
tailor the scope management processes accordingly.
• Product Development approach
• Does the organization use agile approaches ?
• Is it iterative / incremental?
• Is a predictive approach used?
• Will a hybrid approach be productive?
• Stability of requirements
• Are there areas of the project with unstable requirements?
• Do unstable requirements necessitate the
• Use of lean, agile, or other adaptive techniques until they are
stable and well defined?
• Knowledge and Requirements Management
• Does the org have formal/informal knowledge requirements
management systems?
• What guidelines should the PM establish for requirements to
be reused in future?
• Validation & Control
• Does the organization have existing formal / informal
validation policies, procedures, and guidelines ?
• Governance
• Does the organization have formal/informal audit &
governance policies, procedures, and guidelines.
• Knowledge and Change Management
• How knowledge be managed to foster collaborative
environment
• How change will be managed?
Trends and Emerging Practices
• Emerging Importance of Business Analysis Professionals
Research indicates that many of the inherent problems in
projects can be traced to requirements-related activities
• Once a decision has been made to proceed with a project
and resources have been committed, the project manager
must focus on delivering the expected scope, at the
expected cost, in the expected time.
• And, while the project manager is working with the project
team, vendors, resource managers, and functional groups
to get things done, there is the challenge of keeping a
sharp eye on the most important expectation of all:
achieving the expected benefit to the stakeholders.
• Using the combined skills, competencies, and knowledge of
the business analyst and project manager, stakeholder
requirements become more manageable and achievable
“so that the project will satisfy the needs for which it was
undertaken”
• Who is a Business Analyst ?
• “A business analyst works as a liaison among stakeholders
in order to elicit, analyze, communicate and validate
requirements “
• Those who perform business analysis are known by a
number of titles, including business analyst, systems analyst,
business systems analyst, functional analyst, and even
project manager himself may do this role.
• The title is not important, but the function is. Each of these
individuals is conducting business analysis when analyzing
the business needs of the stakeholders in order to help
identify business problems and propose solutions.
Business Analyst’s role

Elicit and document

stakeholder Recommend Solution to
requirements meet the business need

Business Need Facilitate successful

Identification implementation of
product / service

• Note : The relationship b/w Project Manager and Business

Analyst should be a collaborative partnership .
• Project Manager is the ultimate responsibility that BA’s work
is accounted in PM plan and performed on time/budget/deliver
value
 Overview of Integration Management processes
Processes Process Description Major output
Group
Plan Scope Planning Provides guidance and direction on • Scope Management
Management how scope will managed throughout Plan
the project. • Requirements
Management Plan
Collect Planning Determining, documenting and • Requirements
Requirements managing stakeholder needs and Documentation
requirements. • Requirements
traceability Matrix
Define Scope Planning Developing detailed description of • Project Scope
project and product scope Statement
Create WBS Planning Subdividing project deliverables into • Scope Baseline
more manageable components. (Approved Scope
Statement, WBS,WBS
Dictionary )

Validate Scope Monitoring Formalizing acceptance of • Accepted

and completed deliverables. Deliverables
controlling • Work performance
Information
• Change requests,
• PM plan updates,
Project document
updates
Control Scope Monitoring Monitoring the status of scope and • Work Performance
and managing changes to scope. Information
controlling • Change Request,
• PM plan updates,
Project document
updates

Another important point to note is that Integration Management occurs in all the process
groups i.e. Initiating, Planning, Executing, Monitoring and Controlling and Closing.
1. Plan Scope Management
• This process provides guidance and direction on how scope will
managed throughout the project.
• This process produces Scope Management Plan and Requirements
Management Plan that are subsidiary plans of Project Management
Plan.
• Scope Management Plan
• Defines how the scope will be defined, validated and
controlled
• i.e., it includes how to prevent scope creep, how to handle
change requests, escalation path for disagreement on
scope elements between stakeholders, processes for
creating scope statement, WBS,, how the deliverables will
be accepted
• Requirements Management Plan:
• Defines how the requirements will be managed, documented
and analyzed
• i.e., it includes how to process requirements, address missed
requirements, configuration, prioritize requirements, metrics
(and rationale) for defining the product, define the
traceability structure (in RTM), authorization level for
approving new requirements

Glossary : Plan Scope Management is the process of creating

a scope management plan that documents how the project
and product scope will be defined, validated, and
controlled .”
Scope Creep
This process is necessary to avoid scope creep.
• What is Scope Creep ?
• “Adding features and functionality (project scope) without
addressing the effects on time, costs, and resources, or
without customer approval”
• Change on projects is inevitable, so the possibility for scope
creep is also inevitable. Perhaps this is the reason why
taming scope creep is so challenging.
• It does not imply that additional functionality or work is not
desirable on projects. It does not mean that scope creep
occurs just because requirements change. The key part is
whether changes are authorized or not. If an expansion of
scope is approved, then it is not scope creep.
Glossary : Scope Creep is defined as The uncontrolled
expansion to product or project scope without adjustments to
time, cost and resources.

Some Reasons cited for scope creep

• Lack of leadership team commitment
• Lack of clarity and depth to the original specification
document.
• Allowing direct [unmanaged] contact between client and team
participants.
• Customers trying to get extra work “on the cheap.”
• Beginning design and development of something before a
thorough requirements analysis and cost-benefit analysis has
been done.
• Scope creep “where you do it to yourself” because of lack of
foresight and planning.
• Poorly defined initial requirements.
ITTOs ( Inputs, Tools & Techniques, Outputs )

Inputs are explained in the respective knowledge area

Tools and Techniques :
• Data Analysis : Alternative Analysis
• Alternative analysis is grouped under data analysis
category. (To know the tools and techniques group please refer to
page no 686 in PMBOK guide)
• Alternative analysis is to evaluate identified options in order
to select the options or approaches to use to execute and
perform the work of the project.
• Decision has to be taken on considering and picking various
ways of
• collecting requirements,
• elaborating the project and product scope,
• creating the product,
• validating and controlling the scope.
• Meetings
• Meetings involving project team and sponsor to develop the
scope management plan
Outputs
Scope Management Plan and Requirements Management Plan are
the outputs , that guides the rest of the processes of this knowledge
area.
These documents can be formal or informal; detail or broad
1. Scope Management Plan
1. It guides the rest of the processes except collect requirements
as there is a separate requirements management plan to
guide that process.
2. Scope Management Plan explains how scope statement, WBS
has to be created
3. It explains the way scope to be validated and controlled.
• Requirements Management Plan
• Also called as Business Analysis Plan
• Establish how requirements will be collected, documented and
managed.
• Components of Requirement Management Plan includes
• Requirements Management Approach
• methodology the project team will use to identify, analyze,
document, and manage the project’s requirements.
• This may include what technique to be used, how to analyze
requirements, Document template, accountable personnel,
approval procedures etc.,
• Requirements Configuration Management :
• Establish process to review and approve any proposed
changes, version control and to implement and communicate
these changes to the stakeholders
• Requirements Prioritization Process
• Methods by which priorities of requirements are determined.
• Product Metrics
• How quantitative characteristics are established to measure
against in order to gauge the progress and success of the
project.
• Requirements Traceability Matrix
• Establishing Req. Traceability Matrix
• The requirements traceability matrix is a tool to ensure that
deliverables meet the requirements of the project
2. Collect Requirements
Activities of this process include
• Project and Product requirements are defined
• Determining expectations of the stakeholder – customer,
sponsor and other necessary stakeholders
• Documenting, quantifying and analyzing and prioritizing such
requirements
Glossary : Collect Requirements is the process of determining,
documenting and managing stakeholders needs and requirements to
meet objectives.

Definition of Requirement :
Requirements include conditions or capabilities that are required
to be present in a product, service, or result to satisfy an
agreement or other formally imposed specication.
Importance of this process :
Requirements are the basis for
• Scope Planning particularly WBS creation
• Planning Cost
• Scheduling
• Quality Planning
• Procurement Planning
ITTO

Inputs
• The inputs listed are explained or will be explained in their
respective knowledge areas where they appear as outputs.
Tools & Techniques
1. Data Gathering Techniques
• Brainstorming - explained
• Interviews - explained
• Focus groups - explained
• Questionnaire & Survey
• Benchmarking
Tools & Techniques
• Questionnaire and Survey
• Q&S are used when you want to gather requirements from
a mass of people – i.e., huge number of respondents
• For example An organization in an attempt to develop a
new automobile conducts a survey that studies the consumer
behavior , tastes and preferences of the target segment.
• So here the potential market is huge and the sample size
will also be huge
• Hence Q&S are used quickly collect information from the
huge respondents.
• Data collected via Q&S undergoes statistical analysis to
derive inferences.
• Benchmarking
• Comparing product, services, processes to other
organizations to identify best practices and opportunities
for improvement that can be accommodated in the
requirements.
Tools and techniques

2. Data Analysis Techniques

• Document Analysis
• Analyze existing documents from where more requirements can
be elicited or traced back.
• Documents that can be analyzed includes
• Agreements
• Business plans
• Marketing Literature
• Process flows
• Policies and procedures
• Issue logs
• Regulatory documentation
• RFPs ( Request for Proposal)
• Use case (a use case is a list of actions or event steps
typically defining the interactions between a role and a
system to achieve a goal.)
Tools and techniques
3. Data Representation Techniques
The below techniques shows graphic/visual representation of
requirements .
• Affinity diagram – also called KJ ( Kawakita Jiro) Method
• Sorting and grouping technique
• Ideas sorted under homogenous group for easy visualization
and analysis

• Mind Mapping
• A mind map can at once give you an overview of a large subject
while also holding large amounts of information.
• Mind Maps mimic the way our brains think—bouncing ideas off
of each other, rather than thinking linearly.
• It consolidates idea into a single map, that are collected through
brainstorming sessions
Tools & Techniques
• An example Mind mapping to conduct an event.
Tools and Techniques
5.Decision Making Techniques- used to prioritize product
requirements.
• Voting
• Autocratic Decision Making
• MCDA
Voting : Under voting decisions can be made by
• Unanimity : Every one agrees
• Majority: More than 50 % agrees
• Plurality: Largest percentage (not majority) agrees
• Autocratic Decision Making
• One individual takes responsibility for making the decision
for the group.
• MCDA
• Decision matrix to provide a systematic analytical approach
for establishing criteria, such as risk levels, uncertainty, and
valuation, to evaluate and rank many ideas.

Criteria Style Reliability Fuel efficiency Weighted

score
• Wt :0.3 Wt:0.4 Wt :0.3 Tot wt : 1
Civic 8.4 (7*0.3 +
7 9 9
9*0.4+9*0.3)
Saturn
8 7 8 7.6

Ford
9 6 8 7.5

Mazda
6 7 8 7.0
Tools & Techniques
6. Interpersonal & Team Skills
• Nominal Group technique
• Observation / Conversation
• Facilitation ( Facilitated workshops)
Nominal Group technique
• Enhanced brainstorming with a voting process used to rank the
most useful ideas for further brainstorming or for prioritization.
NGT steps
1. Idea Generation
• A question or problem is posed. Each person silently generates and writes down
their ideas.
2. Recording
• The moderator writes down the ideas on a flip chart until all ideas are recorded.
3. Discussion
• Each recorded idea is discussed until all group members have a clear
understanding.
4. Voting
• Voting may take place in many rounds to reduce. After each round, the votes are
tallied and the highest scoring ideas are selected.
Tools & Techniques
• Observation / Conversation
• Viewing individuals in their environment
and how they perform their jobs or
tasks and carry out processes to
uncover hidden requirements
• Facilitation ( Facilitated workshops)
• Bring key stakeholders together to define product
requirements.
• This work shops are composed of healthy mix of users,
business experts and product development people (cross
functional team)
• Ideal for cross functional requirements.
• Help to reconcile stakeholder differences and increase
stakeholder consensus . JAD, QFD and user story workshops
are examples.

Joint Application Development –JAD-

used in software development industry

Quality Functional Deployment- QFD

used in Manufacturing Industry- Collects
Voice of Customer- VOC

User Stories- short textual description of

required functionality.
Tools & Techniques
• User Story
Describe the
• who benefits from the feature (role),
• what the stakeholder needs to accomplish (goal),
• and the benefit to the stakeholder (motivation).

Voice Of
Customer
Tools & Techniques
• QFD Workshops uses the following template to gather information
from cross functional teams. The matrix is ony for your reference.
Remembering the contents of the matrix is not required for the
exam

Voice Of
Customer

7. Prototypes
• *A method of obtaining early feedback on requirements by
providing a working model of the expected product before
actually building it.
• E.g., 2D & 3D models, simulations, Storyboard etc.,
• Story Boarding is a prototyping technique showing sequence
or navigation through a series of images or illustrations.
• Applications
• Films
• Software development
• Advertising
• Instructional design
Story Boarding examples

8. Context Diagram:
*A visual depiction of the product scope showing a business
system (i.e., process, equipment, computer system, etc.) and
how people ( actors ) and other systems interact with it.
The rigor, the number of applied techniques and the sequence in which these
techniques are applied depend on the project's complexity, the audience and
the available time for gathering & prioritizing requirements.

Outputs
1. Requirements Documentation
• *Describes how individual requirements meet the business
need for the project.
• Can be simple or elaborate
• Includes Requirement constraints, assumptions & dependencies.
Following are the categories of requirements
• Business requirements
• Business objectives, issues, opportunities
• Reason for undertaking the project
• Stakeholder requirements
• Needs of stakeholders
• Transition requirements
• Temporary capabilities needed to move from current state to
future state
• e.g., Data Conversion, training requirements
• Project requirements
• Actions, processes and other conditions to be met
• e.g., milestone dates, constraints, contractual obligations
• Solution requirements (features, functions and characteristics of
the product). This is classified into
• Functional requirements (product behavior)
• Non functional requirements (reliability, security, performance
level of service and supportability etc.,)
• Quality requirements
• condition or criteria needed to validate the successful
completion of a project deliverable
• e.g., tests, certifications, validations, etc.
 Outputs
2. Requirements Traceability Matrix
• It identifies
• Source of the requirement
• Responsibility for managing
• Work status
• Completion status
• For a software project requirement traceability matrix
• Traces each user requirement is traced with work packages
or activities needed to fulfill those requirement.
• Used for creating test plans
• The components of Requirements traceability Matrix may be
include the following

Project
I Requirement Business Product Product Test
WBS
D Description Needs Design Development Cases
Objectives

ID Category Requirement Priority Source Business Deliverables Verification Validation

Objective
001 Mandatory Ability for High CTO Increase self Knowledge Achievement Unit Test and
customers to service base module of business UAT
search the resolution rate Analytics objective
knowledge by 13 % module within 1yr
base for from go
solutions to
broadband
problems
002 Optional Customers can Low Service Increase CSAT My Account Uptick of Unit Test and
see recently Desk by 3% by 2nd module CSAT UAT
viewed half FY
knowledge
articles in a my
account area
 3.Define Scope
• This process involves product/service/result boundaries and
acceptance criteria in greater detail.
• It describes PROJECT INCLUSIONS AND EXCLUSIONS.
• Risks, constraints and assumptions are added and updated .
Glossary : Define Scope is the Not all requirements
process of developing a detailed enters the project, this
description of the project and process also involves
product.” selecting final project
requirements

Inputs
• The inputs listed are explained or will be explained in their
respective knowledge areas where they appear as outputs.
Tools & Techniques
Decision Making , Facilitation are discussed
Tools & Techniques
1. Data Analysis
• Alternative Analysis
• To evaluate ways to meet the requirements and the
objectives
2. Product Analysis
• Analyze the objective and description of the product stated
by the customer/sponsor and turn them into tangible
deliverables.
• Product analysis is other wise called as
•Value analysis
•Value engineering
•System engineering
•Product breakdown
•Requirement analysis
•Objectives of Product Analysis
ü Technical performance: can we make this product with
the material and can we make it well?
ü Economics: if we can make it, can we make it cheaply
enough?
Product Analysis / Value Analysis
• Hence Product Analysis or Value Analysis is improving
value either by enhancing function or reducing cost or a
bit of both actions.
Outputs
Project Scope Statement :
• * The description of the project scope, major deliverables,
assumptions, and constraints.
• Documents the entire scope, including project and product scope
• May contain explicit scope exclusion.

Note the difference

between Project Scope
Statement and
Statement Of Work

Project Scope Statement Vs Project Statement of Work

• Statement of Work (SOW) contains at least the following
three elements:
• Organization strategic plan
• Business needs
• High level product scope

• These are meant to provide an overarching direction for

the project only, NOT the full implementation details. The
statement of work is present in agreements or RFPs.

• The high level product scope contained in the statement

of work must be further developed in order for all
stakeholders and project team members to really
understand what are expected from the project. This is
where the Project Scope Statement comes into play.
Project Scope Statement
• Components of Project Scope Statement
• Product scope description
• Acceptance criteria
• Deliverable
• Project exclusions
• Assumptions & Constraints

• Product Scope:
• Product is an output of the project and features, specifications,
details about the product are described in the product scope.
• And therefore, since the product is a project deliverable,
product scope will be included in the Project Scope Statement
as well.
• Deliverables:
• Project will produce deliverables throughout the project until all
project scope is completed.
• Let’s consider that you are working in an e-commerce shopping
website project. The interim deliverables such as login screen,
category page, member profile screen etc. And these interim
deliverables can be tested by the customer before waiting for
the final product delivery.
• Since deliverables are smaller parts of the overall project
scope, these are listed in the scope statement.
• Product Acceptance Criteria:
• Product acceptance criteria shows in what conditions customer
will accept the project.
• This is actually a handshake between the project team and
customer that in what circumstances the customer will accept the
final project and give acceptance. These criteria generally
generated through requirements.
• For instance, if it is agreed with the customer in the beginning
that the member login will be accomplished in less than 2
seconds, this is written in product acceptance criteria and when
the e-commerce shopping website is ready for customer tests, if
member logins are processed successfully in less than 2 seconds,
customer must accept.
Project Scope Statement
• Exclusions:
• It must be written in project scope statement as well.
Because in some cases, some project stakeholders might think
some out of scope items in the project scope. Therefore, it is
better to clearly outline critical points which are not in the
scope of the project.
• Let’s consider that you are working on the installation of a
new database project in an IT company and the scope is
only installation and configuration. It is better to mention
that migration of data from old database in out of scope.
• Because some stakeholders might consider that new
database installation will cover also migration of data as
well.
• Additional risks, constraints, and assumptions:
• Risks that might affect the project must be included in the
scope statement as well as Constraints and assumptions.
• Project constraints limit the dimensions of the project and
planning is done based on these constraints and
assumptions.
• If constraints or assumptions of a project do not go as
planned, these will affect the project scope and other
aspects respectively. Therefore, these must be written down
in the project scope statement.
Project Charter Vs Project Scope Statement

• Project Charter • Project Scope Statement

• Project purpose • Project Scope
• Measurable Project Description
Objectives • Project deliverables
• High level requirement
• Project exclusions
• Assumptions and constraints
• Acceptance criteria
• High Level Project description
and boundaries
• Overall project risks
• Summary milestone schedule
• Preapproved financial
resources
• Key Stakeholder list
• Project approval
requirements and exit
criteria
• Project Manager's
responsibility and authority
level
• Name and authority of
project Sponsor

• Although Project Charter and Project Scope Statement look to

have some similar elements , the level of detail in the Scope
statement is elaborate.
4.Create WBS
• This process is of subdividing project deliverables and project
work into smaller, more manageable components.”
All about Work Breakdown Structure
• Deliverable oriented hierarchical decomposition of the work
to be executed by the project team.
• Work here refers to work products or deliverables that are
the result of activity and not to the activity itself.
• Helps to estimate the cost, time and risk

Project

Phase Phase Phase

Deliverables Deliverables

Sub
Sub Deliverables
Deliverables

Work Work
The Least component Package Package
of WBS called work
package which is
nothing but lowest
level of deliverable.

• Work Package is also a deliverable.

WBS
• Why create WBS ?
• Provides framework of what has to be delivered.
• Helps in assigning responsibilities and resource allocation
• Verify that no deliverables are missing or not overlapping

• *Work package :
• The work defined at the lowest level of the work breakdown
structure for which cost and duration can be estimated and
managed.
• *Code of account :
• Any numbering system that uniquely identifies each
component in the WBS.
WBS

• *Planning package :
• A work breakdown structure component below the control
account and above the work package with known work
content but without detailed schedule activities.
• When there is sufficient information to estimate cost and
duration of the work with reasonable accuracy, WBS is
decomposed till the lowest level (Work Package
level). When there is insufficient information to estimate
cost and duration of the work with reasonable accuracy,
decomposition is stopped there. Decomposition is only
resumed when the information is available to the extent to
produce a verifiable sub-component of the product or
service or result.
• At one stage, we know the details of the work to be done,
but the details of the schedule are still not clear. This level
of decomposition is known as Planning Package.
• At a later point of time, when the details about the schedule
becomes clear, Planning Package can be decomposed to
form Work Package(s).
WBS
Work Package • Planning Package
• Lowest Level of WBS. • These are decomposed into
work package or they get
• Duration, and cost of the converted into work
work can be estimated. package when we get more
visibility of the work them.
• Further decomposition of
Work package not possible. • We can say it is a stage
between control account and
• Work packages are Work Package.
planned by way of
identifying activities under • Schedule details are unclear,
them, they are the primary so estimation cannot be
input to identify activities made with reasonable
process accuracy.

• When details are available,

Planning package can be
decomposed into work
package(s)
• *Control account:
• control account as a management control point
• where scope, cost and schedule are integrated compared to
earned value performance measurement.
• A control account has two or more work packages, though
each work package is associated with a single control
account
WBS rules

1. Noun not verbs

• Include deliverables, not activities
2. 100 % rule
• The total of the work at the lowest levels should roll up to the
higher levels so that nothing is left out and no extra work is
performed.
• Include project management work too.
3. Mutually Exclusive
• There must be no overlap in either in the deliverables or their
work.
4. Rolling Wave Planning
• Decompose for the deliverable which is agreed on and do not
rush to far future ones
5. Stop, when its enough
• Excessive decomposition can lead to nonproductive
management effort, inefficient use of resources, decreased
efficiency in performing the work, and difficulty aggregating
data.
ITTO

Tools & Techniques

Decomposition
• Dividing and subdividing the project scope and project
deliverables into smaller, more manageable parts
• The lowest level – work package – at which duration and
cost is estimated and managed

Identify Deliverables

Structure and organize WBS

Decompose upper WBS level into lower

level components

Assign identification codes to them.

Verify that the degree of decomposition is

appropriate
Tools & Techniques
• Top-down
• Start with the largest items of the project and break them
down.
• Bottom-up
• Start with subcomponents (work package) and roll them up.
• Different form of WBS
• Phases as the second level of decomposition
• Major deliverable as the second level instead of phases

1.Phases as the second level of decomposition

Please note if the some work is contracted out then, only

subcomponents are included in the project work and
detailed WBS of the contracted work will be created by
the seller.
Tools & Techniques

2. Major deliverables as the second level of decomposition.

Outputs
1. Scope baseline : It is approved version of following
• Project scope statement
• WBS
• WBS dictionary
• Planning package
• Work package
2. Project Document updates
• Assumptions log
• Requirements documentation
Outputs
• WBS dictionary :
• WBS dictionary is a document that provide details about
each component of WBS.
• Code of account identifier
• Description of work
• Assumptions and constraints
• Responsible organization
• Schedule milestones
• Cost estimates
• Quality requirements
• Acceptance criteria
• Technical references
• Agreement information
5.Validate Scope
• *Validate Scope is the process of formalizing acceptance of the
completed project deliverables.”
• Increases the probability of final product, service, or result
acceptance by validating each deliverable

• It can occur not only at the end of the project , but also at the
end of every milestone or phase.
• Constant verification of deliverables allow the project
manager and the project team to make incremental correction
as the project progresses to ensure successful delivery.
Flow Chart to recall
• 1. Deliverable Flow
Tools & Techniques
• Inspection
• To validate whether deliverables meet requirements and
product acceptance criteria
• Also called reviews, product reviews, audits and
walkthroughs.
• Decision making techniques
• Voting is used to reach a conclusion when the validation is
performed by the project team and other stakeholders.

Outputs
• Accepted deliverables
• Formally signed off and approved by the customer/sponsor.
• Forwarded to close project/phase.
• Change requests ( defect repair)
• Unaccepted deliverables requires a change request to
defect repair
• Work performance information
• Progress information of deliverables such as which
deliverables are completed and accepted.
• Project documents updates
• All those documents which defines the product and report
status on deliverable completion.
• Lessons learned register, Requirements documentation,
Requirements traceability matrix
6. Control Scope
• *Control Scope is the process of monitoring the status of the
project and product scope and managing changes to the scope
baseline.”
• Prevention of scope creep and gold plating is an important
objective here
• Any scope change must be handled in a structured, linear, and
controlled manner.
• This process interacts with Perform Integrated Change Control in
order to take the scope change requests through a formal
process
How scope changes to be handled?
1. All requested scope change must be documented.
2. Perform an impact assessment to all requested scope
changes.
3. Must be reviewed by the CCB .
4. Status of the change request ( Acceptance/ Rejection)
should be updated and implemented.
Tools & Techniques
• Data Analysis

Variance Analysis Trend Analysis

• Compare the baseline • Examines project
to the actual results performance over time
• Determine if the • Determines if
variance is within the performance is
threshold amount improving or
• If corrective or deteriorating.
preventive action is •x
appropriate.

Outputs
1.Work performance information
• Information on scope variances and their impact on schedule
and cost, forecasts on scope performance etc.,
2.Change requests
• Corrective/ Preventive / defect repair or change requests
to scope baseline.
3.Project management plan updates
• Upon approval scope, schedule and cost baseline,
performance measurement baseline, scope management
plan can be updated.
4.Project documents updates
• Lessons learned register, Requirements documentation,
Requirements traceability matrix.