Project delivery
Building for the team that comes after you
Every technical decision you make today is a decision for the next developer who touches the codebase. Here's what maintainable architect...
The Blog
Scope creep isn't the real problem
Project delivery
Every agency has a scope creep story. The project that started as a six-page website and finished as a twelve-page platform with a custom portal. The build that was quoted at eight weeks and delivered in fourteen. The client who kept adding "just one more thing" until the budget was gone and the relationship was strained.
Scope creep gets blamed for a lot of project pain. But scope creep isn't the problem. It's the symptom. The actual problems sit underneath, and they almost always start before development begins.
The causes
What's actually behind scope expansion
Scope creep doesn't come from nowhere. It comes from gaps that were present at the start of the project but didn't surface until mid-build.
- 01The scope was never specific enough
"Build a new website" isn't a scope. Neither is "redesign the platform." These are directions, not definitions. When the scope is described in broad terms, both sides fill in the gaps with assumptions. The client assumes certain features are included. The agency assumes they're not. Nobody discovers the mismatch until week six, when the client asks for something they thought was always part of the plan
- 02There's no process for handling changes
Changes are inevitable on any project. New requirements emerge. Business priorities shift. Someone sees the work in progress and realises they need something different. The problem isn't the change, it's having no agreed process for evaluating it. Without a change process, every new request becomes an open negotiation. Some get absorbed. Some get pushed back on. None are assessed consistently for impact on timeline, budget, or scope.
- 03The client wasn't involved early enough
When a client doesn't see working output until late in the build, they're reacting to a near-finished product rather than shaping it along the way. Reactions at that stage are expensive. "Can we change how this section works?" in week two is a conversation. The same question in week ten is a rework.
- 04 Nobody distinguished between must-haves and nice-to-haves
Everything in the brief was treated with equal priority. The core functionality, the stretch goals, and the "it would be nice if" features all went into the same scope document with no tiering. When everything is in scope, there's no framework for deciding what to cut when time or budget gets tight, so nothing gets cut. It all just takes longer.
Scope creep doesn't come from nowhere. It comes from an unclear starting point, and both sides contribute to that.
Both sides
How agencies and clients both contribute
Scope creep isn't just a client problem. Agencies contribute to it in ways that rarely get discussed.
- 01Agencies that don't push back early
An agency that agrees with everything in the first meeting isn't being accommodating, they're setting up a project that will either go over budget or under-deliver. Pushback early is a sign of experience. It means the agency has seen where projects go wrong and is trying to prevent it.
- 02Agencies that don't document trade-offs
When a scope decision has trade-offs, this feature will take three weeks and push the launch, the client needs to know. Agencies that absorb scope changes without flagging the consequences are building up pressure that will eventually surface. Usually as a timeline blowout or a quality compromise.
- 03Clients that treat the brief as a starting point
A brief that changes significantly after the project is scoped isn't a brief, it's a wish list that's still being refined. If the requirements aren't stable enough to scope against, the project isn't ready to start. Starting anyway and adjusting as you go is how scope creep becomes the default operating mode.
- 04Clients that involve new stakeholders mid-project
A senior leader who wasn't part of discovery reviews the work in week eight and wants changes. A department head sees the platform for the first time and adds requirements. Every new voice mid-project is a potential scope change, not because they're wrong, but because they're bringing context that wasn't part of the original decisions.
The fix
What actually prevents scope creep
Not "build a website" but "build a 12-page marketing platform with these content types, these integrations, and this editorial workflow." The more specific the scope document, the easier it is to identify when something falls outside it.
When someone requests an addition, there should be a documented way to assess impact on timeline, budget, and existing scope, and a named decision-maker who can approve or defer it. This isn't bureaucracy. It's the mechanism that turns scope discussions from negotiations into structured decisions.
Must-haves, should-haves, and nice-to-haves. When budget or timeline pressure hits, and it will, this tiering gives everyone a framework for deciding what stays and what gets deferred. Without it, every cut feels arbitrary and every decision becomes a debate.
Every two weeks, the client should see working software they can interact with. Not a presentation. Not a PDF. Something they can click through. Early feedback is cheap. Late feedback is expensive. The more often a client sees the work in progress, the less likely they are to request significant changes late in the build.
The conversation
Have it before the project starts
The best time to prevent scope creep is during discovery, before a line of code is written. That's when you define what the project is, what it isn't, how changes will be handled, and who makes the call when priorities compete.
The projects that run clean aren't the ones with perfect briefs. They're the ones where both sides agreed on the rules before the game started. Scope is a shared responsibility. When it drifts, it's rarely because one side did something wrong, it's because neither side set it up to succeed.