Scope – What it Is, and Isn’t
Last week I addressed the misunderstanding regarding the difference between Scope Creep and Scope Change. This week we’ll tackle a more fundamental issue – Scope itself.
There’re four primary misconceptions I commonly see re: scope –
- Scope is pre-determined, and fixed.
- Scope is a set of tasks
- Scope suggests we know everything that has to be done.
- Adaptive projects don’t have ‘scope’.
None of these are true.
As always let’s start with the basics – what is ‘scope’?
PMI defines scope as –
The sum of the products, services, and results to be provided as a project. See also Project Scope and Product Scope.
So let’s take a look at Project Scope and Product Scope –
Project Scope: the work performed to deliver a product, service, or result with the specified features and a functions.
Product Scope: the features and functions that characterize a product, service, or result.
[Note: I’m not suggesting PMI is the final arbiter of all things project management. But most ‘anti-pm’ discussions will eventually point back to PMI/PMBOK, so it makes sense to use their definitions here.]
So ‘Scope’ can be defined as “the sum of the work performed to deliver, *and* the features and functions that characterize the product, service, or result.”
Or another way – scope is “the things we have to do”, and *ALSO* “the things the result should do”.
So let’s look back at our misconceptions:
# Misconception 1: Scope is predetermined, and fixed.
Let’s start with the idea of ‘fixed’ first.
Very little in project management (or products) is ever ‘fixed’. Needs change, features change, schedules change, costs change, even the approach may change during the life of the project/product. The degree to which things change, or are allowed to change is a function of the project/product itself, the leadership of that project/product, and the impact of those changes. Tearing out concrete to change the layout of a building is far more problematic than rolling back code because an upgrade didn’t work.
But the word and idea of scope in and of itself doesn’t mean ‘fixed’.
What about “Scope is pre-determined”?
The definitions of scope above don’t suggest ‘when’ scope is defined or identified. These definitions apply equally whether you’re describing scope before, during, or after the work/project/product is complete. This *wiil be* the work/features we’re going to do (this is what we think the scope will be), this *is* the work/features we’re currently working on (this is our current scope), these *were* the work/features we did (that was the scope of our product/project).
# Misconception 2: Scope is a set of tasks.
Given the definition, this one falls flat immediately. Scope is the ‘work to be done’, which could be interpreted as ‘tasks’, but also the features and functions, which aren’t ‘tasks’.
And I think this is the perhaps the biggest misconception/misunderstanding.
Scope is both a *prescriptive*, and a *descriptive* term.
Going back to the definitions, scope describes both ‘what to do/was done’ (the work), but also what it’s ‘supposed to do/does’ (features and functions).
And this is where most of the misunderstanding comes from – Scope is both – the ‘how’ and the ‘what’.
If you want to build a house, the scope will be the work necessary to build the house, and the features you want in that house. If you build software, the scope is the desired features, functions, and capabilities, and the work necessary to develop those.
Sometimes ‘scope’ just describes one side of the equation, the side you know ‘at the moment’.
So even if you just ask a question, or are given a problem to solve, those have scope. You may not know what to do (tasks), but you still have a scope – things necessary to answer the question, or solve the problem.
# Misconception 3: Scope suggests we know everything that has to be done.
This is probably one of the bigger ones.
Another one of the reasons there’s so much confusion is that many try to apply a ‘level of knowledge’ to scope, i.e. ‘scope’ suggests we know ‘everything that has to be done’. This simply isn’t true (and doesn’t line up with the definitions).
Scope exists in *every* undertaking, just at different levels of granularity and knowledge. As soon as you have an idea to do something, *that’s the scope*. It may not be well-defined, but there is now a ‘scope’ to your idea (this thing is part of my idea, this other thing isn’t). As soon as you have one feature in your backlog, *that’s your scope*. Your scope will obviously grow and change, but having an idea of the work and features necessary is ‘scope’. As soon as you have a problem to solve, that’s your scope – the work and features necessary to solve the problem. You may not know what they are yet, but It’s the work to be done, and the features/capabilities necessary to solve the problem.
When Elon Musk says he wants to colonize Mars, he’s just given you the ‘scope’ of his dream.
He didn’t provide a list of tasks, or suggest he even knows how to do it yet. But he’s described the ‘scope’. Things having to do with colonizing Mars are ‘in scope’. Things having to do with colonizing the Moon would then be ‘out’ of scope.
Scope in its descriptive form provides direction, and focus.
But let’s take this a step further. No, we can’t know everything we have do. Nor does the idea of scope suggest we can.
This is why the idea of scope doesn’t exist by itself.
Scope has a few friends – Assumptions, Risk Management, and Change Control.
And this is true in both predictive and adaptive approaches. We don’t know everything that has to de done, but we can make some assumptions about things we might have to do, a place where we might want to start, or some conditions we may encounter. We can identify some things that may cause us problems, and we can address how to handle changes to the previously expected scope and assumptions via change control. How these are handled differ based on the approach (predictive or adaptive), but they all still exist as a group, even within an iterative or incremental approach.
# Misconception 4: Adaptive projects don’t have ‘scope’.
Again, this misunderstands what scope is. As noted above, every undertaking has ‘scope’.
If you’re given a problem to solve, but no direction how to solve it, you still have ‘scope’ – solving the problem. So you look a the things you are doing, and the things you could do, and you ask ‘are these within the scope of my problem?’.
Even something as simple as grocery shopping has ‘scope’. You have the work of shopping itself, and the features, the food on your list to get. And if you’re like most, you’ll buy something not on your list, so even in this silly example scope isn’t ‘fixed’.
Musk’s goal of colonizing Mars will require an adaptive approach (since he doesn’t know how it will be done yet), but the scope still exists – things necessary to colonize Mars. And it could end up that ‘colonize the Moon’ becomes a necessary intermediate step.
So then we would have ‘scope change’ with the original overall scope, based on adaptive learning.
The idea of scope isn’t a ‘fixed list of tasks’, some ‘unchangeable construct’, the ‘totality of things to be done’, or even applicable to only certain types of projects or products. Scope is the understanding of what we’re trying to accomplish. It’s both the idea of what we’re doing, and where possible, the things we need to do to get there. And as with all aspects of project/product management, it’s begins broad and vague (in most cases) and becomes more defined and clear the closer we get to the ‘thing’ we’re trying to do.
*Originally published on LinkedIn