Why is it Hard to Define Your Scope?

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. What is the root cause of this conflict?

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.