Project Scope is simple in concept; but hard in practice. It is a measure of the breadth and depth of your project. Put another way, it is everything you need to do.
We call the process of defining the scope of your project, ‘scoping your project’.
Come to think of it, scoping your project isn’t just hard; it’s the hardest part of project management. After all, it’s at this part of your project management that you have to reconcile all of the different needs and desires of a wide range of stakeholders, of varying influence, importance, and attitude.
And, you need to do that within constraints on your time, budget, and resources. Scoping is fundamentally an exercise in negotiation.
But here’s the thing. If you get your project scope wrong at the outset, you will end up with the wrong outcomes. Not only that, but you will also have angry, upset, and frustrated stakeholders. And no one wants that!
This is a short article, but we’ll be covering a lot:
Before we go too much further, let’s start by defining our terms. Scoping is the process of defining your Project Scope; the extent of what your project aspires to achieve. You can think of this as the length and breadth of your ambitions.
By ‘your’, by the way, I mean the settled ambitions of the project’s ultimate decision-makers. The project scope determines all of the work that the project team will need to do – the ‘scope of work’ – and all of the things that the project will produce – the ‘products’ or ‘deliverables’.
In the US, project managers most frequently think of project scope in terms of products (and they more often use the term products, rather than deliverables, which is the preferred term in the UK).
The PMI defines Scope as:
Scope: The sum of the products, services, and results to be provided as a project.
Project Scope: The work performed to deliver a product, service, or result with the specified features and functions.A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th Edition
The Project Management Institute
In the UK, project managers tend to think of scope as relating to the work to be done; the tasks, or activities.
The APM defines Scope as:
Scope: The totality of the outputs, outcomes and benefits and the work required to produce them.APM Body of Knowledge, 7th Edition
The Association for Project management
Each of these approaches is equally valid, as long as you use it consistently throughout your project. The difficulty comes if you mix the two up on one project. There is not a one-to-one relationship between the activities and the products of a project. Some activities can lead to multiple products. Some products are the result of a whole series of activities. Choose the approach that suits you (or fits the standards used in your organization) and stick to it throughout your project.
Think about three stakeholders (and a project with just three would be a pretty easy one!)
Each stakeholder wants a different set of capabilities and standards from your project. And for each stakeholder, there are:
Also, each stakeholder has:
And you, as the Project Manager, need to reconcile all of their needs and wants, to create the optimum package of what you will produce – and what you will not.
But it is harder still. Because, to deliver this scope, you will need resources.
To make it simple, let’s focus on the money that will pay for them. Each stakeholder will have a different idea of the ultimate value of your project and how much they want to see invested in it. You not only have to find the optimum scope for your project from among conflicting wishes: you must also reconcile that scope to the resources you are going to get.
More resources will allow you more flexibility on scope, but what if one stakeholder says this?
‘you can have this extra money… as long as you deliver this piece of functionality.’
Yet the other stakeholders have that capability so far down their list of requirements that they are not prepared to accept it.
There are a number of tools you can use to help you define your project scope. Let’s look at four of them. The:
This comes in a lot of flavors, but all amount to the same thing. I like to draw three zones on a chart and facilitate a discussion.
Now we need to evaluate the resources remaining, once we commit to the project scope items in the Yes box. Having done that, we can discuss each of the maybe items in that context. So, which project scope items:
Determining your Project Scope is largely an exercise in horse-trading among stakeholders.
Work Breakdown Structures are a fundamental project planning tool – and far too important to tackle as an aside to a separate article. We look at them in the article:The Easy Way to Create a WBS with a Mind MapAnd we also consider them in the shorter article:Are You a Top-down or a Bottom-up Person?
But here, I want to note that the WBS is, at least in part, a project scoping tool. The lowest (most-detailed) level of your WBS is a full articulation of your Project Scope. And this is true, whether you are breaking down the activities to be done (as in the UK) or the products to be delivered (as in the US – called a Product Breakdown Structure in the UK).
The process of creating your WBS helps impose order and structure on your scope definition, and also helps to ensure that it is complete, and without duplication. This is sometimes known as:
The Kano model is a feature prioritization model that helps you prioritize features or scope during the Definition Stage of your project. And you can also use it for creating a Product Roadmap in an Agile project.
We use the Kano Model to identify which features to build – especially when you have time, budget, or resource limitations. We ask:
These questions help us to determine whether you should add them to a product backlog or roadmap.
There are 3 Features to include on your plan:
There are 2 Features to eliminate from your plan:
The final tool I want to highlight to help you define your project scope is a simple prioritization tool, called ‘Moscow Analysis’.
The obvious three answers, as we saw above, are yes, no and maybe. Moscow analysis takes this one step further, and separates the maybes into a strong maybe: maybe yes, and a weak maybe: maybe no. This gives you four categories.
These are scope items that stakeholders widely agree we must achieve, if the project is to succeed at all. They tend to be core capabilities that tie closely to the project’s goals. There is little or no point in undertaking the project if it does not achieve its musts. You will need to fight hard to find the resources you will need, to deliver all of these. These are the threshold attributes of the Kano model.
These scope items deliver substantial additional value that suggests they are a wise investment if the resources are available to your project. They are your first priority for any additional resources. And, when you have delivered your ‘Musts’, you can try to use the success to generate additional funding. You will use your ‘Shoulds’ to make the case for the extra funds, and allocate them to your ‘Shoulds’ first.
These are the elements of capability that would be a nice to have and valuable addition. But that value is marginal at best and you would only consider adding these scope items to your project if:
Sometimes known as ‘Woulds’. These are the scope items that you would deliver if you could, but you won’t because you cannot justify them. Not only is their value marginal, but there is a good chance that their cost or risk will outweigh that value. These often amount to polishing up small details that one or two stakeholders are surprisingly eager to see. But others recognize them as a waste of effort at best, and a dangerous distraction at worst.
In simple terms, The Pareto Principle states that you get most of the value from your project from a ‘vital few’ elements of capability. Therefore, many additional small capability elements deliver little amounts of incremental value. At the same time, these extras often have costs and risks that are disproportionate to the value they add.
Consequently, your Project Scope should conform to the Pareto Principle. Firstly, limit your scope to the few things that deliver maximum value. And secondly, you should avoid the long tail of lots of little extras, none of which offer much additional benefit, but which do each add cost, complexity and risk.
Here is a typical Pareto curve:
Once you get your head around this, it is easy to see how our four Moscow Categories can map onto the Pareto curve. The percentage figures in the chart are illustrative only. What matters is the principle of what the curve tells you about what you should and should not include in your project scope.
So, don’t take the numerical values seriously: they are indicative only. What is important is the general pattern:
For many project managers, the Moscow categories act as a useful mental model for helping them in discussions and negotiations. If you can discern where a stakeholder would fit a desired capability within the framework, you will be better able to sense what to concede and what to negotiate hard about.
I favor having a fifth board; label it ‘Will’. At one end, have a grid of 100 boxes to represent 100 per cent of your maximum confirmed project budget. Once the group agrees a must will be part of the project, move it to the Will board, and tick off as many boxes as represent the estimated incremental cost of delivering that capability. You’ll soon see minds focus, as fewer and fewer boxes remain!
Defining your Project Scope is the toughest part of project management. But when you get it right, you will have the soundest of all platforms on which to build your plans. To get it right, you need to settle on a set of core products, capabilities or functionalities that you will deliver. These must be ones that all your stakeholders can a agree are a fair balance among their differing needs. You also have a mechanism to go back and negotiate additional features, if time, resources or budgets expand. There is no single most important skill in project management, but if I were to get into one of those artificial arguments over this, I think it’s scoping I’d choose.
Scoping is just one of many activities that contribute to a robust project definition. So you may like to take a look at our Project Manager’s Project Definition Kit – an innovative course and resource kit, so you can take a jumble of ideas, needs, and requests and turn it into a well-defined project.
You may also like this article: The Key Components of Your Project Definition.
Take a look at our article, Scope Management Plan: Everything You Need to Know.
And, to help you with controlling your scope…
Please do share your thoughts about the scoping process below and, as always, I’ll respond to every comment.
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.
Introduction to the PMP Certification (Project Management Professional) with Cornelius Fichtner
What are Assurance and Audit in Project Management? Your Awesome Guide
Robust Project Definition: How to Build it and the Components you Need
I Don’t Like You – Trust and how to Deal with the Toughest Form of Resistance
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.