Revised July 2022

The term “scope creep” is usually a conversation ender.

Who could possibly defend scope creep? It seems to imply either an undisciplined customer requesting every new idea that pops into their heads, or perhaps on the other side an unscrupulous vendor attempting to weasel their way to billing more time and money.

Either way, the term has become an effective weapon to protect against new ideas arising that weren't in the original plan.

Project managers and budget owners especially worry about “scope creep”. How can we stick to our timeline and budget, they ask, if you’re going to keep changing the target? You can’t just keep shoehorning in more and more!

That’s an easy perspective to understand.

But the truth is, when you're building technology, scope creep may actually be exactly what you want. A sign that things are working, and that you are being appropriately opportunistic. 

Why does scope creep?

Scope will evolve as you build and you test and you use. And it should.

This is the nature of high quality technology work. By now, the hope that you can guess exactly what you need ahead of time is well understood to be a myth. As is the hope that you can make a technology product “good enough” when building it, and then leave it alone thereafter and expect it to maintain usefulness.

In a well executed, agile, iterative project, scope creep is the result of discovering new opportunities along the way — which are absolute gold. Or of learning something new about your own work in the process and wanting to incorporate this new insight.

Often the particular, specific details that emerge during this creative process are more nuanced, more impactful, differentiated and helpful, and sometimes even magical, because of the fact that they were uncovered as a result of real time feedback and active creativity.

Scope is supposed to creep because you’re supposed to learn new things as you gain new ground, and to make better decisions along the way because of what you’ve learned and what you can do now. You’re seeing new frontiers that were out of sight before. So everything you do is with the hope of getting closer to that promised land. And the goal is to never stop getting closer and closer to it, either by making more ground or by refining your understanding of where you are going.

So that new insight may be just what you were hoping for all along. And someone who yells “scope creep” to try to knock it out quickly is probably protecting the wrong target.

Your external agency should admit it too

That is why the best agencies who build technology products often have embraced unabashedly an iterative, agile-style project structure. They shouldn’t be pretending that they know exactly how much your idea will cost or how long it will take. That might feel reassuring at first, but it should actually be a bit of a warning sign.

Here’s a good test: does the agency you’re considering require a change order when you add a new feature? Do they communicate their displeasure when you change your mind about a previous decision after you see the result in practice?

If so, that’s simply not working in an agile way. They may be disguising an outdated working model with current-sounding language, but if you have to sign off on the scope of the project before it starts, or if you’re discouraged from changing course as you see things emerge, then that’s pretty much the old, non-agile way of working. You’re probably not going to end up with the product you really needed.

But what about budgets?

Of course it’s also true that ever-changing project scope is a very awkward fit for most organizations’ budget processes and project timelines. Executives and management need certainty in order to plan. That makes sense, but it puts you in the extremely awkward position of having to guess this year during budget planning how much a project is going to cost next year, without even quite knowing what you will end up building.

No getting around it, that’s just awkward. So how do you deal with it?

Step one in the right direction is to embrace the uncertainty. Stop pretending that you’re actually buying a known product for a known price. (You aren’t.)

Then allocate your budget in phases, making adjustments and prioritizations as you go. And allocate a decent pile of “extra” budget on top of those optimistic estimates, knowing that you will want to take the opportunities that arise to get to the best product you can.

If allocating extra budget during a project simply isn’t an option, then effective prioritization serves as your protection — meaning take the new win and de-prioritize something else. This is the very essence of working in an agile manner.

The build is never done

And for the love of all that is holy, don’t plan to stop allocating budget after the “build” is done. The build is never done. The moment you stop investing and iterating is the moment your product will start to wither. You must continue to invest and iterate for the life of the product if you want it to continue returning the value for which you built it in the first place.

It’s true that these realities don’t fit many organizations’ budgeting process well, but it’s not the technology approach that needs to change — it’s the budget process.

Don’t bet against your own success

Because this is the absolute truth of how great work happens. You simply can’t know enough to make the right choices until you’re in the midst of the work. And you NEED the flexibility to make strategic choices between options as they emerge -- EVEN when they might impact overall project cost. Don’t rob yourself of the game-changing adjustments that will present themselves, simply because you didn’t predict them ahead of time. That’s betting against your own success!

Both the organization and an external partner firm must build their process and expectations around this reality, or once again fumble their attempts at game-changing technology interventions by knee-capping them before they’ve seen the light of day.

If you’re going to the effort to build something new, remember why you embarked on it in the first place. Would you prefer to end up with the best product that delivers the most impact for you, or would you be satisfied with a project that under-delivers on its potential but stays aligned with someone’s original guesses about timeline and budget?

Remember how valuable this product will be if it actually delivers as you imagined when you first dreamed it up. You can be certain that you won’t get there on your very first attempt out of the gate. But if you’re agile, focused, smart, and opportunistic, you’ll get there. As long as you give yourself enough rope.