Scope Management Plan: Everything You Need to Know

I’ve often said that scoping is the hardest part of Project Management. So for a formal project, you’ll need a good Scope Management Plan. It will help you navigate the scoping process, and take full advantage of all of your hard work.

But a Scope Management Plan is a tiny part of Project Management. In the 6th edition of the PMI’s Project Management Body of Knowledge (PMBOK Guide), it is one of two outputs of one of six processes of one of 10 Knowledge Areas. So why, you ask, did I choose this topic for one of our giant guides?

Therein lies a story.

The Contents of the Article

In this article, we’ll cover:

• Why a Scope Management Plan is Important
• What is a Scope Management Plan?
• How to Develop your Scope Management Plan
• The Contents of a Good Scope Management Plan

Why a Scope Management Plan is Important

Getting your scope wrong at the outset will set your project up to fail. And another common source of failure is an inability to control your scope, leading to scope creep and over-runs in both schedule and budget. And, if you fail to properly validate your products before handing them over to their new beneficial owner, you’ll be storing up a whole world of trouble.

Your scope management plan will set out the processes and procedures that will protect you from all these failings.

For More about the Reasons for Project Failure…

By the way – for more about the many reasons for project failure, I recommend our feature articles:

• Project Failure – Why it Happens
• Why Projects Fail – Five more reasons

We’ve compiled these into an audio-visual course, too.

What Spurred me to Write this Article?

If that is not enough, one specific question and series of Q&As spurred me to write this article. Currently, the most-viewed video (c.70k views) in my ‘PM Dictionary: What is…‘ series is: What is Project Scope?

Here is is…

This video spurred the following question from a viewer:

What is the difference between scope management plan and project management plan?

In other words which comes first scope management plan or project management plan?

I want to use this article to expand on the answers I gave.

If you are interested, I have documented the three questions and answers at the bottom of this article.

What is a Scope Management Plan?

Here’s my answer:

A Scope Management Plan is a plan for how you will:

• Determine and document the scope of your project
• Validate that you deliver your  activities and products to their specification
• Monitor and control your scope to ensure changes to your scope:
  • meet changing needs,
  • get an accountable sign-off, and
  • are implemented properly

Let’s put the Scope Management Plan in context. We’ll look at it from two perspectives. In the context of:

1. Your Project Management Plan
2. The PMBOK Guide’s Wider Project Scope Management Knowledge Area

The Relationship with a Project Management Plan

At its simplest, your Scope Management Plan will be part of your wider Project Management Plan. So, for a smaller project, it may be a section in a larger document. But, for a large project, it may be one of a whole suite of interconnected documents.

This is a schematic version of how the PMI represents it in the 6th Edition of its Project Management Body of Knowledge (PMBOK Guide).

Planning and Scoping are Iterative Processes

Elements of the emerging Project Management Plan are inputs into your Plan Scope Management process, and your Scope Management Plan is an input into your Project Management Plan. That can sound worryingly circular. But, like the Ouroboros, that is exactly as it should be.

Planning your project, and how you will deliver and control it, is a process of:

• making assumptions
• creating a draft
• revising assumptions
• creating a revised draft
• …until you are ready to get approval
• them keeping your plan under review and in version control

Regarding the relationship between your Project Scope and other aspects of your project plan, the essential thing you are looking for is consistency. Each part must be consistent with the others.

The Relationship with Project Scope Management

Your Scope Management Plan is part of the wider Project Scope Management master process, which the PMBOK Guide divides into six component processes, which can be illustrated like this…

Whether you are learning for your CAPM or PMP, or developing a pragmatic approach to planning this month’s new project, your approach to scope management will look something like the diagram:

1. You need a plan, process, or operating model for handling scope
2. You need to gather requirements…
3. and use them to determine the scope of work and range of deliverables
   – for which a Work Breakdown Structure (WBS) is the best tool
4. You need a means to assure that deliverables meet their specifications
5. And finally, so need to be in control of changes to scope

How to Develop your Scope Management Plan

First, just to be clear, developing your Scope Management Plan is not the same as defining the scope of your project. You can learn more about that in our long article: ‘Project Scope: What you need to Know’.

Integration with your Project Management Plan

Your first big decision is how to integrate with your Project Management Plan.

At one end of a spectrum of possibilities is a wholly free-standing Scope Management Plan. This must be consistent with your Project Management Plan, but can exist as a separate document, and repeat anything that overlaps.

The other end of the spectrum is to include scope management within your Project Management Plan. This is my general preference.

Either way, any work you have already done on your Project Management Plan will be an input into developing your Scope Management Plan. Particular examples of overlaps and interfaces include:

• Benefits Management
• Configuration Management
• Quality Management
• Development approach for technology and New Product Development (NPD) projects

Other Inputs into Developing Your Scope Management Plan

You will also need to take account of:

• Project set-up documents like your project charter, mandate, or initiation document
  (A note for PRINCE2 Practitioners. I am using that term generically here, not to mean the Project Initiation Document, or PID)
• Organizational policies, procedures, and culture
• Practices in other projects – especially if you are part of a wider program
• Guidance from your PMO (Project/Program/Portfolio Management Office)

What will You Include in Your Scope Management Plan?

In the next major section, we’ll discuss the contents list for a scope management plan. But you’ll need to draw down, from the long-list of possible components, those that you need for your project.

Determine How Your Processes will Work

The heavy lifting is figuring out how you will manage your scope:

• How will you gather requirements, and turn them into scope?
• What will your scope statement and baseline look like? How will you articulate them, what tools will you use?
• Which standards will your products need to conform to?
• What will be your process for validating deliverables against those standards?
• How will you control change? And what governance will you set over your change control process?

Who Needs to be Involved in Developing and Maintaining Your Scope Management Plan?

This is a process you (the Project Manager) will lead. But you will also want to involve your project team. Also consider involving key stakeholders – especially when you are determining your validation, acceptance, and change control procedures.

You will also need involvement from your sponsor and the governance tiers of your project. If you are subject to a Stage Gate Process/Gateway Review, for example, a satisfactory Scope Management Plan may be a necessary criterion for passing the review. Likewise, your Project Board or Steering Group may need to sign-off on your plan.

The Contents of a Good Scope Management Plan

This last section articulates a long list of possible sections for your Scope Management Plan. You will rarely need all of these. And some you will want to combine into fewer sections.

Introduction

Use your introduction to set the context for the project and place the governance of scope management within it. Also document how your scope management plan relates to other documents.

Definition Process

This section is central and must address two components:

1. How you will define scope
   The definition itself will come later in your plan.
2. How you will arrive at your scope definition
   You may want to document the tools and techniques you will use, such as:
   1. Expert judgment
   2. Analysis of data and reports
   3. Observation
   4. Benchmark comparisons
   5. Facilitated workshops

You will also want to refer back to the inputs that have informed your thinking.

Interfaces with other areas of your Project Management Plan

This section will refer outwards to other documents, like your Project Management Plan, which contain related information. Equally, it may highlight plans that you have chosen to include within your Scope Management Plan, which other project processes will call upon. These include sections we’ve included below, like:

• Configuration management plan
• Benefits management plan

Budget and Resourcing for Scope Management

Usually, the cost of scope management is part of the wider cost of project management. Certainly this is not the place to document the entire project budget. But if you anticipate particular costs for scoping activities, do document them. Examples include:

• Feasibility studies
• Prototyping and testing
• Travel costs for a Change Control or Design Authority group

Stakeholders

In this section, you would document those stakeholders who will have a particular influence over scoping or scope change decisions. You may choose simply to identify them here and refer your analysis and planning to your Stakeholder Engagement Management Plan. Or you may create a Scoping Stakeholder Engagement Plan here.

Requirements and Requirements Management

Often the scoping process will follow a requirements identification step. So, here, you will document the outcome of requirements gathering, and how you plan to keep that under change control.

During requirements identification, you will find out what your stakeholders need. You’ll do this with a combination of one-to-one and one-to-many meetings, and using remote communication and survey tools. Most projects have a large number of requirements originating from a wide group of stakeholders, so it is valuable to find a way to measure the priority or each requirement, to each stakeholder. A good question to ask is ‘so what?’ Find out the consequences of meeting or failing to meet the requirement.

Scope Statement 

Let’s cover off one thing first of all. PMBOK Guide (6th Edition, Chapter 5, Key Concepts for Project Scope Management section), clearly states;

Project Scope. The work performed to deliver a product, service, or result with the specified features and functions.

The highlighting of work is mine, not PMI’s. So, ‘scope’ is work. Except the PMBOK Guide equally clearly states:

In the context of the WBS, work refers to work products or deliverables that are the result of activity and not the activity itself.

Again, my highlights, not PMI’s. So, scope appears confused. It is my experience (but I cannot say for sure if it is generally true) that:

• In the UK, project managers treat scope as referring to the work, and a Work Breakdown Structure breaks down the work (tasks)
• In the US, project managers treat scope as referring to the products, and a Work Breakdown Structure breaks down the products (things). Here in the UK, we’d call that a Product Breakdown Structure (PBS)

What to include…

However, whichever approach you take, choose one and avoid mixing terms. For either, you’ll want:

• Product Scope Description
  A narrative statement what the project will accomplish
• Product Acceptance Criteria
  Setting out the requirements or standards work or products must meet
• Project Deliverables
  A list of deliverables the project will produce
  I’ve allowed that in the UK and other countries, this may be in a separate section
• Scope Exclusions
  Description of out-of-scope work that is not included in the project

You may also want to include:

• Assumptions that you are working to, and need to validate
• Constraints that limit your choices about how you will approach the project. Examples include budget and resource limitations (such as availability of assets, equipment, or materials)
• External Dependencies – factors that will influence your choices.

Your scope statement is a central part of your project definition. It establishes and documents your stakeholders’ expectations. Accordingly, if you get it right, it will reduce the risk of scope changes during your project.

Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) is your primary tool for effective management and will be part of your Scope Management Plan. Once you have built it, you have the platform for your project:

• Budget
• Schedule
• Resource plan
• Risk identification

This may often be combined with…

WBS Dictionary

A WBS Dictionary supports your Work Breakdown Structure by listing the following things for each work item:

1. Unique Identification number
2. Description of work (or product)
3. Responsible organization or individual

To build your project plan, you can start to add more information. For example, other items might include:

• start date
• duration
• predecessor activities
• deadline
• budget
• resources required

Your Scope Statement and WBS may often cover the project’s…

Deliverables/Products

A deliverable or Product can be something material, that you can touch and see. But it can also be something you can experience, like a training course, and event, or a process improvement. These are the things that your sponsoring organization has commissioned you to produce. So you need to include them in your Scope Management Plan, along with the specifications and standards they must meet.

Information Management and Version Control

Use this section to discuss how you will manage the scope information. Perhaps you’ll include product specification templates, for example. You’ll also need version control procedures for all project documentation – including your scope management plan!.

Scope Validation/Assurance Approach

Scope validation is one of the six Scope Management process is the PMBOK Guide. Set out how you will verify that your deliverables meet your original scope and specifications.

Your client or sponsor should also formally accept and sign-off your deliverables, so this may often be combined with…

Stakeholder and Sponsor Acceptance

A deliverable is not finished until the new beneficial owner (project sponsor, client, operational manager, etc.) has formally accepted it. This may not mean they have received the deliverable: only that they approve it for delivery.

You may also have a scope acceptance stage where he new beneficial owner approves the scope statement and specification-set. This means that, as long as products meet their validation criteria, subsequent acceptance is automatic.

Scope Monitor and Control Approach

This covers:

1. Monitoring the status of the project scope of the project
2. Controlling changes to the scope baseline

We cover how to handle change requests in our article: OnlinePMCourses Guide to Project Change Control.

Roles and Responsibilities

Here, you’ll document who has authority and responsibility for scope management. It will usually be your responsibility (the Project Manager). However, there will also be roles for The Project Sponsor, team members, and Stakeholders.

You can also cover off governance arrangements here – particularly if you do not do so in the section on Change Control. This reminds me of one particular role or set of roles: that of Change Controller, and any team she or he may have.

Team leads and team members will each have a role to play, because each part of the scope will sit within a workstream and therefore be the responsibility of a part of the overall project team.

I recommend you tabulate names, roles, and responsibilities as the example below. Or you could use a RACI Chart or Linear Responsibility Chart.

Configuration Management

This may well call upon a part of your Project Management Plan. In a more complex project or program, the inter-relationships between products, outcomes, and benefits is as important as the specifications of each. So you will need a process and plan to manage these configurations.

Benefits Management

This may well call upon a part of your Project Management Plan. We do projects to achieve benefits. And the benefits management plan is the means by which you will set up a process to ensure you deliver those benefits.

What is Your Experience of Scope Management Plans?

Let us know in the comments below if you have any thoughts or questions arising from this article. We’ll respond to every comment.

[thrive_text_block color=”blue” headline=”Original Questions and Answers”]

[thrive_toggles_group”][thrive_toggles title=”Q1: Scope Management Plan vs Project Management Plan” no=”1/3″]

Question:

What is the difference between scope management plan and project management plan?

In other words which comes first scope management plan or project management plan?

My Answer:

A Project Management Plan is a bigger thing – I covers every aspect of the project: scope, schedule, resources, budget, quality, H&S… Your Scope Management Plan is one component of this. It sets out: the initial statement of scope, and how you intend to handle changes in scope, as well as monitor and sign-off delivery.

Which comes first? It’s the chicken. No, it’s the egg.

Seriously, project planning is an iterative process, where aspects are refined and that triggers us to review other aspects that we already have a provisional statement on. Our goal is full self-consistency.

That said, defining scope is an early stage activity. At definition stage, we define the Goal, Objectives and Scope. We then refine the scope during planning stage, making it more precise. Take a look at the videos on Project Hierarchy and What is MoSCoW Analysis? We use MOSCOW Analysis to help define scope at the outset.

[/thrive_toggles][thrive_toggles title=”Q2: Why is the project management plan an input for the scope management plan?” no=”2/3″]

Question:

Thank you so much for quick reply, but you assume we pass the begining of planning process and the startup phase and I assume we still at the beginning.

So, how come the project management plan popped as an input for scope management plan? I imagine it like, we still at the startup of planning and we don’t have any project management plan up to this point, and we still on our way to define scope to build on, So from where we got project mangement plan to put it as an input for scope mangement plan.

* According to PMBOK

4.2.3.1 Project Management Plan

The project management plan is the document that describes how the project will be executed, monitored, and

controlled. It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.

My Answer

I think the answer lies in the iterative nature of planning. From the earliest stages we start to develop our project plan, and develop our scoping statement and Scope Management Plan in parallel. Each feeds into the other.

I hope the PMI won’t be upset if I say that I find the distinction between the two as a little artificial. In the real world they are often parts of the same document.

[/thrive_toggles][thrive_toggles title=”Q3: Do we plan in parallel way or in a rolling wave way?” no=”3/3″]

Question:

Thank you so much again for your interest and your quick reply,

But friendly speaking, I’m still confused !!

Regardless of the iterative nature of planning, do we plan in parallel way or in a rolling wave way?

For example can we define scope before collecting the requirements, could we have scope statement before or at the same time we get requirements documentations?

I think there is some planing could happen in parallel but others not and the master plan or the project management plan is a result and a collection of all planning processes,

This may bring us back to the question: what is the first step in building project management plan, Is it the scope definition or a group of planning processes happening in parallel? Here if the answer one of the two questions or both of them the project management plan still a result and an output and we can’t consider it as an input for one of its components in the early stage of planning before doing any reviewing or refining.

My Answer

You raise good questions and expose the complicated nature of the topic. There are different ways we do planning and different ways to do scoping and this format cannot do justice to your question.

So, I have added your question to the list of topics for my feature length articles at OnlinePMCourses.com. Sometime (but not immediately, because feature articles are thorough and planned in advance) I’ll write a 1,500-2,500 word answer*.

In the meantime, the following article may be too basic, but it may help you: https://onlinepmcourses.com/define-project-scope/

* It actually runs to 3,000.

[/thrive_toggles][/thrive_toggles_group][/thrive_text_block]