Why is it Hard to Define Your Scope?
Zohar Strinka
Consultant: Solving the Meta-Problem | Facilitator and Educator in Data and Supply Chain | Data Analytics, Inventory, Lean Warehouse, Process Improvement
Let’s set the scene. You work hard as a team to define exactly what problem to go out and solve. At the end of the process you get to some sort of consensus. Sure, not everything is included, but everyone generally agrees on what problem we have chosen to solve and what to expect to do along the way. Unfortunately, as soon as the project actually begins, new requirements appear and the team fights about what to include in “The Project.†Depending on your point of view, this can seem like the most natural thing in the world, or the dreaded scope creep you seek to avoid as much as possible. In this post I will be explaining why both perspectives are valid, and how you can at least be more aware of the root causes next time it happens to you.
Take yourself to that period where the team is deciding on the project’s scope and think about a second related but separate project. What makes the two separate? Said another way, why do projects need to have a scope to begin with? If we were to take all the individual projects a group is working on and make them one mega-project, what would change?
The reason we need to have a scope for a project comes down to the practical reality of what it takes to get things done. If you try to do everything, there is a decent chance instead you will do nothing. And so, we intend for each project to be a manageable subset of everything. You want to fix an issue? Great, figure out the minimum set of things to change or fix just for that issue. Now we have our scope.
There are two ways this goes wrong. The first is more or less unavoidable. You thought the scope included everything necessary to fix the issue, but some things were left out. If those gaps are a deal breaker, we change the scope to incorporate the more educated understanding of “minimum.†The only way to get out of this kind of scope creep is to change the problem. In which case the scope either shrinks or goes to zero when we realize the problem is harder to solve than we originally thought and no longer worth it.
The other way scope creep appears is when that manageable subset of everything seems like it would still be perfectly manageable if we added just a few extra requirements. Sure, the project got bigger, but individually each new requirement seems worth the additional investment. And honestly, it can be. But every time you make your “manageable subset of everything†bigger (your scope) there is a greater and greater risk that it will no longer be manageable. To avoid this kind of scope creep you need to keep the overall system in mind.
To answer the question in the title: The reason it is hard to define your scope is that it will always be a piece of “everything we could do.†In so many ways it is arbitrary. And yet, defining scope well is key to delivering any results at all.
One thing that makes defining scope hard is that if it is an unexamined problem, the client really does not know what they don't know, so the first part of the project is discovery. Then when you have had to deal with the world as it is (the actual system or the data that comes from it), you can have much better conversations on what the client needs (what are the options available and what do they need to know to choose between them). Back when I was in academia, I ran our department capstone course, which had industry sponsored clients. While they all had initial problem statements, we used the first month to do discovery and write new problem statements, and for all successful projects, they were different than the original statement. (partly because of this issue, and partly because of the need to have a scope they could finish by the end of the semester.)