Scope Creep Is Here to Stay

The Creep That Ate Our Budget

Every software project I’ve ever worked on has had one thing in common: The client keeps asking for more stuff after we’ve started. Even after our exhaustive discovery phase, even after we’ve painstakingly put together roadmaps, estimates, SOWs, and timelines, it’s just never enough for them. We call this phenomenon “Scope Creep.”

It sounds scary. It’s got the word “creep” right there with all of its negative baggage. It’s messing with our scope, which is tied to our budget, which is how we get paid, which is how we feed and clothe ourselves and our families. This all sounds like terrible news.

So how can you defeat this time-and-money-eating menace?

The Reality of Scope Creep

You can’t. There’s always something that was overlooked, or some facet of their business process they forgot to mention, or simply some new thing that pops up months after you’ve started building. No matter how good you are at planning, you can’t predict every single thing that’s going to be needed to get a software project off the ground.

Maybe instead of trying to banish the specter of scope creep from our Kanban boards we should reframe it. What’s really going on here? Are those rascally clients trying to squeeze in more work for free? Are we so inept that we’re constantly missing the mark when writing up requirements? Yea possibly, but I think there’s usually something less sinister going on.

Any app or website, no matter how small, has hidden layers of complexity. There are so many moving parts and things that need to be able to change contextually based on user input. There’s constant feedback and the landscape is always shifting underfoot.

The fact is that people are complex and systems are complex. So making systems for people is, like, really really complex. There’s no way around it. You can’t plan or template or flow chart your way out of it. You just have to accept it and know how you want to handle it.

Handling Scope Creep

There are a few ways I know of to handle these kinds of additional requests. I’ve tried them all and all of them can be valid depending on your circumstances, but some are objectively better than others.

Option 1: Just say no

This one is risky, but sometimes it’s necessary. If the project is small and the budget is tight, this could be the only way to maintain your sanity and not get stuck doing a bunch of extra work for free. Just beware of clients with unrealistic expectations, especially if the contract or SOW has any room for interpretation. They might think that everything they can imagine should be included.

Option 2: Say yes, for more money and/or time

This one seems obvious, but it can be tricky. You have to be able to clearly identify that the new idea is, in fact, new. Sometimes something will get highlighted that really should have been in SOW but was glossed over for some reason. And then you also have to be able to vet it and come up with a realistic estimate for the time and cost it will add. Having these conversations can sometimes lead to Option 3.

Option 3: Do it, but take something else away

If the new thing is all of a sudden a high priority item, but they can’t budge the budget or timeline, you can try to find something else in the project of similar size to remove. Even better than removing, you can use the magical phrase:

Option 4: Do it in Phase 2

This is my favorite option. If I like the client and the project and I want to keep working on it, having a backlog of stuff to add in Phase 2 is a great way to stay focused on the highest priority items and hit your launch target while building a roadmap for future improvements. Now it’s not an argument about what’s “in scope”, it’s a conversation about what’s most important and what we can do to evolve the product over time.

This option also allows the core product to get on its feet and be put to the test before expending effort on some of the nice-to-haves. Maybe the client likes the Phase 1 version of the app so much that they don’t feel the need to dive into Phase 2 any time soon, but that’s a much better problem to have than blowing up the initial budget and timeline to try to squeeze in every new idea.

Option 5: Do it for free, gladly

We’ve all been there. Eager to please, hungry for work, unaware of the slippery slope on which we’re precariously perched. But that usually leads to…

Option 6: Do it for free, grumpily

Just give in to that creep and let it wash over you. Clients are always jerks and you’re the martyr left holding the bag. You’re worth twice what they’re paying you and it’s still never enough for them. I’ve been there too, believe me, but it doesn’t have to be this way!

Reframing Scope Creep

So since this phenomenon happens on literally every project, is it truly a “problem?” That would be like saying it’s a “problem” that there aren’t any mockups before you make them. Or it’s a “problem” that you don’t have a server up and running to host all the code you also haven’t written yet. Are these things problems, or just steps in the process?

In the same way, scope changes are an expected step in the process of building software. As the ideas start to crystallize and stakeholders and users get their hands on early versions, things are going to occur to us to add, remove, or improve. People are imperfect and are going to forget to consider every single thing that needs to be considered at the outset. A new person is going to get hired and they’re not going to like the color yellow.

I would argue that scope creep already has another, friendlier name that we can use: Iteration. As we go through the project process, things change and we iterate. We don’t have to obey what was decreed in the original estimate, we can be nimble and agile and put things in Phase 2, or 3 or even 4!

Scope Creep (aka Iteration) may not be your best friend, but it is definitely your coworker. And it definitely has seniority.