OnlinePMCourses
Please Share

Project Scope: What you need to Know

How to Define Your Project Scope

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

Scoping your Project is Hard

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

What is Scoping?

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: 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). In the UK, project managers tend to think of scope as relating to the work to be done; the tasks or activities.

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 organisation) and stick to it throughout your project.

Why is Defining your Project Scope so Difficult?

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 things that they need, things that they want a lot, and things that they would quite like. Also, each stakeholder has different levels of influence, different authority within the organisation, and different attitudes to your project. 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 won’t.

But it is harder still, because to deliver this scope you will need resources. Put simply, 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 ‘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.

Are you starting to see why defining your Project Scope is so difficult?

How to Define Your Project Scope

How to Define Your Project Scope

What Tools will Help You Define Your Project Scope?

There are a number of tools you can use to help you define your project scope. Let’s look at three of them:

The Simplest Tool: The Yes-No-Maybe Approach

This comes in a lot of flavours, but all amount to the same thing. I like to draw three zones on a chart and facilitate a discussion. Some items of project scope are definitely needed. They go in the Yes box. Others candidates are definitely not going to be in scope. hey are not valuable enough, or they are too costly, or the risk is too high. Or, quite simply, there is not enough weight of stakeholder support. These go in the No box. Park the remainder into the Maybe box for further 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:

  • Can we achieve with the available resources?
  • Offer the best complement to the already-agreed yes items?
  • Achieve the best balance of benefit against cost or risk?
  • Will meet the needs of the largest stakeholder group?

Determining your Project Scope is largely an exercise in horse-trading among stakeholders.

The Most Thorough Tool: The Work Breakdown Structure (WBS)

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 Map, and 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. 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 MECE: Mutually Exclusive, and Completely Exhaustive.

The Best Negotiation and Decision Support Tool: Moscow Analysis

The third tool I want to highlight to help you define your project scope is a simple prioritisation tool, called ‘Moscow Analysis’.

Start by thinking about a single capability; is it in scope?

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.

Musts

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.

Shoulds

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.

Coulds

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:

  1. You have a high level of confidence that you can deliver your ‘Musts’ and ‘Shoulds’ to the specified standards, and
  2. You have surplus funding and resources that you will not need elsewhere.

Won’ts

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 recognise them as a waste of effort at best, and a dangerous distraction at worst.

Think of Moscow Analysis as linked to the Pareto Principle

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:

The Pareto Principle. Your Project Scope needs to conform to this.

The Pareto Principle

 

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.

 

How MoSCoW Analysis helps your Project Scope to conform to the Pareto Principle

How MoSCoW Analysis helps your Project Scope to conform to the Pareto Principle

 

So, don’t take the numerical values seriously: they are indicative only. What is important is the general pattern: the Musts occupy a small amount of the investment that gives a large return of value. The Won’ts, at the other end of the curve, are the large number of possible extras that are costly, risky, and yet potentially of only small incremntal value. What defines the boundary between the ‘Coulds’ and the ‘Won’ts’ is that your overall estimate of the cost and risk is greater than the value you estimate for delivering them.

How to Carry out Moscow Analysis

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. But when negotiations get really tricky, it is often best to get your stakeholders in one room.

Put up four boards – whiteboards or posters – labelled: Must, Should, Could, Won’t. Ask your stakeholders to agree what clearly goes into the ‘Must’ category. Then try to get some consensus about the ‘Won’ts’. Finally, look at how remaining objectives fit into the ‘Should’ or ‘Could’ categories. Now start the negotiations about what balance of capabilities will best match the resources available, and the priorities expressed.

I favour 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!

The ’so what?’

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.

Creating a Robust Project Definition

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.

About the Author Mike Clayton

Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 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.

follow me on:
>
Malcare WordPress Security