Scope Management

Location: PMKI > PM Knowledge Areas > Scope Management.
The PMKI Library

This subject covers the work required to ensure the project or program includes all of the work needed, and only the work needed, to achieve its objectives and that the outputs are successfully delivered to the client.

Topics included in Scope Management:

- Scope management overview
- Collect and manage requirements
- Define and manage scope
- Create WBS & other Breakdown structures
- Scope Validation, Verification and Control
- Useful External Web-links & Resources.

Other related sections of the PMKI:

- Cost estimating and management, including Earned Value


Integration Management	Cost Management

Scope management overview

Project Scope Management describes the processes required to ensure that the project includes all of the work, and only the work, required to successfully deliver the project's objectives. It is concerned with describing and controlling what is ‘in’, and what is ‘not in’ the work of the project.

The first phase of scope management is defining precisely what has to be achieved to complete the project. The project team work with key stakeholders to assess the detailed project requirements, constraints, and assumptions, based on inputs from the client, or performing organization. such as the project charter, formal contract documents, lessons learned from previous projects, and/or by the use of requirement-gathering techniques (e.g., planning sessions, brainstorming, focus groups). The objective is to establish and agree the precise nature of the deliverables required to successfully accomplish the project's objectves.

The term scope can refer to:

Product scope: the features and functions that characterize the product service or result to be produced (the deliverables)
Project scope: the full scope of work required to be performed to deliver the product service or result in conformance with organizational policies.

Where the term project scope is typically viewed as including the product scope.

Scope management is achieved by:

Planning how scope will be defined, validated and controlled.

Being aware of the problems and challenges of scope definition, particularly on large projects (see Scope for Improvement)

Collecting requirements, to ensure all of the necessary requirements have been identified and delivered.
Defining the scope in sufficient detail to allow the efficient planning and execution of the work needed to deliver the scope.
Creating the WBS and other project breakdown structures to facilitate planning and managing the work.
Validation and verification. Having agreements and systems in place to facilitate the validation of the scope by the client or customer. Successful scope validation means the customer has accepted the project deliverables.
Controlling the scope to minimize unnecessary change, and to ensure all of the required scope is created and delivered to plan.

Collect and manage requirements

Project requirements are the features, functions, and tasks that need to be completed for a project to be deemed successful. They define what has to be achieved and create clear set of parameters to work towards. Determining how the requirements will be implemented in the project's deliverables is a design process.

Creating the design may be:

A separate phase with design approval a key milestone in the project's lifecycle (typical in many engineering and construction projects),
An incremental process, which is the typical approach used in most Agile projects, or
In many traditional industries, the requirements gathering and design my be completed by the client, before engaging a contractor to undertake the work of the project.

However, in every project a fundamental prerequisite to success is making sure the project team fully understand the requirements of their client (even when the client may not fully understand their needs) and everyone agrees what the requirements are. This often requires negotiation, compromise, and trade off between the requirements and other constraints such as time and cost parameters.

WP: Data Gathering & Brainstorming. Gathering requirements needs a planned approach using a range of techniques.

WP: Defining Requirements. The factors to consider in developing a set of requirements.

WP: Ranking Requirements and Selecting Projects. The full list of requirements often needs to be limited an prioritized using techniques such as MoSCW.

WP: Requirements Traceability Matrix. Requirements traceability is the process that facilitates the description of each requirement and sub-requirement and then ensures the requirement is fulfilled.

Blg: Success and Stakeholders. When considering the relationship between success and stakeholders, one potential conclusion is that success is gifted to you by your stakeholders, but you have to earn the gift by delivering what they really require!

PMI's Requirements Management Practice Guide is available free of charge to PMI members, see: https://www.pmi.org/pmbok-guide-standards/practice-guides.

Define and manage scope

Scope Management Fully defining scope and then ensuring the specified requirements are delivered is critically important to achieving project success. There are a number of documents that may be used to define the project’s scope.

Project scope: An overall statement of the work needed to be accomplished to achieve the delivery of the product, service or result (product scope); including objectives, constraints and other relevant items
Product scope: The features and functions that characterize the product, service or result – the deliverables
Design documents: Defining, deigning and documenting the project scope can be done in many different ways depending on the nature of the project, industry standards, and organizational preferences. Options include various forms of engineering or architectural design documents and/or drawings, BIM (see more on BIM), and various forms of IT architecture and data-flow diagrams. Finalizing the design is part of the scope definition process. The design may be prepared completely by the client, completely by the project team, or some combination of both. For example, the client may design the overall concept, leaving the details to be rounded out by the project team
Specification: A set of documents that define the technical attributes (characteristics) of each of the elements of the deliverables, described in a precise way that defines how the deliverable will be created, or what is required, and how conformance to the specification will be assessed or measured (verified)
Statement of work (SoW): A concise narrative description of a deliverable (usually included in a contract or purchase order)

Project Statement of Work – issued by the client to define the project
Procurement Statement of Work – issued by the project team as part of its procurement processes to define the product or service being purchased.

The project's scope baseline consists of the project scope statement, plus the WBS and WBS Dictionary.

WP: Statement of Work (SoW). Statement of Work (SOW) is a formal document that captures and defines the work activities, deliverables and timeline the project (or a vendor) will execute against in performance of specified work for a client. The SOW typically forms part of a purchase order or contract but may be attached to a business case.

Art: Scope for Improvement Too. If a project’s client cannot ask for what it wants, the project team is highly unlikely to deliver what’s needed! Most projects have scope missed until its too late. This article is a discussion on a series of reports focused on scope omissions in major projects, that also discussed in Causes of project failure.

Art: Ethics is not enough. Recent cladding fires demonstrate that achieving reliable quality standards needs more than simply relying on the ethical standards of everyone in the supply chain - the supply system needs to actively support ethical standards to ensure the defined scope is delivered.

Configuration Management. Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes, with its requirements, design, and operational information, throughout its life. The product may be a document or a physical deliverable. The focus of CM is on ensuring all of the components of a deliverable (configuration management items) continue to work together as elements are changed over time, by handling changes systematically.

Configuration management includes processes for:
a. Configuration item identification, identifying and characterizing each item in a database
b. Configuration status accounting:
i. Capturing and accessing information on configuration activities
ii. Verifying continued conformance to requirements
iii. Ensuring accountability is maintained and changes are managed
c. Change management:
i. Knowledge of current project change control processes
ii. Recording and reporting each change
iii. Assessing the value and impact of the changes on the configuration items
iv. Communicating the changes to stakeholders
d. Configuration verification and auditing to ensure performance and functional requirements have
been met.

PMI's Practice Standard for Configuration Management is available free of charge to PMI members, see: https://www.pmi.org/pmbok-guide-standards/framework

Systems Engineering: Is an approach that can assist in the design of the project's scope in complex situations. Systems engineering can be thought of as the principles and methods related to the successful engineering of systems, to meet stakeholder requirements and to maximize value. Systems engineering is problem-independent, and solution/technology-independent. See WP: Systems Thinking.

Front End Loading / Planning: refers to an increased focus on early planning and analysis to the defined scope is capable of achieving the desired outcomes for cost, schedule, and operating performance. It is the project phase that encompasses activities such as feasibility, concept, and detailed scope definition. Note that front end loading has many other equivalent and associated terms, including front end planning, advance planning, pre-project planning, schematic design, and design development. This approach is commonly used on major construction and engineering projects - see more.

Create WBS & other Breakdown structures

Scope Management WP: Work Breakdown Structures. Developing and using a Work Breakdown Structure (WBS).

WBS Standard PMI's Practice Standard for WBS is available free of charge to PMI members. The third edition applies the WBS to the predictive, iterative, incremental, and agile project life cycles; it also explores several different types of decomposition in practice today.
See: https://www.pmi.org/pmbok-guide-standards/framework

Other breakdown structures:

Art: Breakdown Structures Revisited. Details of some of the different types of Breakdown Structure in use today; RBS, OBS, CBS, PBS and others.

Art: PBS -v- WBS, is there a difference? The key differences between, and uses of, the Work Breakdown Structure and the Product Breakdown Structure. This article is based on an APM (UK) publication, download: APM web briefing - Use of Product Breakdown Structures and Work Breakdown Structures.

See more on the origins of the WBS and other business charts.

Scope validation, verification and control

Scope verification = ensuring the deliverables are of an appropriate quality and complete.
This is a quality assurance function - click through to see more.

Scope validation = acceptance of the scope by the client. Validation usually precedes the transfer of the deliverable to the client.

WP: V&V = the Verification and Validation of Deliverables. V&V should be a planned, on-going function that leads to the final acceptance of the project's deliverables by the client.

Useful External Web-links & Resources

PMI Practice Standard for Work Breakdown Structures is available free of charge to PMI members: https://www.pmi.org/pmbok-guide-standards/framework

Configuration Management: Processes to establish and maintain consistency of a product's performance, function and physical attributes with its requirements, design and operational information; throughout the products life. PMI's Practice Standard for Project Configuration Management is available free of charge to PMI members: https://www.pmi.org/pmbok-guide-standards/framework

ISO Standard (with Australian adoption)
- ISO 21511:2018 – Work breakdown structures for project and programme management
(AS ISO 21511:2022)