Scope Creep is Common

You’ll have seen it many times before. A project starts smoothly, but once you’ve started sharing progress, and asked for feedback, the requests begin. Small tweaks, additional features—before you know it, scope creep is eating into the budget, your margins and can even lead to project overruns.

Scope creep isn’t just an occasional challenge—it’s a constant reality for agencies. A project begins with what feel like clear expectations, but before you know it, your team and the client have differering priorities.

Your team need to be able to keep every project on track, and that means assessing and refining your agency’s delivery approach to avoid this risk.

Often scope creep requests are accidental. Perhaps a naive client with unclear expectations—clients assume something is included, or aren’t clear if they can change their mind.

Sometimes, it can be strategic—a sneaky attempt to squeeze more out of the budget you agreed.

Either way, how you handle it impacts your agency’s profitability, efficiency, and client relationships.

Your tactics during a project must depend on which approach you planned before it begin. The key is to be intentional and consistent.

Here’s a soundbite from an upcoming Everyday Agile podcast episode I recorded with Jac Hughes recently.

In this short clip take from a longer discussion focusing on AgencyLand Agile, I talk about building a project team, and why it’s key to include all the stakeholders in that effort.

Align around the client, the organisation, their challenges and their needs.

“Let’s just get started. We’ll work it out as we go. Who needs a plan anyway? We’re Agile!”

We knew some stuff. We certainly had enough excitement. The roadmap would become clearer as we did the work and made progress.

Or at least that was what we assumed. But 20 years ago I was still learning my trade.

And sure enough, not far into the project things got sticky. We’d made decisions without the client. Some which would be tough to undo. But undo them we must. Time and money had been wasted.

The key learning at the time was to know as much as possible before starting. Workshopping, user research, data analysis, paper prototyping. With the client stakeholders.

Often discussions we’d be having as we went anyway, just frontloaded to ensure we all headed in the right direction as a single group.

We found that starting things well had a compound effect on the remainder of the project. A poor start was impossible to compensate for later. Aligning, understanding and agreeing could (and should) all happen before work began.

Then, the majority of projects could be focused on doing, and smaller discoveries and changes to maximise the value being created.

And that’s now a key part of the approach I take with teams. We focus on starting projects well. Aligning around the needs, and a plan, and only then getting started.