SCOPE

Session 3
 5.1 Plan Scope Management [P] The process of creating a scope
management plan that documents how the project and product scope
will be defined, validated, and controlled.

5.2 Collect Requirements [P] The process of determining,

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

5.3 Define Scope [P] The process of developing a detailed description

of the project and product.

5.4 Create WBS [P] The process of subdividing project deliverables

Chapter 5 and project work into smaller, more manageable components.

5.5 Validate Scope [M&C] The process of formalizing acceptance of

PROJECT SCOPE MANAGEMENT the completed project deliverables.
includes the processes required to ensure that the project
5.6 Control Scope [M&C] The process of monitoring the status of the
includes all the work required, and only the work required,
project and product scope and managing changes to the scope
to complete the project successfully
baseline.

2
 PROJECT MANAGEMENT PROCESS GROUPS
Project Management Process Groups
Knowledge Areas
Initiating Planning Executing Monitoring and Controlling Closing
4. Integration 4.1 Develop Project 4.3 Direct and Manage Project Work 4.5 Monitor and Control Project Work 4.7 Close Project
4.2 Develop Project Management Plan
Management Charter 4.4 Manage Project Knowledge 4.6 Perform Integrated Change Control or Phase
5.1 Plan Scope Management
5. Scope Management 5.2 Collect Requirements 5.5 Validate Scope
5.3 Define Scope 5.6 Control Scope
5.4 Create WBS
6.1 Plan Schedule Management
6.2 Define Activities
6. Schedule Management
6.3 Sequence Activities 6.6 Control Schedule
6.4 Estimate Activity Durations
6.5 Develop Schedule
7.1 Plan Cost Management
7. Cost Management 7.2 Estimate Costs 7.4 Control Costs
7.3 Determine Budget
8. Quality Management 8.1 Plan Quality Management 8.2 Manage Quality 8.3 Control Quality
9.3 Acquire Resources
9.1 Plan Resource Management
9. Resource Management 9.4 Develop Team 9.6 Control Resources
9.2 Estimate Activity Resources
9.5 Manage Team
10. Communications
10.1 Plan Communications Management 10.2 Manage Communications 10.3 Monitor Communications
Management
11.1 Plan Risk Management
11.2 Identify Risks
11. Risk Management 11.3 Perform Qualitative Risk Analysis 11.6 Implement Risk Responses 11.7 Monitor Risks
11.4 Perform Quantitative Risk Analysis
11.5 Plan Risk Responses
12. Procurement
12.1 Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements
Management
13. Stakeholder
13.1 Identify Stakeholders 13.2 Plan Stakeholder Engagement 13.3 Manage Stakeholder Engagement 13.4 Monitor Stakeholder Engagement 3
Management
 PROJECT SCOPE
MANAGEMENT
Includes the processes required to ensure that:
1. the project includes ALL and ONLY the work required,
to complete the project successfully.
2. WHAT IS and IS NOT included in the project.
4
 KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT
Product scope. The features and functions that characterize a product, service, or result.
Project scope. The work performed to deliver a product, service, or result with the specified features and functions.
The term “project scope” is sometimes viewed as including product scope

In an adaptive or agile life cycle, the deliverables are developed over multiple iterations where a detailed scope is defined
and approved for each iteration when it begins. Three processes (Collect Requirements, Define Scope, and Create WBS)
are repeated for each iteration.

In a predictive life cycle, the project deliverables are defined at the beginning of the project and any changes to the scope
are progressively managed. Three processes (Collect Requirements, Define Scope, and Create WBS) are performed toward
the beginning of the project and updated as necessary, using the integrated change control process.

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT 5

 KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT (cont.)
In an adaptive or agile life cycle, the sponsor and customer representatives should be continuously engaged with the
project to provide feedback on deliverables as they are created and to ensure that the product backlog reflects their
current needs. Two processes Validate Scope and Control Scope are repeated for each iteration. Projects with adaptive life
cycles use backlogs (including product requirements and user stories) to reflect their current needs.

In a predictive project, Validate Scope occurs with each deliverable or phase review and Control Scope is an ongoing
process. In predictive projects, the scope baseline for the project is the approved version of the project scope statement,
work breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only through formal
change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope
processes as well as other controlling processes. Projects with adaptive life cycles use backlogs (including product
requirements and user stories) to reflect their current needs.

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT 6

 KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT (cont.)
Completion of the project scope is measured against the project management plan
Completion of the product scope is measured against the product requirements

The term “requirement” is defined as a condition or capability that is required to be present in a product, service, or result
to satisfy an agreement or other formally imposed specification.

Validate Scope is the process of formalizing acceptance of the completed project deliverables. The verified deliverables
obtained from the Control Quality process are an input to the Validate Scope process. One of the outputs of Validate
Scope is accepted deliverables that are formally signed off and approved by the authorized stakeholder. Therefore, the
stakeholder needs to get involved early on during planning (sometimes initiating as well) and to provide inputs about
quality of deliverables so that Control Quality can assess the performance and recommend necessary changes.

Assume that you are the project manager for the buyer for all questions on the exam that involve procurement,
unless the question specifically states otherwise.

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT 7

 TIP
Project Management Plan: 19 components: Scope baseline has 5 components: Project scope statement has 4 components:
1. Scope management plan 1. Project scope statement 1. Project scope description
2. Requirements management plan 2. WBS 2. Deliverables
3. Schedule management plan 3. WBS dictionary 3. Acceptance criteria
4. Cost management plan 4. Planning package (inside WBS, below 4. Project exclusion
5. Quality management plan the control account and above work
6. Resource management plan package)
7. Communications management plan 5. Work package (inside WBS, lowest
8. Risk management plan level)
9. Procurement management plan
10. Stakeholder engagement plan
11. Change management plan
12. Configuration management plan Project scope description includes Product
13. Scope baseline scope
14. Schedule baseline • Project scope: work to deliver features,
15. Cost baseline functions; include Product scope
16. Performance measurement baseline • Product scope: The features & functions
17. Project life cycle description that characterize a product, service, or
18. Development approach result.
19. Management reviews

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT 8

5.1 Plan Scope Management
The process of creating a scope management plan that documents how the project and product scope will
be defined, validated, and controlled.

9
 5.1 PLAN SCOPE MANAGEMENT
The process of creating a scope management plan that documents
?
how the project and product scope will be defined, validated, and
controlled.

1/ it provides guidance and direction on how scope will be managed

throughout the project.
This process is performed once or at predefined points in the project.

Project charter Expert judgment Scope management plan

Requirements management
Project management plan Data analysis
plan
Enterprise environmental
Meetings
factors
Organizational process assets

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.1 PLAN SCOPE MANAGEMENT 10

 5.1 PLAN SCOPE MANAGEMENT (cont.)
i The development of the scope management plan and the detailing of the project scope begin with:
1/ the analysis of information contained in the project charter (Section 4.1.3.1),
2/ the latest approved subsidiary plans of the project management plan (Section 4.2.3.1),
3/ historical information contained in the organizational process assets (Section 2.3),
4/ any other relevant enterprise environmental factors (Section 2.2)

The same with all the FIRST PROCESS of PLANNING PG in any KA, we need inputs:
• Project charter
• Project management plan
• EEF
• OPA

5.1 PLAN SCOPE MANAGEMENT 11

5.1 PLAN SCOPE MANAGEMENT – INPUTS
1
Project Charter (*)
documents the project purpose, high-level information
(project description, assumptions, constraints, requirements)
that the project is intended to satisfy.

issued by the project initiator or sponsor

formally authorizes the existence of a project

Authority for project manager to apply organizational

resources to project activities

2 Quality management plan

Project management plan (*) The way the project and product scope will be managed can be influenced by
how the organization’s quality policy, methodologies, and standards are
document that describes how the project will be executed, implemented on the project
monitored and controlled, and closed
Project life cycle description The project life cycle determines the series of phases that a project passes
integrates and consolidates all of the subsidiary through from its inception to the end of the project.
management plans and baselines,… to manage the project.
Development approach The development approach defines whether waterfall, iterative, adaptive, agile,
or a hybrid development approach will be used
There are 19 components

3
Enterprise environmental factors
4
Organizational process assets

5.1 PLAN SCOPE MANAGEMENT 12

5.1 PLAN SCOPE MANAGEMENT – TOOLS & TECHNIQUES
1
Expert Judgment provided by group/person with specialized education, knowledge, skill, experience, or training

judgment provided based upon expertise • Previous similar projects

(application area, Knowledge Area, discipline, industry,…) • Information in the industry, discipline, and application area.
2
Data analysis Alternatives analysis Root cause analysis Trend analysis

Cost-benefit analysis Earned value analysis Variance analysis

3 Attendees may include the project manager, the project sponsor, selected project team members, selected
Meetings stakeholders, anyone with responsibility for any of the scope management processes, and others as needed.

5.1 PLAN SCOPE MANAGEMENT 13

5.1 PLAN SCOPE MANAGEMENT – OUTPUTS
1
Scope management plan (*) Process for preparing a project scope statement

Components
describes how the scope will be defined, developed, Process that enables the creation of the WBS from the detailed project scope statement
monitored, controlled, and validated.
Process that establishes how the scope baseline will be approved and maintained
can be formal or informal, broadly framed or highly detailed, Process that specifies how formal acceptance of the completed project deliverables will be obtained
based on the needs of the project.

2
Requirements management plan (*) How requirements activities will be planned, tracked, and reported

Components
describes how project and product requirements will be Configuration management activities such as: how changes will be initiated, analyzed (impacts), traced, tracked, reported;
analyzed, documented, and managed authorization levels required to approve these changes

Requirements prioritization process

Metrics that will be used and the rationale (reason) for using them

Traceability structure that reflects the requirement attributes captured on the traceability matrix

Requirements management plan is available BEFORE Collect Requirements process

5.1 PLAN SCOPE MANAGEMENT 14

5.2 Collect Requirements
The process of determining, documenting, and managing stakeholder needs and requirements to meet project
objectives.

15
 5.2 COLLECT REQUIREMENTS
The process of determining, documenting, and managing stakeholder
?
needs and requirements to meet project objectives.

1/ it provides the basis for defining the product scope and project
scope.
This process is performed once or at predefined points in the project.

Project charter Expert judgment Requirements documentation

Requirements traceability
Project management plan Data gathering
matrix
Project documents Data analysis
Business documents Decision making
Agreements Data representation
Enterprise environmental
Interpersonal and team skills
factors
Organizational process assets Context diagram
Prototypes

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.2 COLLECT REQUIREMENTS 16

 5.2 COLLECT REQUIREMENTS (cont.)
Requirements INCLUDE conditions / capabilities that are required to be present in a product, service, or
i result to satisfy an agreement or other formally imposed specification.
Is the basis for Cost, schedule, quality
planning, and procurement. quantified and documented needs and expectations of the sponsor, customer, and
other stakeholders.

NEED TO BE elicited, analyzed, and recorded in enough detail.

included in the scope baseline

measured once project execution begins.

The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into project
and product requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or
result of the project.

Product requirements include: Project requirements (project management effort) include:

• Business requirement • Project requirement
• Stakeholder requirement • Quality requirement
• Solution requirement
ü Functional requirement
ü Nonfunctional requirement
• Transition requirement

5.2 COLLECT REQUIREMENTS 17

5.2 COLLECT REQUIREMENTS – INPUTS
1
Project Charter (*)
2 Scope management plan
Project management plan (*) how the project scope will be defined and developed.

Requirements management plan how project requirements will be collected, analyzed, and documented.

Stakeholder engagement plan stakeholder communication requirements & level of stakeholder engagement.

3 Assumption Log
Project documents (*) identified assumptions about the product, project, environment, stakeholders,
… that can influence requirements.
Lessons learned register provide information on effective requirements collection techniques.

Stakeholder Register identify stakeholders who can provide information on the requirements.
Also captures requirements and expectations of that stakeholders

4 business case can describe required, desired and optional criteria to meet the business needs.
Business documents (*)
determine whether the expected outcomes of the project justify
the required investment.

5
Agreements (*) can contain project and product requirements.

Are used to define initial intentions for a project

6
Enterprise environmental factors
7
Organizational process assets

5.2 COLLECT REQUIREMENTS 18

5.2 COLLECT REQUIREMENTS – TOOLS & TECHNIQUES
1
Expert Judgment provided by group/person with specialized education, knowledge, skill, experience, or training

judgment provided based upon expertise Business analysis, Requirements elicitation, Requirements analysis, Requirements documentation, Project
(application area, Knowledge Area, discipline, industry,…) requirements in previous similar projects, Diagramming techniques, Facilitation, and Conflict management
2
Data gathering (*) Brainstorming generate and collect multiple ideas

Interviews 1/n : 1/n, useful for obtaining confidential information

Focus groups prequalified stakeholders and subject matter experts (SME)

Questionnaires & surveys quickly accumulate information from a large number of respondents

Benchmarking comparing actual/planned things to those of comparable organizations to

identify best practices, generate ideas for improvement, and provide a basis for
measuring performance. (internal/external)
3
Data analysis [In this process] analyzing existing documentation and identifying information relevant to the requirements
4
Decision Making Voting (1) Unanimity = consensus (100%) (Delphi = consensus + anonymous) //
(2) Majority (>50%) // (3) Plurality (largest group/option)

Autocratic decision making One individual takes the responsibility for making decision for entire group

Multicriteria decision analysis uses a decision matrix to provide a systematic analytical approach (weighted
included)
5
Data Representation Affinity (relation) diagrams allow large numbers of ideas to be classified into groups (20% increased)

Mind mapping reflect commonality and differences in understanding and to generate new ideas

5.2 COLLECT REQUIREMENTS 19

5.2 COLLECT REQUIREMENTS – TOOLS & TECHNIQUES (cont.)
6
Interpersonal and team skills Nominal group technique enhances brainstorming with a voting process with 4 steps

describes how the scope will be defined, developed, 1/ Individuals write down their ideas silently 2/ All the ideas are recorded
monitored, controlled, and validated.
3/ Discuss each idea 4/ Individuals vote privately to prioritize the ideas

Observation/conversation viewing individuals in their environment and how they perform their jobs or
tasks and carry out processes. (job shadowing)

Facilitation is used with focused sessions that bring key stakeholders together to define
product requirements. Cross-functional + buyin

Joint application bringing business SMEs and the development team together to gather
design/development (JAD) requirements and improve the software development process.

Quality function deployment determine critical characteristics for new product development, starts by
(QFD) collecting customer needs (voice of the customer - VOC)

User stories describe the stakeholder role, who benefits from the feature (role), what the
stakeholder needs to accomplish (goal), and the benefit to the stakeholder
(motivation).

7
Context diagram visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and
how interacted with it by people and other systems (actors).

8
Prototypes Storyboarding showing sequence or navigation through a series of images or illustrations

is a method of obtaining early feedback on

requirements by providing a model of the expected
product before actually building it.

5.2 COLLECT REQUIREMENTS 20

5.2 COLLECT REQUIREMENTS – OUTPUTS
Resolving Competing Requirements
Some issues are so complex they cannot be resolved by the project manager alone, and require management intervention.
However, there are some standard guidelines for balancing competing requirements. Walk through the following list for each
requirement.

You should resolve competing requirements by accepting those that best comply with following:
• The business case stating the reason the project was initiated (market demand, legal requirement, etc.)
• The project charter
• The project scope statement (if this is available at the time of the conflict)
• The project constraints

A stakeholder’s request to do or add something to the project that is not related to the reason the project was initiated should be
rejected.
If a requirement is related to the reason the project was initiated but does not fall within the project charter, this request should
also be rejected.
Any suggested changes to the project charter must be brought to the sponsor for approval.
When considering constraints, if the most important constraint is schedule, then any requirements that would delay the schedule
will not likely be accepted. Those that enhance the schedule (without serious impact to other project constraints) will more likely
be accepted. Requests that do not fall within these guidelines could become part of a future project instead.
Refer to Perform Integrated Change Control!

5.2 COLLECT REQUIREMENTS 21

5.2 COLLECT REQUIREMENTS – OUTPUTS
1
Requirements documentation (*) Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent,
and acceptable to key stakeholders
describes how individual requirements meet the business
need for the project. format of the 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 may start out at a high level and become progressively more detailed as more information about the
requirements is known. Can be grouped into classifications allowing for further refinement and detail:

Business requirements Solution requirements Project requirements

describe the higher-level describe features, functions, and describe the actions, processes, or other
organization needs characteristics of the outcomes. conditions ( milestone, contraints,..)
Functional & non-functional requirements
Stakeholder requirements Transition & readiness requirements Quality requirements
describe the stakeholder or describe temporary capabilities (training Capture any condition/criteria needed to
group needs requirements, data conversion,..) validate deliverable or fulfill
requirements (tests, certs, validations,…)

2
Requirements traceability matrix ensure that each requirement adds business value by linking it to the business and project objectives.

a grid that links product requirements from their origin to ensure that requirements approved in the requirements documentation are delivered at the end of the project
the deliverables that satisfy them.
it provides a structure for managing changes to the product scope

5.2 COLLECT REQUIREMENTS 22

5.2 COLLECT REQUIREMENTS – OUTPUTS
Requirements Traceability Matrix

5.2 COLLECT REQUIREMENTS 23

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

24
 5.3 DEFINE SCOPE
The process of developing a detailed description of the project and
?
product.

1/ it describes the product, service, or result boundaries and

acceptance criteria

Project charter Expert judgment Project scope statement

Project management plan Data analysis Project documents updates
Project documents Deccision making
Enterprise environmental
Interpersonal and team skills
factors
Organizational process assets Product Analysis

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.3 DEFINE SCOPE 25

 5.3 DEFINE SCOPE (cont.)
i Identify
Collect Requirements Requirements documentation
all the requirements

develop
Define Scope Detailed description of the outcomes
final project requirements

All the requirements identified in Collect Requirements may not be included in the project.

The preparation of a detailed project scope statement builds upon the major deliverables, assumptions, and constraints that are
documented during project initiation. During project planning, the project scope is defined and described with greater specificity as
more information about the project is known

The Define Scope process can be highly iterative.

In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one
iteration at a time, and the detailed planning for the next iteration is carried out as work progresses on the current project scope and
deliverables.

5.3 DEFINE SCOPE 26

5.3 DEFINE SCOPE – INPUTS
1
Project Charter (*)

2 Scope management plan

Project management plan (*) documents how the project scope will be defined, validated, controlled.

3 Assumption log
Project documents (*) identifies assumptions and constraints about the product, project, environment,
stakeholders, and other factors that can influence the project and product
scope

Requirements documentation Identifies requirements that will be incorporated into the scope.

Risk register contains response strategies that may affect the project scope, such as reducing
or changing project and product scope to avoid or mitigate a risk

4
Enterprise environmental factors
5
Organizational process assets

5.3 DEFINE SCOPE 27

5.3 DEFINE SCOPE – TOOLS & TECHNIQUES
1
Expert Judgment provided by group/person with specialized education, knowledge, skill, experience, or training

judgment provided based upon expertise

(application area, Knowledge Area, discipline, industry,…)

2
Data analysis Alternatives analysis Root cause analysis Trend analysis

Cost-benefit analysis Earned value analysis Variance analysis

3
Decision Making Voting Autocratic decision making Multicriteria decision analysis

4
Interpersonal and team skills 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 & common understanding of the project

deliverables and project and product boundaries.

5
Product analysis (*) Requirements are captured at a high level and decomposed to the level of detail needed to design the final product.

Product analysis can be used to define products and services.

It includes asking questions about a product or service and • Product breakdown
forming answers to describe the use, characteristics, and • Requirements analysis
other relevant aspects of what is going to be delivered • Systems analysis
• Systems engineering
Deliver the same scope with least costs
Finding the less costly way to execute the work
• Value analysis
• Value engineering: Deliver the same scope with least costs

5.1 PLAN SCOPE MANAGEMENT 28

5.3 DEFINE SCOPE – OUTPUTS
1
Project scope statement may contain explicit scope exclusions that can assist in managing stakeholder expectations.

Describes enables the project team to:

• entire scope project and product scope • perform more detailed planning,
• major deliverables in detail • guides the project team’s work during execution,
• assumptions • provides the baseline for evaluating whether requests for changes/additional work are contained within/outside the
• constraints project’s boundaries

a detailed description of the scope components. Different Project scope description Progressively elaborates the characteristics of the outcomes described in the
with Project Charter is just contains high-level information project charter and requirements documentation. Includes product scope.

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

Acceptance criteria A set of conditions that is required to be met before deliverables are accepted

Project exclusions Identifies what is excluded from the project

2
Project documents updates Project documents that may be updated as a result of carrying out this process

Assumption log Requirements Requirements traceability matrix Stakeholder register

documentation

5.1 PLAN SCOPE MANAGEMENT 29

 TIP
Project Management Plan: 19 components: Scope baseline has 5 components: Project scope statement has 4 components:
1. Scope management plan 1. Project scope statement 1. Project scope description
2. Requirements management plan 2. WBS 2. Deliverables
3. Schedule management plan 3. WBS dictionary 3. Acceptance criteria
4. Cost management plan 4. Planning package (inside WBS, below 4. Project exclusion
5. Quality management plan the control account and above work
6. Resource management plan package)
7. Communications management plan 5. Work package (inside WBS, lowest
8. Risk management plan level)
9. Procurement management plan
10. Stakeholder engagement plan
11. Change management plan
12. Configuration management plan Project scope description includes Product
13. Scope baseline scope
14. Schedule baseline • Project scope: work to deliver features,
15. Cost baseline functions; include Product scope
16. Performance measurement baseline • Product scope: The features & functions
17. Project life cycle description that characterize a product, service, or
18. Development approach result.
19. Management reviews

KEY CONCEPTS FOR PROJECT SCOPE MANAGEMENT 30

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

31
 5.4 CREATE WBS
The process of subdividing project deliverables and project work into
?
smaller, more manageable components.

1/ it provides a framework of what has to be delivered

This process is performed once or at predefined points in the project.

Project management plan Expert judgment Scope baseline

Project documents Decomposition Project documents updates
Enterprise environmental
factors
Organizational process assets

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.4 CREATE WBS 32

 5.4 CREATE WBS (cont.) No time-sequence

Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the
i project objectives and create the required deliverables.

organizes and defines the total scope of the project and represents the work specified in the current approved
project scope statement.

represents ALL product and project work, including the project management work. The total of the work at the
“breakdown structure” = hierarchical lowest levels should roll up to the higher levels so that NOTHING is left out and NO extra work is performed. This is
sometimes called the 100 percent rule.

may be structured as an outline, an organizational chart,… that identifies a hierarchical breakdown.

Work In the context of the WBS, it refers to work products/deliverables that are:

Result of activity

NOT to the activity itself

Control account is a management control point where scope, budget, and schedule are integrated and compared to the earned
value for performance measurement.

has two or more work packages, though each work package is associated with a single control account

Work package is the work defined at the lowest level of the WBS with a unique identifier.

Provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of
accounts.

is part of a control account.

5.4 CREATE WBS 33

 5.4 CREATE WBS (cont.)
i Work Breakdown Structure (WBS)

Every WBS is unique, and every project manager will approach creating a WBS in their own way. But there are a few guidelines
that every project manager should follow when creating a WBS:
• WBS should be created by the project manager using input from the team and other stakeholders.
• Each level of a WBS is a breakdown of the previous level.
• An entire project should be included in the highest levels of a WBS. Eventually, some levels will be further broken down.
• A WBS includes only project deliverables that are required; deliverables not included in the WBS are not part of the
project.

During planning, the project management team and SMEs break down the scope description until the work package level is
reached. This occurs when the deliverables:
• Can be realistically and confidently estimated (including the activities, duration, and cost associated with them)
• Can be completed quickly
• Can be completed without interruption and without the need for more information
• May be outsourced

The exam may use the term “deconstruction” instead of “decomposition.” Both terms mean the same thing.

5.4 CREATE WBS 34

5.4 CREATE WBS – INPUTS
1 Scope management plan
Project management plan (*) describes how the WBS will be created from the project scope statement

2 Project scope statement

Project documents (*) describes the work that will be performed and is excluded

Requirements documentation Detailed requirements describe how individual requirements meet the business
need for the project
3
Enterprise environmental factors
4
Organizational process assets

5.4 CREATE WBS 35

5.4 CREATE WBS – TOOLS & TECHNIQUES
1
Expert Judgment provided by group/person with specialized education, knowledge, skill, experience, or training

judgment provided based upon expertise

(application area, Knowledge Area, discipline, industry,…)

2
Decomposition (*) Decomposition of the total project work into work packages generally involves the following activities:

a technique used for dividing and subdividing the project 1. Identifying and analyzing the deliverables and related work,
scope and project deliverables into smaller, more 2. Structuring and organizing the WBS,
manageable parts. 3. Decomposing the upper WBS levels into lower-level detailed components,
4. Developing and assigning identification codes to the WBS components, and
5. Verifying that the degree of decomposition of the deliverables is appropriate.

The WBS structure can be represented in a number of forms

5.4 CREATE WBS 36

5.4 CREATE WBS – OUTPUTS
1
Scope baseline Project scope statement includes the description of the project scope, major deliverables, assumptions,
and constraints
is the approved version of a scope statement, WBS, and its
associated WBS dictionary. WBS 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
is a component of the project management plan which can deliverables. Each descending level of the WBS represents an increasingly
be changed ONLY through formal change control procedures detailed definition of the project work

Work package The lowest level of the WBS is a work package with a unique identifier.
is used as a basis for comparison.
Planning package is a WBS component below the control account and above the work package
with known work content but WITHOUT detailed schedule activities.

WBS dictionary is a document that provides detailed deliverable, activity, and scheduling
information about each component in the WBS. Most of the information
included in the WBS dictionary is created by other processes and added later to
this document.

§ Code of account identifier, § Resources required

§ Description of work § Cost estimates
§ Assumptions and constraints § Quality requirements
§ Responsible organization § Acceptance criteria
§ Schedule milestones § Technical references
§ Associated schedule activities § Agreement information
2
Project Documents Updates Assumption log

Requirements documentation may be updated to include approved changes resulting from the Create WBS
process.

5.4 CREATE WBS 37

5.5 Validate Scope
The process of formalizing acceptance of the completed project deliverables.

38
 5.5 VALIDATE SCOPE
The process of formalizing acceptance of the completed project
?
deliverables.

1/ it brings objectivity to the acceptance process and increases the

probability of final product, service, or result acceptance by validating
each deliverable.
This process is performed periodically throughout the project as needed.

Project management plan Inspection Accepted deliverables

Work performance
Project documents Decision making
information
Verified deliverables Change requests
Work performance data Project document updates

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.5 VALIDATE SCOPE 39

 5.5 VALIDATE SCOPE (cont.)
i Direct and Manage Project Work

Deliverables
The verified deliverables obtained from the Control Quality process are reviewed
Control Quality (internal) with the customer or sponsor (in Validate Scope) to ensure they are completed
satisfactorily and have received formal acceptance of the deliverables by the
Verified Deliverables customer or sponsor.

Control Quality process is primarily concerned with correctness of the

Validate Scope (customer) deliverables and meeting the quality requirements specified for the deliverables.
Validate Scope process is primarily concerned with acceptance of the deliverables.
Accepted Deliverables Control Quality is generally performed before Validate Scope,
although the two processes may be performed in PARALLEL
Close Project or Phase

Final product, service

or result

Change Change requests are evaluated through

request Integrated Change Control, and approved
changes may lead to replanning

5.5 VALIDATE SCOPE 40

5.5 VALIDATE SCOPE – INPUTS
1 Scope management plan
Project management plan (*) specifies how formal acceptance of the completed project deliverables will be
obtained

Requirements management Describes how the project requirements are validated.

plan

Scope baseline The scope baseline is compared to actual results to determine if a change,
corrective action, or preventive action is necessary

3 Lessons learned register

Project documents (*) Lessons learned earlier in the project can be applied to later phases in the
project to improve the efficiency and effectiveness of validating deliverables

Quality reports Include all quality assurance, recommendations, summary of findings from the
Control Quality process. Reviewed PIROR to product acceptance.

Requirements documentation Requirements are compared to the actual results to determine if a change,
corrective action, or preventive action is necessary. (same with scope baseline
purpose in this phase)

Requirements traceability Contains information about requirements, including how they will be validated
matrix
4
Verified Deliverables (*)
Verified deliverables are project deliverables that are
completed and checked for correctness through the Control
Quality process.
5 raw observation, can include the degree of compliance with requirements, number of nonconformities, severity of
Work Performance Data (*)
the nonconformities, or the number of validation cycles performed in a period of time.

5.5 VALIDATE SCOPE 41

5.5 VALIDATE SCOPE – TOOLS & TECHNIQUES
1
Inspection (*) includes activities such as measuring, examining, and validating to determine whether work and deliverables meet
requirements and product acceptance criteria.

sometimes called reviews, product reviews, & walkthrough

2
Decision Making Voting Autocratic decision making Multicriteria decision analysis

5.5 VALIDATE SCOPE 42

5.5 VALIDATE SCOPE – OUTPUTS
1
Accepted Deliverables (*) 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.

2
Work Performance Information Describes which deliverables have been/not been accepted and the reasons why.

includes information about project progress

3
Change Requests The completed deliverables that have NOT been formally accepted are documented, along with the reasons for non-
acceptance of those deliverables. Those deliverables may require a change request for defect repair.
are processed for review and disposition through the
Perform Integrated Change Control process

4 Lessons learned register

Project documents Updates updated with information on challenges encountered and how they could have
been avoided as well as approaches that worked well for validating deliverables.

Requirements documentation 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

Requirements traceability updated with the results of the validation, including the method used and the
matrix outcome.

5.5 VALIDATE SCOPE 43

5.6 Control Scope
The process of monitoring the status of the project and product scope and managing changes to the scope
baseline.

44
 5.6 CONTROL SCOPE
The process of monitoring the status of the project and product scope
?
and managing changes to the scope baseline.

1/ the scope baseline is maintained throughout the project

This process is performed throughout the project

Work performance
Project management plan Data analysis
information
Project documents Change requests
Project management plan
Work performance data
updates
Organizational process assets Project documents updates

INPUTS TOOLS & TECHNIQUES OUTPUTS

5.6 Control Scope 45

 5.6 CONTROL SCOPE (cont.)
Control Scope ensures all requested changes and recommended corrective or preventive actions are processed through the
i Perform Integrated Change Control process.

is also used to manage the actual changes when they occur

is integrated with the other control processes

Scope Creep The uncontrolled expansion to product or project scope WITHOUT adjustments to time, cost, and resources

5.6 Control Scope 46

5.6 CONTROL SCOPE – INPUTS
1 Scope management plan
Project management plan (*) Documents how the project and product scope will be controlled.

Requirements management plan Describes how the project requirements will be managed.

Change management plan defines the process for managing change on the project

Configuration management plan Defines those items that are configurable, those items that require formal
change control, and the process for controlling changes to such items.

Scope baseline is compared to actual results to determine if a change, corrective action, or

preventive action is necessary.

Performance measurement baseline When using earned value analysis, the performance measurement baseline is
compared to actual results to determine if a change, corrective action, or
preventive action is necessary

2 Lessons learned register Lessons learned earlier in the project can be applied to later phases in the
Project Documents (*)
project to improve scope control

Requirements documentation is used to detect any deviation in the agreed-upon scope for the project or
product.

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
3
Work Performance Data can include the number of change requests received, accepted, deliverables verified, validated, completed.

4
Organizational process assets

5.6 CONTROL SCOPE 47

5.6 CONTROL SCOPE – TOOLS & TECHNIQUES
1 Variance analysis is used to compare the baseline to the actual results and determine if the
Data Analysis (*)
variance is within the threshold amount or if corrective or preventive action is
appropriate.

Trend analysis examines project performance over time to determine if performance is

improving or deteriorating

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.

5.6 CONTROL SCOPE 48

5.6 CONTROL SCOPE – OUTPUTS
1
Work Performance Information (*) includes 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.

3
Project Management Plan Updates Scope management plan Scope baseline Schedule baseline Cost baseline

Performance measurement baseline

4
Project Documents Updates Lessons learned register Requirements documentation Requirements traceability matrix

5.6 CONTROL SCOPE 49

Thank You
Atoha Institute of Project Management
+84 28 6684 6687

[email protected]