Which of the following makes up the scope baseline when using a predictive lifecycle approach?

In the project context, the term “scope” can refer to:

• Product scope. The features and functions that characterize a product, service, or result.
• Project scope. The work 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.

Project life cycles can range along a continuum from predictive approaches at one end to adaptive or agile approaches at the other. 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. 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.

Projects with adaptive life cycles are intended to respond to high levels of change and require ongoing stakeholder engagement. The overall scope of an adaptive project will be decomposed into a set of requirements and work to be performed, sometimes referred to as a product backlog. At the beginning of an iteration, the team will work to determine how many of the highest-priority items on the backlog list can be delivered within the next iteration. Three processes (Collect Requirements, Define Scope, and Create WBS) are repeated for each iteration. On the contrary, in a predictive project, these processes are performed toward the beginning of the project and updated as necessary, using the integrated change control process.

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. On the contrary, 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.

Completion of the project scope is measured against the project management plan, while 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.

Source: PMBOK Guide

‘Scope’ is probably one of the most common terms in project management. Often, the scope of a project is subject to different views and intensive discussions among stakeholders, project managers, and team members. A scope baseline is therefore a ‘must’ in every project: it defines and documents the scope of a project clearly and in sufficient detail from the beginning.

In this article, we are going to discuss the components and the purpose of the scope baseline and share an example of its practical use.

What Is a Scope Baseline?

The scope baseline is a bundle of scope-related documents that sets out the approved scope of a project. A project’s scope baseline consists of the scope statement and the defined work breakdown structure of that project, subject the approval of the relevant stakeholders. A project’s results and progress are measured against that baseline.

While this a common and generally accepted definition that is also broadly in line with the PMI terminology, it is not the only one. Some authors define the scope baseline differently.

James Taylor, for instance, describes the scope baseline as a synonym of project baseline which includes technical, cost, and schedule baselines (source). In this example, the term ‘technical baseline’ is used instead of what is generally referred to as the scope baseline.

This example demonstrates how important it is to agree on a single clear terminology in a project.

Which Documents Are Part of the Project Scope Baseline?

The scope baseline of a project consists of:

• the approved project statement,
• the work breakdown structure (WBS), incl. control accounts, planning packages, and work packages, and
• the associated WBS dictionary.

The ‘project scope statement’ is a written definition of the project scope. It describes the goals, main deliverables, and other characteristics of a project.

‘Work breakdown structure’ (WBS) refers to the breakdown of project deliverables into smaller, manageable pieces of work. The lowest level of a WBS represents ‘work packages’. A work package itself consists of various activities (which are technically not part of a work breakdown structure). A planning package is hierarchically higher than work packages, and a controlling account can contain several planning packages.

The WBS dictionary accompanies the work breakdown structure with details on all its constituents, including an identifier, an outline of the work of a WBS element, responsibilities, assumptions, and estimations. The scope and extent of WBS dictionaries vary significantly among the different organizations.

Sources: projectmanagement.com, Project Management Body of Knowledge (PMBOK®), 6th ed., ch. 5.4.3.1.

What Is a Scope Baseline Used For?

The scope baseline is a part of the project plan. It defines the agreed goals, deliverables, and scope of the work of a project. It documents the agreement of the relevant stakeholders and gives the project a work structure as well as guidance in the day to day work.

In project management, a baseline has several functions which include (yet is not limited to):

• controlling and success measurement,
• documentation of agreement,
• basis of change control assessments, and
• protection against scope creep.

Controlling and Success Measurement

The success of a project is – among other criteria – measured against the creation of deliverables and the accomplishment of its goals which are set out in the scope baseline.

Performance Measurement Baseline: Definition | Example | 6-Step Guide

Read more about the use of baselines for project controlling in our earned value management article.

Documentation of Stakeholder Agreement on the Scope

The scope baseline consolidates the consensual expectations and requirements of stakeholders with respect to a project.

While positions, perspectives, and personnel may change in practice, the goals and deliverables of a project, and the relevant stakeholders’ approval are manifested in the scope baseline.

Basis of the Change Control Assessments

Once the scope baseline is approved, any change to the project scope requires the completion of change control processes.

Thus, uncontrolled scope creep or reduction is limited. Amendments of the project scope require a change request and the stakeholders’ agreement on these changes. The change control process also ensures that side effects on the schedule and cost baselines, as well as changing resource needs, are assessed.

Protection against Scope Creep

One of the most unpleasant though common occurrences in projects is scope creep. Scope creep refers to the uncontrolled change or extension of the scope of an ongoing project. This is usually caused by stakeholders or project members who request work or deliverables outside of the initial scope of the project while bypassing the project’s change processes. Adhering to the scope baseline and referring change requestors to the change control process(es) can help to prevent scope creep in a project.

How Do You Develop a Scope Baseline?

The scope baseline is typically developed by the project manager and the PMO or project team. In PMI-style projects, it is am output of the process ‘create work breakdown structure‘ and becomes a part of the project management plan.

The baseline consists of several items that need to be created first. The document bundle is then subject to approval as the scope baseline of the project. Subsequently, it is communicated to the project stakeholders and the project team.

1) Define Scope Statement (incl. Deliverables)

You should summarize the purpose and goals of the project and the key deliverables in a clear statement. According to PMBOK®, it consists of

• Description of the scope,
• Major deliverables,
• Assumptions, and
• Constraints.

In addition to these items, the statement may also include (source):

• Justification / underlying business needs,
• Acceptance criteria,
• Further deliverables,
• Project exclusions.

If you don’t have a lot of experience with the development of scope statements, consider reading this PMI conference paper on that topic.

2) Define Work Breakdown Structure incl. WBS Dictionary

Once you have fixed the scope statement, you need to develop a work breakdown structure to operationalize the creation project deliverables.

Work breakdown structure refers to the so-called ‘decomposition’ of the work that needs to be delivered by a project. It follows a hierarchical order with control accounts, planning packages, and work packages.

At its highest level, it typically contains the main deliverables. These are then broken up into smaller and workable (sub)deliverables, all the way down to the level of work packages.

The work breakdown structure dictionary documents key assumptions, responsibilities, and further details on the WBS.

3) Seek Approval

The scope statement, the WBS, and its dictionary are turned into a scope baseline by obtaining the required stakeholder approval.

In this context, you might wonder which stakeholder approvals you will need for finalizing a baseline.

These approval requirements are individual for every project where they are usually defined in the project charter. Large organizations might also have standard policies on project governance and standardized approval matrixes in place where you will find the detailed requirements.

In practice, project scope baselines are often approved by the project steering committee, consisting of the project sponsor and senior key stakeholders of a project.

4) Communicate Scope Baseline

It is good practice to share and communicate the scope baseline among the project team members and the other stakeholders. It will help those who work on the project to understand the bigger picture and align their areas of responsibility with the overall goals.

Stakeholders that were not involved in the approval process, on the other hand, should know the scope baseline as well.

Communicating the goals, scope, boundaries, and limitations of a project can help prevent scope discussions (outside change control processes) and scope creep further down the road.

For more details about project communications and stakeholder management, visit this dedicated section of our site.

Supplementing this 4-step guide, you will also find a short instruction in this video on projectmanager.com.

Example of a Scope Baseline

In practice, scope baselines are highly tailored to individual projects and tend to be somewhat complex. To illustrate the principles and creation of a scope baseline, we are therefore using a simple everyday example: refurbishing a house or apartment.

For this project, your scope statement would set out that you require:

• replacement windows,
• new flooring,
• painting the walls and ceilings,
• etc.

You might also want to add whether the order of work is important, e. g. replacing windows before the new flooring is installed. In addition, you will want to define a timeline, as well as certain conditions that the work can be performed, e. g. certain minimum qualifications/experience of the workers and a weather forecast that allows for replacing the windows.

Your work breakdown structure would likely contain the main deliverables – flooring, painting, and windows.

A control account and/or planning package could be clearing the floor – with work packages such as removal of old flooring, disposing of the old material, clearing the underground – and preparation, which may include the work packages purchasing, delivery/collection of material, tools and supplies, etc. Note that activities that are parts of work packages, e.g. ‘measure the area’ or ‘drive to the DIY market’, are generally not included in a WBS.

All WBS elements would be documented in the WBS dictionary which contains a description of them, an identifier, and additional details, e. g. whether parts of the work should be done by a contractor.

If you outsourced the project to a contractor, the scope baseline would contain the agreed-upon deliverables and goals. It would be the basis for the contract. You would measure a contractor’s performance against this scope baseline (as well as against the cost and schedule baseline). If the contractor does not deliver the full scope, you would likely request rework and refer to the agreed scope baseline.

On the other hand, if you wish to add or change work partway in the project (e. g. getting new wallpapers instead of painting the walls), the contractor would reject this as ‘scope creep’ and insist on adhering to the change control processes – which would also assess the changes to the cost and/or schedule baselines.

Conclusion

A scope baseline sets out the approved deliverables of a project as well as the work that needs to be performed to create them. The scope baseline becomes part of the performance measurement baseline against which the project performance is measured.

In practice, scope discussions and scope creep are not uncommon partway in a project (unfortunately). Many projects fail because business goals and scope are not entirely clear or properly implemented (source).

Getting the scope baseline right is good project management practice and a first step to successfully and efficiently accomplishing the project goals.