Managing scope creep

Scope creep. Two words that send a shiver down the spine of anyone who works in client services.

When managed correctly, scope creep stays in its box, the project gets delivered as planned, and everyone's happy.

But unfortunately scope creek does happen, and most people don’t manage it very well.

In fact, it's a huge problem (according to the PMI Pulse report)

50% of projects experience scope creep
Only 57% finish within the estimated budget
And only 51% finish on the estimated schedule

Successfully managing scope creep is sometimes the difference between succeeding in client services, and deciding to give up altogether and find a 9-5 job.

Why is scope creep a problem? 🤷‍♂️

"Assumptions are the termites of relationships”
– Henry Winkler, Actor

Scope creep, requirement creep, or feature creep - whatever you call it, it's when the requirements of a project change during the delivery phase, affecting both the budget and schedule of the project - which for the client are two of the most important factors.

But the worst part about scope creep is that it leaves everyone unhappy.

For you, it can be frustrating having a client continuously change requirements, and for the client, it’s frustrating hearing that their project won’t be delivered on time or on budget.

How does scope creep occur? 🤦‍♂️

“Clear thinking requires courage rather than intelligence”
– Thomas Szasz, Academic and psychiatrist

Ask any agency or freelancer, and they’ll tell you scope creep occurs when clients say things like…

“That looks great, but could we also now add…”
“Now that Jane has seen this, she was thinking we should…”
“I just noticed this other website has X, and I would like to add…”

And that’s definitely one type of scope creep, when the client changes their mind.

But remember just because the client asks for something, doesn’t mean the scope has changed. The project scope is really just an agreement of what will be delivered, so it can’t just change without both parties agreeing.

But there are some other types of scope creep, where the size of the project increases without you initially realising.

Miscommunication can mean missing requirements, or failing to fully understand what the client has asked for. For you, this feels like scope creep, but not to your client. Similarly, unexpected complexity can make the project balloon well past what you thought the initial scope was (e.g. realising you now have to implement your own scheduling system, because you thought a third-party API handled it when it doesn’t).

So scope creep comes in a few shapes and sizes.

I believe there are 5 key reasons why 50% of projects are affected by scope creep.

Unclear project requirements
Failure to set expectations
Unexpected complexity
No planned contingency
Saying “Ok” to everything

Let’s dive into each of these, and talk about how to manage them effectively.

How to manage scope creep

“Ch-ch-changes (Turn and face the strain)
Ch-ch-changes (Where's your shame, you've left us up to our necks in it)”
– David Bowie, Changes

1. Set clear project requirements 📝

Miscommunication between what the client asks for, and what you understand, is a central source of scope creep. You can debate forever whether they told you they “wanted their logo to spin” or not, but if they say they said it, and you say you didn’t hear it - then that’s a problem.

Miscommunication can also be sneakier.

For example, your client requests that “When X happens we get a notification” so you add that as a requirement, and start the project. But it’s not until they actually see the feature two months later that you realise they expected a Slack notification, not an email. They didn't say, and you didn't ask.

There’s no room for assumptions in successful projects, and ambiguous requirements need to be further clarified.

5 ways to make sure you set precise requirements:

Be super detailed with the requirements documentation. I use living user story documentation for this.
Have a requirement confirmation session with your client, where you run through all requirements and agree to “sign them off” to officially confirm understanding. I do this in a follow-up after the project workshop.
Use the signed-off requirements as the line items in your estimation, which you also send to your client to review.
Break the project into small sprints (I do 2 weeks), and before starting a sprint hold a sprint kickoff session to re-run through and confirm the exact requirements in that sprint.
When your client is testing a sprint, give them a document with the exact confirmed requirements to test.

Adding these checks and balances helps catch any unclear requirements early, and hopefully before you start any real work.

But accurate requirements also rely on strong communication, as they may need to be re-confirmed throughout the development phase.

Always make sure everything is clearly communicated, and that there is a paper trail about the decision. I recommend summarising in an email, even if the conversation took place out of email, and always ensure requirements are updated in one central single source of truth.

2. Set expectations 🤝

If the first time your client understands how you handle scope creep, is when the scope has started creeping - then you’ve done it wrong.

Your way of working should be communicated from the first time you meet a client, and re-enforced often, especially at the start of a relationship.

What do I mean by “your way of working”?

I mean your standards and processes.

How you gather requirements and scope projects
How you price your project
How you deal with new feature requests
How you deal with unexpected changes
How you manage communication
How you manage the project

Your client is looking for an expert to guide them, and your standards and processes are the way you ensure a quality project delivery. And that’s great because that’s exactly how you set clear expectations.

5 ways to make sure you have set expectations:

From your very first interaction, or the “sales dance” as I like to call it, tell your client how you work. Educate them, as they may never have embarked on a project like this before.
A project workshop is the next place to communicate what they should expect when choosing you to deliver their project. As this is a longer session you can go into much more detail.
Your proposal for the project should enforce how you work. In fact, I always included a 3 page “How we work” at the end of every proposal (just in case it wasn’t clear by this stage)
Once a client accepts your proposal, again it’s best to do a quick run-through (in person or on a call) of how it’s going to work. Remember, people don’t always read everything you give them.
Be consistent with describing your processes the entire way through your project. Sprint kickoff, retrospective, and any other further client meetings.

3. Avoid unexpected complexity 🛠

Easier said than done, as the problem here is the “unexpected” part.

Unexpected complexity is when something turns out to be more involved than you initially anticipated. So whilst this is scope creep for you (things just for a lot harder), your client doesn’t think it’s scope creep. So this can be a tricky one to handle.

But there are definitely ways to mitigate unexpected complexity and reduce the chances of it occurring in your project.

5 ways to avoid unexpected complexity:

Simply avoid complexity, and you’ll avoid unexpected complexity. By "dumbing down" things as much as possible, there are fewer hidden cracks for unexpected complexity to hide. Prioritise clean and maintainable instead of over-engineered.
Use trusted tools. Don’t decide that this project is a great time to try that cutting-edge technology. Don’t make your client your guinea pig - do that on your own internal projects.
Conduct thorough research on things you haven’t used before. Read the documentation, reviews, and outstanding Github issues. Do everything you can to confirm it’s the right choice.
If you need, create a simple prototype to confirm assumptions. Be transparent with your client, and do this as a standalone mini project, as their project success may depend on this prototype working as expected.
Do the riskiest or more complex parts right upfront. Even if you built a prototype, when developing the project front-load the riskiest parts. Don’t always start with the “Login” screen and work from there. Whilst this doesn’t directly avoid complexity, you will find unexpected issues much sooner- which will give you a lot more options on how to proceed.

4. Build in a planned contingency 📊

If you read my article on my hybrid pricing approach, you will see I build two contingencies into a project. Technical risk contingency, and project enhancement contingency.

Software development is not an exact science, so I add multiple layers of contingency and buffer to provide the best chance of success. By not adding any contingencies into the cost and schedule you provide your client, you are simply asking for trouble.

You always hear the phrase "underpromise and overdeliver" right? Here’s how you do that.

5 ways to include planned contingencies:

Build a technical risk contingency of 10%-20% into the project. Base this amount on how “risky” this project is to deliver from a technical standpoint, e.g. how much of the tech you have never used before.
Add a project enhancement contingency of between 10%-20%, to allow your client to add “scope creep” without affecting the time or cost. Base this amount on the chances of this client requesting changes. If you haven’t worked with them before, go higher as opposed to lower.
Add a buffer to the external project schedule you give your client. Allow yourself extra time for everything. E.g on a 2 month project I would allow 1 week, meaning you get things done 1 week earlier than when you show the client, you can then eat into this buffer if you need to and not be so rushed.
Nothing is set in stone. I always reminded my clients that an “estimated delivery date” is exactly that, an estimate. If they need to plan a press release or a launch party, then I suggest they do it a week or two after what we plan. Why would you add undue stress when it’s not needed.
If a client has a fixed budget that cannot budge, I recommend they only spend 80% of it, even with the other contingencies above. Remind them of the statistics around how many projects go over time and budget. This is not your fault, it's the whole software development industry, and it's better to be safe than sorry.

5. Don’t just say “Ok” to everything 🤔

If you’ve implemented all of the previous steps, and your client still demands that they asked for “Login with Google Account” but somehow it wasn’t captured in the requirements (or any of the requirement review sessions) - then what happens next is up to you.

If you just say “Ok”, and start working on it, then that will affect the schedule. And if you choose to charge for that, then it affects the client's price (and if you don’t it affects your budget).

But you have the signed-off requirements from the scoping phase and the estimate, you’ve set expectations the whole time, and let them know that anything not in the requirements will not be included.

So you didn’t “miss” this feature… everyone missed it.

In fact, as this is their project, and they knew they wanted that feature - it is actually more in their court than yours.

But none of that really matters, as you want to keep your client relationship strong, so it’s never time to blame people.

Hopefully, you have the project enhancement contingency built into your time and cost, so you can use that if needed. But assuming you don’t, or assuming you've already used it all - there are options other than just saying “Ok” and adding it into scope.

5 ways to avoid just saying OK to scope creep:

Scope the new features with your client, estimate them, and then put them in the project backlog.
The project enhancement contingency can then be used to accommodate some or all of the backlog items (depending on how much there is and how many new features there are). This won’t affect the price or schedule, as it was already considered upfront.
Backlog items can be paid for individually by the client on a time and materials basis.
Backlog items can be left for now, and bundled into a future “Version 2” of the project to be booked separately. This is my preferred approach, and again you can set expectations with a client up front that 90% of projects end up having multiple versions, so they don’t need to do it all now.
You can offer a discount for any new features. This is a compromise, as the price and time will still increase, but you share the increase. Only do this if you do feel like a mistake happened and something was missed in the requirements, this should not be a common occurrence.

My experience with scope creep 📢

“Experience is a great teacher”
– John Legend, American singer-songwriter

When starting out, I had to learn the hard way - I guess most people do.

Clients would ask for additional things, and sometimes I would do them for free. This seemed fine when starting out, especially when starting a new project.

Early on my requirements were probably a little too vague, some parts were ambiguous, and maybe a feature got missed here or there. You’re excited to get started, so it makes sense why this happens.

It took me about 6 months before I found the processes to help mitigate scope creep - but honestly - it was always a work in progress, and the contents of this article were 8 years in the making.

I think one of the key ways I avoided scope creep was to move clients to an ongoing monthly retainer.

Retainers can make the process more flexible, as with an agreed number of hours per month, it’s really up to the client what we should spend that on. If they change their mind and now want their “logo to spin” - no worries, that will take time away from another feature (that will have to wait until next month).

But whilst retainers can make it a little easier, scope creep can still happen. It’s really just part of the game.

So do the best you can to have systems and processes in place to mitigate scope creep from occuring, and then if it does occur - do the best you can to deal with it as fast as possible.

Keep learning, keep experimenting, and you’ll keep improving.