Part 5:

Project Scope
Management
Knowledge Areas
A Knowledge Area represents a complete set of concepts, terms and activities that
make up a professional field, a project management field, or an area of specialization.
Ten Knowledge Areas are used on most project most of the time:
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Process Human Resources Management
Project Communication Management
Project Risk Management
Project Procurement Management
Project Stakeholders Management
Index: Six process groups

Plan Scope Management

Collect Requirements
Define Scope
Create WBS: Work Breakdown Structure
Validate Scope
Control Scope
Mapping of Project Management Processes
Each Project Management Process belongs to
One of the Five Project Management Process Groups
One of the Ten Knowledge Areas
Example
Project Management Process Groups
Initation Planning Execution Monitoring and Closing
Control
…
K A
n r
o e
w a
Project Scope • Plan Scope • Validate
l
Management Management scope
e • Collect Requirements • Control
d • Define Scope scope
g • Create WBS
e …
The Project Management Triangle

3 constraints faced in every project: Scope, Time, and Cost.

The Project Management Triangle

Time.
The most obvious one. Everything takes time.
Project schedule are set during initiation and planning phases and rarely change
midway.
Cost
Project budgets are typically set prior to projects and rarely change midway.

Scope is about the project itself.

What you add to your project can help make it the best thing out there, but it can
also add time and cost to the project by broadening the scope.
 What is scope creep?
Scope creep refers to how a project’s requirements trend to
increase in an uncontrolled way over a project life cycle.

Why Scope Creep Happens? How to Avoid Scope Creep?

Complex requirements from the Put in place a proper change
Client/User are misunderstood management process
Customer gives a vague idea of his Estimates changes in terms of
requirement costs, resources, budget, planning
Needs from customer change Communicate changes in schedule
during project execution and budget
Poor Change Control in place Update plans after change request
is approved
Gold Plating: A stakeholder wants
to give addional value to the Avoid Gold Plating: Learn how to
product refuse to give additional feature
Scope creep – Few causes
A team member may add extra functions to prove his abilities to the
project manager.

Project manager may add extra functions to earn credit from the client or
the top management.

Direct communication bewteen Customer/User and development team

Sometimes it is performed to divert the attention of the client from the

defects in the product.
Project Scope Management
Project scope management includes the processes
required to ensure that the project includes all the work
required and only the job required to complete the
project successfully.

Managing the project scope is primarily concerned with

defining and controlling what is and what is not included
in the project

The scope baseline for the project is the approved

version of the project scope statement, work breakdown
structure (WBS)
What is project baseline?
The project’s baseline is used to measure how performance deviates from the
plan.
A project’s baseline is defined as the original scope, cost and schedule.
The project’s baseline must be completely defined and documented before the
project execution and control activities can begin.
Once the project starts execution, the project’s baseline is put under change
control to help you evaluate any further change and its impact on the project.
No meaningful measurements can be made if the scope, cost and schedule are
not under strict change control disciplines.
If any change is approved then the new baseline is redefined as the original
plan plus the approved change.
Frequent requests for changes to the project requirements may indicate that
there was an incomplete initial requirements analysis or the lack of meaningful
communication with users and customers early in the project.
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

5.1 Plan Scope Management

Inputs Tools & Techniques Outputs

1. Project Charter 1. Expert judjement 1. Scope management
2. Project Management 2. Meetings plan
Plan 2. Requirements
3. Enterprise management plan
Environmental
factors
4. Organizational
Process Assets
5.1 Plan Scope Management: Inputs

Project Charter
Used to provide the project context needed to plan the
scope management processes. It provides the high-level
project description and product characteristics from
the project statement of work.

Project Management Plan

Used to create the scope management plan and
influence the approach taken for planning scope and
managing project scope.
5.1 Plan Scope Management: Inputs
5.1 Plan Scope Management: Inputs

The enterprise environmental factors that can influence the

Plan Scope Management process include, but are not limited to:
Organization’s culture
Infrastructure
Personnel administration

The organizational process assets that can influence the Plan

Scope Management process include, but are not limited to:
Policies and procedures,
Historical information and lessons learned knowledge base.
5.1 Plan Scope Management

Inputs Tools & Techniques Outputs

1. Project Management 1. Expert judjement 1. Scope management
Plan 2. Meetings plan
2. Project Charter 2. Requirements
3. Enterprise management plan
Environmental
factors
4. Organizational
Process Assets
5.1 Plan Scope Management: Tools and Techniques

Expert Judgment
Expert judgment 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
Project teams may attend project meetings to develop the scope
management plan.
Attendees at these meetings may include the project manager, the
project sponsor, selected project team members, selected
stakeholders.
5.1 Plan Scope Management

Inputs Tools & Techniques Outputs

1. Project Management 1. Expert judjement 1. Scope management
Plan 2. Meetings plan
2. Project Charter 2. Requirements
3. Enterprise management plan
Environmental
factors
4. Organizational
Process Assets
5.1 Plan Scope Management: Outputs
The scope management plan is a component of the project management plan
that describes how the scope will be defined, monitored, controlled, and verified.

The components of a scope management plan include:

Process for preparing a detailed project scope statement (Define scope)
Process that enables the creation of the WBS (Work Breakdown Structure)
Process that establishes how the WBS will be maintained and approved
Process that specifies how formal acceptance of the completed project
deliverables will be obtained ( Customer or User Acceptance)
Process to control how requests for changes to the detailed project scope
statement will be processed.
5.1 Plan Scope Management: Outputs

The requirements management plan is a component of the

project management plan that describes how requirements
will be analyzed, documented, and managed

Components of the Requirement Management Plan include

How requirement activities will be planned, managed and reported
Requirement priortization process
Traceability structure to check if the current project requirements are
being met (Traceability Matrix)
Scope vs Requirements

Scope of work
This is the box inside which all requirements must fit.
It is owned by the project sponsor and project management team
Scope change should be avoided.

Requirements
Requirements are generally outlined during project initiation and refined during project
planning and design.
Requirements are generally more granular than scope.
Requirements should be owned and maintained by the project.
It is normal for requirements to change (although the change must be strongly
controlled & approved by appropriate stakeholders).
Scope vs Requirements : Example

Scope of work
Maintain museum artifacts

Requirements
1. All artifacts will be cleaned monthly using professional standards
2. Environmentally sensitive artifacts will be stored in a safe environment
3. Any artifact removed from display will be tracked in asset management in accordance
with procedure X.
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

5.2 Collect Requirements

Collect Requirements is the process of determining,

documenting, and managing stakeholder needs and
requirements to meet project objectives.

This process provides the basis for defining and managing the
project scope

Needs + Requirements # Project scope

5.2 Collect Requirements

Inputs Tools & Techniques Outputs

1. Scope management 1. Interviews 1. Requirement
plan 2. Focus groups documentation
2. Requirements 3. Facilitated 2. Requirement
management plan workshops traceability matrix
3. Stakeholder 4. Group creativty
management plan techniques
4. Project Charter 5. Group decision-
5. Stakeholder register making techniques
6. Questionnaires and
surveys
7. Observations
8. Prototypes
9. Benchmarking
10. Context diagrams
11. Document analysis
5.2 Collect Requirements

Inputs Tools & Techniques Outputs

1. Scope management 1. Interviews 1. Requirement
plan 2. Focus groups documentation
2. Requirements 3. Facilitated 2. Requirement
management plan workshops traceability matrix
3. Stakeholder 4. Group creativty
management plan techniques
4. Project Charter 5. Group decision-
5. Stakeholder register making techniques
6. Questionnaires and
surveys
7. Observations
8. Prototypes
9. Benchmarking
10. Context diagrams
11. Document analysis
5.2 Collect Requirements: Tools and Techniques
Interviews
Formal or informal approach to obtain information from stakeholders by talking to
them directly

Focus group
Bring together prequalified stakeholders and SMEs (Subject Matter Experts)

Facilitated workshops
Focused sessions that bring key stakeholders together to define product
requirements

Group creativity techniques

Brainstorming: generate and collect multiple ideas related to requirements
Nominal group techniques: Brainstorming with selection and voting process
Idea/Mind mapping: Consolidate ideas from brainstorming into a single map
5.2 Collect Requirements: Tools and Techniques

Group Decision-Making Techniques – Used to generate, classify and prioritize

requirements.
Unanimity: Everypone agrees on a counrse of action
Majority: Support is obtained from more than 50% of the members of the group
Plurality: Decided by the larger block of the group. When more than two options.
Dictatorship: One individual makes the decision for the group
Questionnaires and surveys
Written sets of questions designed to quickly accumulate information from a large
audience
Observations
Direct ways of viewing individuals in their environment and how thy perform their job
Prototype
Provide a working model of the expected product before building it
5.2 Collect Requirements: Tools and Techniques

Benchmarking
Compare actual or planned practices –processes and operations- to those of
comparable organizations to identify best practices

Document analysis
Define requirement by analysing existing documentation and identify information
relevant to the requirements
Marketing litterature, Request for proposal, Technical Documentation, users guide,
use cases, ..
5.2 Collect Requirements

Inputs Tools & Techniques Outputs

1. Scope management 1. Interviews 1. Requirement
plan 2. Focus groups documentation
2. Requirements 3. Facilitated 2. Requirement
management plan workshops traceability matrix
3. Stakeholder 4. Group creativty
management plan techniques
4. Project Charter 5. Group decision-
5. Stakeholder register making techniques
6. Questionnaires and
surveys
7. Observations
8. Prototypes
9. Benchmarking
10. Context diagrams
11. Document analysis
Requirements Documentation

Requirements documentation describes how individual requirements

meet the business need for the project.

Requirements may start out at a high level and become progressively

more detailed as more about the requirements is known.

Requirements need to be unambiguous (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 an executive summary,
detailed descriptions, and attachments.
Requirements Documentation: Content
Business Requirements: High level statements as to what the Customer or User wants
to achieve
Stakeholder requirements: Requirements that are collected from stakeholders such as
business units, operations teams, customers, users, communities and subject matter
experts.
Solution Requirements: describe features, functions, and characteristics of the
product, service, or result that will meet the business and stakeholder requirements
Functional requirements: Requirement which specifies what the solution should do.
Example (Cup): ability to contain tea or coffee without leaking

Non functional requirements: Any requirement which specifies how the solution
performs a certain function.
Example (Cup): must contain hot liquid without heating up to more than 45 °C.

Transition requirements: These requirements are about implementation and change.

They are the requirements needed in order to efficiently and effectively transition a
solution that meets the business and stakeholder needs into the environment.
They need to be well though out and require a plan of action that creates business success.
Quality requirements

Quality requirements are specifications of the quality of

products, services, processes or environments.

Quality is any element, tangible or intangible, that gives

things value beyond their functionality and features.

The following are illustrative examples of quality

requirements.
Quality requirements: examples
Reliability
Enduring and consistent performance in real world conditions.
Example: A cell phone to make and receive voice call in a personal portable environment
with 99% reliability over 1 month, 95% reliability over the 1 year warranty period, and with
reliability of 90% over 5 years.

Availability
The availability of a service.
Example, a requirement for a software service to be up 99.99% of the time.

Usability
Requirements related to ease of use of a product
Example: Candidates will successfully register in the web site in lass then 5mn
Quality requirements: examples
Maintainability
Requirements that things be easy to maintain and fix.
Example: a mobile device with elements that can be swapped in and out by users to
upgrade or replace things.

Robustness
Requirements that a product handles abnormal and erroneous operational
conditions.
Example: Waterproofness of a mobile phone:
1 – Dripping water shall have no harmful effect.
………….
7 – Immersion, up to 1m depth for up to 30 minutes.
Requirement traceability matrix

The requirements traceability matrix is a grid that links

product requirements from their origin to the deliverables
that satisfy them.

It provides a means to track requirements throughout the

project life cycle, helping to ensure that requirements
approved in the requirements documentation are
delivered at the end of the project.

Finally, it provides a structure for managing changes to

the product scope.
Traceability Matrix -Example
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

5.3 Define scope
All of the requirements identified in Collect Requirements may
not be included in the project

Select the final project requirements from the requirements

documentation

Develop a detailed description of the outcomes of the project

A detailed project scope statement is critical to project success

5.3 Define scope
Process is iterative:
The project scope is defined and described with greater
specificity as more information about the project is known.

Existing risks, assumptions, and constraints are analyzed for

completeness and added or updated as necessary.
5.3 Define scope

Inputs Tools & Techniques Outputs

1. Scope management 1. Expert judgment 1. Project scope
plan 2. Product analysis statement
2. Project charter 3. Alternatives 2. Project documents
3. Requirements generation updates
documentation 4. Facilitated workshops
4. Organizational
process assets
Expert judgement

Expert judgment is often used to analyze the information

needed to develop the project scope statement.
Such judgment and expertise is applied to any technical
detail.
Such expertise is provided by any group or individual with
specialized knowledge or training, and is available from
many sources, including but not limited to:
Other units within the organization;
Consultants;
Stakeholders, including customers or sponsors;
Professional and technical associations;
Subject matter experts.
Requirement Analysis
Step 1: Categorize Requirements
To make analysis easier, consider grouping the requirements into these four
categories:
Functional Requirements – These define how a product/service/solution should function
from the end-user's perspective. They describe the features and functions with which the
end-user will interact directly.
Operational Requirements – These define operations that must be carried out in the
background to keep the product or process functioning over a period of time.
Technical Requirements – These define the technical issues that must be considered to
successfully implement the process or create the product.
Transitional Requirements : A classification of requirements that facilitate transition from
the current state to the desired future state, but that will not be needed once that
transition is complete.
Requirement Analysis
Step 2: Interpret and Record Requirements
Define requirements precisely – Ensure that the requirements are:
Not ambiguous or vague.
Clearly worded.
Sufficiently detailed so that everything is known.
Related to the business needs.
Listed in sufficient detail to create a working system or product design.
10 ambiguous phrases to avoid when writing requirements
“Acceptable”,” Adequate”. “Maximise”, “Minimise” or
Define the acceptance criteria. “Optimise”.
Declare the maximum and minimum
“Better”, “Faster”.
acceptable values.
Quantify how much better or faster
constitutes a satisfactory “Reasonable”, “When necessary”,
improvement. “Where appropriate”.
“Etc.”, “Such as” or “So on”. Explain how to make this judgement.

Be explicit about what happens “Robust” or “Easy to use”.

next. Describe the expected operating
“Flexible” conditions.

Explain the actual variables. “Some”, “Several” or “Many”.

“ideally” or “Normally”. State how many, or provide the
minimum and maximum limits.
Define expected outcomes when
under non-ideal or abnormal “Sufficient”.
conditions. Specify how much of something
equals’ the right amount.
Requirement Analysis
Step 3: Prioritize requirements –
Although many requirements are important, some are more important than others, and
budgets are usually limited. MoSCoW
Step 4: Analyze the impact of change
Carry out an Impact Analysis to make sure that you understand fully the consequences your
project will have for existing processes, products and people.
Step 5: Resolve conflicting issues –
Sit down with the key stakeholders and resolve any conflicting requirements issues.
Step 6: Sign Off
Finally, make sure you get the signed agreement of key stakeholders saying that the
requirements as presented precisely reflect their needs.
This formal commitment will play an important part in ensuring that the project does not
suffer from scope creep later on
Value engineering/Analysis - Example
Project to develop a new bike.

After breaking the bike down into component parts a matrix is

prepared to show how each component contributes to four basic
functions of a bicycle:

Structural – load bearing

Motion – conversion of effort into motion
Control – control of direction and speed
Aesthetic – looking good
Value engineering/Analysis - Example
Estimation for 'Front fork': 45% of its function is structural, 45% is for control
and 10% is to look good.
The percentages have been multiplied by the total cost of $16 to give a cost
per function.
Value engineering/Analysis - Example
Result: How much is spent on each function that the bike performs.
5.3 Define scope

Inputs Tools & Techniques Outputs

1. Scope management 1. Expert judgment 1. Project scope
plan 2. Product analysis statement
2. Project charter 3. Alternatives 2. Project documents
3. Requirements generation updates
documentation 4. Facilitated workshops
4. Organizational
process assets
Project scope statement

The project scope statement is the description of the project

scope, major deliverables, assumptions, and constraints.
It documents the entire scope, including project and product
scope.
It describes, in detail, the project’s deliverables and the work
required to create those deliverables.
It may contain explicit scope exclusions that can assist in
managing stakeholder expectations.
It enables the project team to perform more detailed planning
It provides the baseline for evaluating whether requests for
changes or additional work are contained within or outside the
project’s boundaries
Project scope statement

Project scope statement, either directly, or by reference to other

documents, includes the following:
Project scope description
Acceptance criteria
List if deliverables - Also include ancillary results, such as project
management reports and documentation
Project exclusion. Generally identifies what is excluded from the project.
Constraints. A limiting factor that affects the execution of a project or
process:
Ex: Predefined budget or any imposed dates or schedule milestones issued by
the customer or performing organization
Assumptions. A factor in the planning process that is considered to be true,
real, or certain, without proof or demonstration.Also describes the
potential impact of those factors if they prove to be false.
Ex: Availability of specific resources, experts,..
Project Charter vs Project Scope Statement
Although the project charter and the project scope statement are sometimes
perceived as containing a certain degree of redundancy, they are different in
the level of detail contained in each.
The project charter contains highlevel information, while the project scope
statement contains a detailed description of the scope elements.
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

5.4 Create WBS – Work Breakdown Structure
Create WBS is the process of subdividing project
deliverables and project work into smaller, more
manageable components.

The key benefit of this process is that it provides a

structured vision of what has to be delivered.
 5.4 Create WBS

Inputs Tools & Techniques Outputs

1. Scope management plan 1. Decomposition 1. Scope baseline
2. Project scope statement 2. Expert judgment 2. Project documents
3. Requirements updates
documentation
4. Enterprise environmental
factors
5. Organizational process
assets
Decomposition
Decomposition - Top-Down Approach
Technique used for dividing and subdividing the project scope and project
deliverables into smaller, more manageable parts.
The work package is the work defined at the lowest level of the WBS for which
cost and duration can be estimated and managed.
The level of decomposition is guided by the degree of control needed to
effectively manage the project.
Decomposition of the total project work into work packages generally involves
the following activities:
Identifying and analyzing the deliverables and related work;
Structuring and organizing the WBS;
Decomposing the upper WBS levels into lower-level detailed components;
Developing and assigning identification codes to the WBS components;
Verifying that the degree of decomposition of the deliverables is appropriate
Work Breakdown Structure: Example
Mindmapping –
WBS for constructing a house
Project Statement of Work: Example

Project objectives Technical Requirement

Construct a custom home within 6 Must meet local building codes
months at a cost not to execeed Eur
Garage will accomadate two large-
200 000.
size cars
Deliverables Structures must meet seisismic norms
A 150m², 2 baths, 3 bedroom finished
Limits and exclusions
home
Owner is responsible for landscaping
A finished garage, insulated
Refrigerator is not included in kitchen
Kitchen appliances to include oven,
appliances
microwave and dishwasher
Air conditionning is not included, but
Milestones prewiring is included
Permits approved: Oct. 1st
Customer review
Foundation poured: Nov. 1st
David & Kris Lee
Waterproof: Feb 1st
Final inspection: March 31
Intial work
First level of details

Add levels of details, do not change the scope

Drill down on activity "Foundation"
Drill down on activity "Foundation"
Focus on external works
Focus on external works
Focus on internal works
Focus on internal works
WBS: The whole picture
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.5 Control Scope

(*): Work Breakdown Structure

5.5 Validate Scope

Validate Scope is the process of formalizing acceptance of

the completed project deliverables.

The key benefit of this process is that it brings objectivity to

the acceptance process and increases the chance of final
product, service, or result acceptance by validating each
deliverable.

The project deliverables are reviewed with the customer or

sponsor to ensure that they are completed satisfactorily and
have received formal acceptance.
5.5 Validate Scope vs Control Quality

The Validate Scope process differs from the Control Quality

process
Validate Scope:
Primarily concerned with acceptance of the deliverables.
Control Quality
Primarily concerned with correctness of the deliverables and meeting
the quality requirements specified for the deliverables
Control Quality is generally performed before Validate Scope,
although the two processes may be performed in parallel.
5.5 Validate scope

Inputs Tools & Techniques Outputs

1. Project management 1. Inspection 1. Accepted
plan 2. Group decision-making deliverables
2. Requirements 3. techniques 2. Change requests
documentation 3. Work performance
3. Requirements information
traceability matrix 4. Project documents
4. Verified deliverables updates
5. Work performance
data
5.5 Validate scope : Inputs

Verified Deliverables
Verified deliverables are project deliverables that are completed
and checked for correctness through the Control Quality process.

Work Performance Data

Work performance data can include the degree of compliance with
requirements, number of nonconformities, severity of the
nonconformities.
5.5 Validate scope

Inputs Tools & Techniques Outputs

1. Project management 1. Inspection 1. Accepted
plan 2. Group decision-making deliverables
2. Requirements techniques 2. Change requests
documentation 3. Work performance
3. Requirements information
traceability matrix 4. Project documents
4. Verified deliverables updates
5. Work performance
data
5.5 Validate scope : Tools and Techniques
Inspection 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,

audits, and walkthroughs or User Acceptance Tests (UAT)

In some application areas, these different terms have unique

and specific meanings.
5.5 Validate scope

Inputs Tools & Techniques Outputs

1. Project management 1. Inspection 1. Accepted
plan 2. Group decision-making deliverables
2. Requirements techniques 2. Change requests
documentation 3. Work performance
3. Requirements information
traceability matrix 4. Project documents
4. Verified deliverables updates
5. Work performance
data
5.5 Validate scope: Outputs
Accepted Deliverables
Deliverables that meet the acceptance criteria are formally signed off
and approved by the customer or sponsor.
Change Requests
The completed deliverables that have not been formally accepted are
documented, along with the reasons for nonacceptance of those
deliverables. Those deliverables may require a change request for
defect repair.
Work Performance Information
Work performance information includes information about project
progress, such as which deliverables have started, their progress, which
deliverables have finished, or which have been accepted
Project Scope Management - Overview
Project Scope
Management

5.1 Plan Scope

5.2 Collect Requirements
Management

5.3 Define Scope 5.4 Create WBS (*)

5.5 Validate Scope 5.6 Control Scope

(*): Work Breakdown Structure

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

The key benefit of this process: It allows the scope baseline to be maintained
throughout the project.

Controlling the project scope ensures all requested changes and

recommended corrective or preventive actions are effectively processed.

The uncontrolled expansion to product or project scope without adjustments

to time, cost, and resources is referred to as scope creep.

Change is inevitable. therefore some type of change control process is

mandatory for every project.
5.6 Control Scope

Inputs Tools & Techniques Outputs

1. Project management 1. Variance analysis 1. Work performance
plan information
2. Requirements 2. Change requests
documentation 3. Project management
3. Requirements plan updates
traceability matrix 4. Project documents
4. Work performance data updates
5. Organizational process 5. Organizational
assets process assets
updates
5.6 Control Scope: Tools & techniques

Variance Analysis

Variance analysis is a technique for determining the cause and degree

of variance relative to the scope and deciding whether corrective or
preventive action is required.

Project performance measurements are used to assess the magnitude

of variation from the scope baseline.
Index: Six process groups

Plan Scope Management

Collect Requirements
Define Scope
Create WBS: Work Breakdown Structure
Validate Scope
Control Scope