Title Project Scope Management

Scope Baseline: Definition | Example | 4-Step Guide | Uses

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

Scope baseline consists of the project scope statement, the work breakdown structure and the WBS dictionary
The items that are part of the project scope baseline.

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 hierarchy of a work breakdown structure (WBS).

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.

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.

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 the conference paper in PMI’s learning library 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.


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.