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.
In this article, we’ll cover:
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.
By the way – for more about the many reasons for project failure, I recommend our feature articles:
We’ve compiled these into an audio-visual course, too.
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.
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:
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).
Staring with a comprehensive guide: Project Planning Process: Navigate the Many Steps You Need
And short videos that answer the question, ‘what is…
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:
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.
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:
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’.
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:
You will also need to take account of:
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.
The heavy lifting is figuring out how you will manage your scope:
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.
By the way – for more about project governance and working with your sponsor, I recommend:
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.
In summary, the sections we will cover are:
But, be clear…
I am not saying you will need all of these. However, you will need to select, from these, the sections that are right for your project’s scope management plan.
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.
This section is central and must address two components:
You will also want to refer back to the inputs that have informed your thinking.
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:
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:
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.
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.
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:
However, whichever approach you take, choose one and avoid mixing terms. For either, you’ll want:
You may also want to include:
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.
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:
This may often be combined with…
A WBS Dictionary supports your Work Breakdown Structure by listing the following things for each work item:
To build your project plan, you can start to add more information. For example, other items might include:
Your Scope Statement and WBS may often cover the project’s…
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.
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 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…
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.
This covers:
We cover how to handle change requests in our article: OnlinePMCourses Guide to Project Change Control.
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.
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.
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.
Let us know in the comments below if you have any thoughts or questions arising from this article. We’ll respond to every comment.
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?
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.
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.
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.
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.
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.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Scope Management Plan: Everything You Need to Know
PMBOK 7 Development Approach Performance Domain: Is it a Missed Opportunity?
Project Performance Domains: Do You Know What they Are and Why they Matter?
How to Create a Gantt Chart in 9 Easy Steps | Video
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.