Establish Project Scope: How to Master Your Toughest PM Challenge

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.

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!

Our Agenda

This is a short article, but we’ll be covering a lot:

• What is Scoping?
• Why is Defining your Project Scope so Difficult?
• What Tools will Help You Define Your Project Scope?
• The ‘So What?’

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

How Project Scope Differs between the US and the UK

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.

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 organization,
• 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 will not.

Resourcing

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.

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

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 four of them. The:

1. Simplest Scoping Tool: The Yes-No-Maybe Approach
2. Most Thorough Scoping Tool: The Work Breakdown Structure (WBS)
3. Most User-focused Scoping Tool: Kano Analysis
4. Best Negotiation and Decision Support Tool: Moscow Analysis

The Simplest Scoping Tool: The Yes-No-Maybe Approach

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.

1. Yes
   Some items of project scope are definitely needed. They go in the Yes box.
2. No
   Other candidates are definitely not going to be in scope. They 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.
3. Maybe
   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 Scoping 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 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:

• MECE:
  • Mutually Exclusive, and
  • Completely Exhaustive.

The Most User-focused Scoping Tool: Kano Analysis

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:

• What do we need,
• What will make the product excellent,
• and what will excite our users or customers?

These questions help us to determine whether you should add them to a product backlog or roadmap.

How the Kano Model Works

1. Identify potential features you want to prioritize
2. Assess the potential of each feature to satisfy your users against the cost of implementation (This is akin to creating a mini Business Case)
3. Decide which of Kano’s five categories each feature sits in
4. Consult your users and customers about these features

The Kano Model’s 5 Categories of Customer Satisfaction

There are 3 Features to include on your plan:

1. Threshold Attributes
   Or Basic Features. These are what your users or customers expect and would take for granted – the ‘Musts’
2. Performance Attributes
   Or Satisfiers. These offer an increase in user or customer satisfaction that is proportionate to your investment
3. Excitement Attributes
   Or Delighters. These offer a disproportionate increase in user or customer delight compared to your investment. They are Wow Factors that creates fans out of your users.

There are 2 Features to eliminate from your plan:

• Indifferent features
  These are features that users or customers don’t care about – ne way or the other.
• Dissatisfaction features
  Worse still, these features are ones that your users or customers actively dislike.

The Best Negotiation and Decision Support Tool: Moscow Analysis

The final tool I want to highlight to help you define your project scope is a simple prioritization 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. These are the threshold attributes of the Kano model.

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 recognize 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:

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:

• Musts occupy a small amount of the investment that gives a large return of value.
• 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 incremental 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.

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

Will…

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!

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.

You may also like this article: The Key Components of Your Project Definition.

Beyond Scoping: Project Scope Management

Take a look at our article, Scope Management Plan: Everything You Need to Know.

And, to help you with controlling your scope…

What are Your Thoughts about Project Scope and the Scoping Process?

Please do share your thoughts about the scoping process below and, as always, I’ll respond to every comment.