Why Scope Creep is Complete Bullshit

I have had it with the whole concept of scope creep. Scope creep is a negative label given to an inevitable and predictable experience that is a side effect of running projects using waterfall or traditional means. Adopting agile ways of working can eliminate the sources of scope creep and the managerial overhead that goes along with it.

This article provides some background on the term, dives into the details of what perceived scope creep represents, and provides a better approach. That approach requires a shift in thinking and will (hopefully) make you stop using the term Scope Creep.

My Own  Experience with Scope Creep

I began working as a project manager not long after joining IBM in 1985. Geez, I am old. Anyway, I took my first Project Management training course in 1993. Prior to that time, I found that the best way to combat changes in project scope was to use the Nancy Reagan approach – ‘Just Say No’. If someone wanted to change something about a project underway, I would say no or fight it to the best of my ability.

It was probably a good thing that I took that project management course. I learned to not say ‘No’, but to say ‘Yes And’. “Yes you can have that change, AND here is the impact on the timeline and budget. Do you want to proceed?”

You see as a project manager, my goal was to deliver the project On Time, On Budget and On Scope (OTOBOS). [Read my related article Project Success Rates, Going Beyond OTOBOS]. I knew that any changes would F things up and at a minimum, they would cause me to have more work.

The thinking that scope creep is negative remains prevalent today. Consider the articles How to Keep Scope Creep from Derailing Your Project or Top 5 Causes of Scope Creep and What to Do About Them. The abstract of that second article says “Scope creep is a dreaded thing that can happen on any project, wasting money, decreasing satisfaction, and causing the expected project value to not be met.” Clearly scope creep is a threat to you and your success.

Scope Creep Reflects Conflicting Goals

Scope creep will usually reflect the conflicting goals between the customer, the team, and the project manager or other stakeholders.

• In simple terms, the customer has the goal of getting the best solution for the best price. The traditional view of Scope Creep is that customers ask for something that is not in the original or agreed scope of work. It was called creep because sometimes the individual request was very small. It was the accumulation of many of these small requests that represents death by a thousand cuts. The scope “creeped”.
• The team usually has the goal of having realistic and achievable expectations for delivery against the plan. The team may cause scope creep by ignoring the agreed scope and building additional features (called gold-plating).
• The project manager is tasked with delivering on time, on budget and on scope. Their goal is to protect their plan, or making sure that changes to one part of the plan (scope, budget, and timeline) are reflected in other parts of their plan. They need to make sure that the team will deliver what the customer expects.

Traditional project management pits the customer, PM, and team against each other. Traditional projects are planned up front and the parties agree to what is essentially a contract for the scope, timeline, and budget.

This works great when building bridges, but it sucks for delivering complex technology solutions. It sucks when all the details and assumptions that go into that contract are likely to be wrong. It sucks when the time spent to thoroughly analyze all the requirements up front results in changes to those detailed requirements.

It sucks because the contract is made when the least amount of information is available about the requirements and delivery. Unless this project has been done before, the contract is based on the best guesses of everyone involved. That is it – best guesses. These best guesses become the contract.

PMI’s Approach is Bullshit

I guess I should be specific by saying that the PMI approach to scope management for technology projects is bullshit. It may be perfectly legitimate for building bridges, but it doesn’t work for technology.

Consider the PMBOK @ Guide definition of scope:

The work performed to deliver a product, service, or result with the specified features and functions. The term “project scope” is sometimes viewed as including product scope.

–Project Management Institute, Guide to the Project Management Body of Knowledge

And the PMBOK @ Guide definition of scope creep:

Scope Creep – The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

–Project Management Institute, Guide to the Project Management Body of Knowledge

I have an issue with the PMI definition of scope. The definition mentions the work and the product, service or result. These answer how and what, but not why. And of the three questions, the why is the most important.

In a previous blog, I explored the difference between activities, outputs, and outcomes.

The activities represents the work or the how. Most of the traditional planning focuses here.

Outputs are the intended products, services or results of that work. They are the what.

Impacts are the things we hope to accomplish. These represent the why behind the request. Impacts are not reflected in the PMI definition of scope. Why we are taking on the work and producing the output is generally ignored.

How can we be sure that the identified work will produce the outputs we want and the impact we desire? We cannot.

IF we do this Work, Then we will get this Product/Result which will then result in this Impact.

Not only is all of this a best guess built on a lot of assumptions, most project managers and project teams put this into a business case then promptly forget it. They focus only on the work and perhaps a little bit on the outputs, but they completely ignore the impacts or the Why they are doing the work.

PMI acknowledged the lack of focus on outcomes or why in a 2016 study called The Strategic Impact of Projects. They stated that “The data from our 2016 Pulse of the Profession® reveals that a staggering 83 percent of organizations lack maturity with benefits realization, raising myriad questions about how they understand the business value of projects and programs. Our research further confirms that this lack of maturity may be contributing to projects—including strategic initiatives—failing to achieve their original goals and business intent.”

“The data from our 2016 Pulse of the Profession® reveals that a staggering 83 percent of organizations lack maturity with benefits realization, raising myriad questions about how they understand the business value of projects and programs. Our research further confirms that this lack of maturity may be contributing to projects—including strategic initiatives—failing to achieve their original goals and business intent.”

— PMI (2016). The Strategic Impact of Projects: Identify benefits to drive business results.

Stating the obvious, perhaps PMI should focus more on the outcomes or the why, and less on how and what – the project scope – that they seem to be desperately trying to define and defend.

How many of us have implemented technology solutions in a particular business area, with the business goal of reducing FTEs only to see that at the end of the project there are actually MORE FTEs working in that business area?

This is the problem with the narrow focus of the project manager on the scope (work) – they believe that the job is to deliver to the plan (think OTOBOS), rather than to achieve the business impact.

A second major problem with the scope (how + what) is that it represents a best guess at the start of the initiative. That ‘product, service or result’ can easily change over time. They desired impact may change, or there may be a better way to achieve the impact. The requestor might express the actual need more accurately, or the understanding of it might change. Or the actual need may morph into something else.

Gotcha! the project manager exclaims. Scope Creep!

The problem is as we mentioned earlier, that scope is not fully understood until the end of the project. This is where the cone of uncertainty comes in.

The Cone of Uncertainty

I first read about the cone of uncertainty in Steve McConnell’s book, Software Project Survival Guide.

The basic idea is that the least amount of information is available at the beginning of the project, and so estimates about what it will take may vary widely. McConnell claimed that the uncertainty at the start of a project was as much as 25% of the estimate and as high as 400%. It was only at the end of the project or initiative do you really understand what it takes to build it. At that point your estimates become exact. Anything prior to the end is subject to uncertainty.

We can imagine the scope as PMI defines it as a point on the left hand side of the graph. The ‘scope’ defined at the beginning of the project, should be thought of like that wide cone on the left side of the cone of uncertainty. It is a best guess built on a lot of assumptions about what is actually a range of possibilities.

At the start of the project, when we know the least, the scope is subject to wide variations. Or I should say, our guess of what will be the scope could vary widely from the actual scope. Anything that we document about the work to be done or the resulting product is a guess subject to the 25% and 400% variance.

If we were to shift our thinking in that way, then, we could hold our initial beliefs, assumptions and expectations about the scope more loosely. We could think of scope as an unknown that we are exploring and learning about. It is as far from certainty as possible.

What is the True Project Scope?

I would argue that the true scope of the project, the how and the why is that final delivered scope. That is what it actually took. It is the finished estimates from the far right side of Steve McConnell’s cone of uncertainty.

At the end of the project, the scope will be known. It will be certain. We could represent the end state like this.

And if at the start of the project or initiative we think we know what the scope is, we are likely to be wrong.

Which can be quite dangerous.

Believing we have any level of certainty about the scope at the beginning of the project is foolhardy. In the words of the famous project management specialist Mark Twain, “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

— Mark Twain

So why do project managers and other stakeholders treat their initial estimates with certainty? Why do they try to protect these guesses and assumptions against scope creep? Why do we even use a negative label like scope creep?

It is our human need for certainty. With certainty comes a feeling of control and security.

So the question is, how can a project manager be certain about and manage the scope that is uncertain?

The answer is, they can’t. We need to change our paradigm about scope and we need new ways of thinking like those introduced by Elisabeth Hendrickson.

Intentions, Implementation and Actual Need

I learned about Hendrickson years ago from some great youtube videos she had posted about software testing. That led me to her website, Test Obsessed, her 2013 book Explore It, and her twitter feed (@testobsessed). These days she is busy with a day job and is not producing as much content, sadly.

One of the images that I gleaned from Hendrickson was this one below, found in a Slideshare presentation about feedback cycles.

It was this diagram that helped me to see that cone of uncertainty at work. And to begin to understand the need for exploration and short feedback loops.

• Intent in Hendrickson’s diagram represents what the requestor says that they need. In PMI language, this is the scope that might be in the form of a requirements document.
• Implementation in the diagram represents what is built as a result of the expressed need or intent.
• And the Actual Need is what the requestor truly needs, which might be different than what they expressed and what was implemented.

Could there be gaps between these three things? Hell yes! The implementation could be different than the intent due to interpretation errors. The team built what they thought was the intent, but it is very likely they got it wrong.

Could the actual need be different than the intent? Almost always. This is when the user says, I know what I said but what I actually need is this. And in some cases, a user cannot tell you what they need until they see it.

The way out is to recognize these likely gaps, build in small increments and shorten the feedback loops. We take a small part of what the user expressed as Intent, we Implement it and show it to the customer and ask them if it the result is what they actually need or not. And then we go back through the process for another small increment of functionality.

Through this process, we are exploring, learning, and moving from the far left on the cone of uncertainty toward the far right.

Key Takeaways

I hope that this article helps you to see that scope creep on technology projects as a red herring, and that you actually banish the word. Here are some other key takeaways:

1. Start with Why – Not only is this a great book title, it is an important project skill. Shift your thinking from the scope as work (how) and product (what) and focus on the outcomes or the why. What is the desired business outcome that we are trying to address? And we need to think about the Why throughout. Is there a better or easier way to achieve the “why” then what was originally proposed? If the Scope doesn’t provide the shortest path to the business need or goal, we should be willing to abandon it for the better path.
2. Expect Scope to Change – The scope you identify at the start of the project is a best guess of what is actually needed. If your scope is locked in and not changing, you are going to hit the wrong target, guaranteed.
3. Stop Using Scope Creep as a label – Scope creep is an ugly label and should not be applied to 1) requestors learning more about what they actually need and 2) teams learning how to build that need and 3) the drivers for the request actually changing. Also, Scope Creep pits requestors, teams and project managers against one another.
4. Assume you are Wrong – Most of our assumptions about the future are going to be wrong. Stop treating guesses like guarantees. Read the Lean Startup book which describes in detail how to expose and validate assumptions.
5. Stop Trying to Write Better Requirements Documents – A common approach to gain ‘certainty’ in projects is to spend more time and expend more effort perfecting requirements documents. It won’t eliminate uncertainty, or improve your ability to deliver desired business results. Instead, start with the most important business need, build a small part of it and show it to the customer for feedback.
6. Focus on Collaboration – Rather than focusing on Scope Creep which tends to polarize project stakeholders and create an adversarial relationship, focus on close collaboration between the customer and the development team. Treat the exercise of building solutions as exploration and trial and error.

I hope you find this helpful and as always, I welcome your comments.