Every digital project I've ever been involved with has had at least one scope change. Every single one. Across 170-plus projects over 25 years, I cannot point to a single engagement where the scope agreed on day one was identical to what was delivered on the final day. Not one.
That either means we're terrible at scoping - which, honestly, I've considered - or it means scope change is an inherent feature of complex work. I'd argue it's the latter. But the fact that it's normal doesn't mean it's always healthy. And the difference between scope change that reflects genuine learning and scope change that reflects a governance failure is probably the most important thing a project sponsor can get their head around.
The scope was agreed at the start. If it changes, either we didn't specify properly or the agency is moving the goalposts.
I hear this a lot. And I understand why it feels true. You invested time in the brief. You went through workshops. You signed off on a statement of work. The whole point of that process was to agree what would be delivered. So when someone comes back and says "actually, we need to change X," it's natural to feel like something has gone wrong.
Sometimes it has. But often - more often than most people assume - the change is a sign that the project is working exactly as it should.
There are three situations where scope change genuinely produces a better outcome than sticking rigidly to the original plan. Recognising them in the moment is half the battle.
The first is discovery revealing hidden complexity. The most common one we see. You scope a content migration at 500 pages. Straightforward enough. Then the team gets into the actual content and finds that 200 of those pages contain embedded interactive calculators, third-party widgets, or conditional logic that requires completely different technical handling. That's not a failure of the original brief - it's something the brief genuinely couldn't have anticipated without doing the work.
I remember a project a couple of years ago where a mid-sized accountancy firm's "simple" page migration turned into something considerably more involved. Nobody - including their own team - had any idea how much custom functionality had been bolted onto their old Kentico instance over the years. We're talking about 47 separate custom modules, some of which hadn't been touched since 2016 and had no documentation whatsoever. The scope change added three weeks and a fair amount of tension in the room when we first raised it. It also prevented what would have been a broken site at launch. Worth it.
The second is user feedback contradicting the original specification. You've specified a client portal as a document repository. Makes sense on paper. Then you put an early version in front of actual users and discover that what clients really want isn't document storage - they want to know where their matter is. We ran into this on a portal build for a professional services firm a few years back. The client's internal team had been absolutely convinced that document access was the priority. Turned out their clients were logging in, ignoring the documents entirely, and emailing their account manager to ask for a status update. The scope change to add a live status feed felt like a detour at the time. It became the most-used feature on the platform. Ignoring that feedback to stay within scope would have been disciplined but daft.
The third is business context shifting during delivery. Your firm acquires another practice mid-project. Or a regulatory change lands. Or a major client relationship changes. The portal requirements are now different from when the brief was written, not because the brief was wrong, but because the world moved. A law firm we were working with completed a merger halfway through a website rebuild - suddenly they had two additional practice areas and a completely different geographic footprint across three new offices. The scope had to change. The alternative was delivering something that was already out of date on launch day.
In all three cases, the scope change creates value. Resisting it in the name of "sticking to the plan" would have produced a worse outcome.
Here's where it gets important. Because there's a world of difference between a scope change that's identified, assessed, and agreed - and one that just sort of... happens.
Managed scope change has three characteristics. The delivery team surfaces it proactively - you hear about it before you discover it. Its impact on timeline, budget, and other deliverables is assessed and documented before anyone starts working on it. And it's formally approved by you, the client, with the trade-offs understood.
Uncontrolled scope creep looks completely different. It accumulates through small decisions that each seem minor in isolation. "Oh, we just added that extra field." "We tweaked the navigation logic slightly." "The design team refined the dashboard layout." Each one feels trivial. The aggregate impact on timeline and budget is never clearly presented. And you discover the cumulative effect at a review meeting when reversing the changes is no longer practical. That's the moment when "we're running a bit behind" translates to "we've absorbed four weeks of undocumented changes and nobody told you."
That's a governance failure. Worth calling it what it is.
But - and I want to be honest about this - clients contribute to uncontrolled creep too. I've sat in plenty of meetings where a senior stakeholder casually says something like "oh, while you're in there, could you just add..." and expects it to be absorbed. Those corridor requests, those "quick additions" mentioned on a call, those "it shouldn't take long" comments - they're scope changes. Every one of them. And if they're not documented and assessed, they become the exact kind of uncontrolled creep that causes projects to drift.
So this isn't just about holding your delivery team accountable. It's about holding yourself accountable too.
I'm going to describe a four-step process. Before your eyes glaze over - this isn't bureaucracy for bureaucracy's sake. A scope change request should take about 30 minutes to write up and another 15 minutes to review and approve. If you're spending more than that, you've over-engineered it.
Step one: Identify and name. The delivery team's obligation is to surface a potential scope change as soon as it's identified. Before work on the changed scope begins, not after. This is the most important step, and it's the one that gets skipped most often. The temptation for a delivery team is to just crack on and deal with it - especially if the change seems small. But "small" has a habit of accumulating.
Step two: Assess and document. The impact on timeline, budget, quality, and other deliverables should be assessed and written down in a scope change request. Not discussed on a call. Not mentioned in a Slack message. Written down. This sounds pedantic, but I've seen enough projects where "we discussed it and agreed" means different things to different people three months later.
Step three: Decide with full information. This is your moment as the project sponsor. The delivery team presents the change with trade-offs clearly laid out: "Proceeding with this change will add two weeks and £8,000 to the project. The alternative is to proceed without it, accepting the limitation it creates, or to defer it to a Phase 2." Three options. Proceed, defer, or reject. You pick one.
Step four: Record and communicate. The decision - whichever way it goes - gets recorded in writing and distributed to both the delivery team and relevant client stakeholders within 24 hours. Done.
That's it. Four steps. The whole thing fits on a single page. If you want the scope change protocol as a one-page decision template - covering the four-step process and the impact assessment format - download it here.
I've written separately about the broader governance framework this sits within in a companion piece on. The scope change protocol is one component of that. But it's the component that, in my experience, has the most immediate practical impact.
Let me be direct about your rights in a scope change situation, because I think some project sponsors are too polite about this.
You should be involved in every scope decision before work begins on the changed scope. A delivery team that's making scope decisions without your involvement isn't following a change protocol - they're making unilateral decisions about how your money is spent. That's not collaboration. That's presumption.
You should receive a clear trade-off analysis for every change. A scope change presented as "inevitable" or "necessary" without an alternative isn't giving you a decision. It's asking you to ratify something that's already been decided. If there's genuinely no alternative, fine - but that should be explained, not assumed.
You should have a transparent view of the cumulative scope change impact on the programme. If the project has absorbed three approved scope changes, the current timeline and budget should reflect all three. This is where I see things go wrong most often - individual changes get approved, but nobody updates the overall picture, and suddenly the project is six weeks late and everyone's pointing fingers.
And you should always have the right to reject a scope change and proceed with the originally specified scope. Some changes are genuinely valuable. Some are nice-to-have additions that aren't worth the cost or the delay. You should always be able to say "no, let's stick with the plan" without feeling like you're being difficult.
The commercial model you've chosen for the project directly affects how scope changes are handled in practice - I've covered this in more detail in another piece covering fixed price, time and materials, and outcome-based pricing models. which is worth reading alongside this one.
Most scope changes are manageable. Some are genuinely valuable. But there are three patterns that should set off alarm bells.
Changes presented without impact assessment. "We need to add this - it won't take long." That's not an impact assessment. That's an invitation to absorb scope without accountability. If a delivery team can't tell you what a change will cost in time and money, they either haven't thought about it or they don't want you to know. Neither is acceptable.
Timeline or budget extensions attributed to vague external factors. The project that's always running late for reasons that aren't connected to specific, identifiable scope changes has a scope accounting problem. "Things have been more complex than expected" is not a reason. Which things? What specifically changed? When was it identified? If those questions can't be answered, someone is losing control of the project and dressing it up as bad luck.
The absence of a formal change record. This is the big one. If you're sitting in a project review and you can't point to a list of approved scope changes with their documented impact, the scope change protocol isn't operating. Full stop. Somebody - possibly everybody - is making decisions about how your investment is spent without your informed consent.
I've written about the broader set of warning signs that tell you whether a project is on track in [the piece on what good looks like halfway through a digital project]. Unmanaged scope creep is one of the clearest indicators in that framework.
I'm not going to pretend that every scope change conversation is comfortable. They're not. There's always a moment of tension when someone says "we need to change the plan." Your instinct as a sponsor is to protect the timeline and the budget. The delivery team's instinct is to solve the problem they've just discovered. Those instincts can collide if you're not careful.
What I've learned over a lot of projects: sponsors who treat every scope change as a crisis consistently create adversarial dynamics with their delivery teams at precisely the moments when collaborative problem-solving would produce the best outcomes. And sponsors who treat every scope change as normal consistently absorb cost and timeline overruns that a simple protocol would have prevented.
The right response is neither defensive nor permissive. It's structured. And honestly, once you've got the habit, it takes about as much effort as a decent cup of tea.
Scope change isn't a sign your project is failing. It's usually a sign your project is learning something real. The only question is whether you're managing that learning or whether it's quietly managing you.
If you want the scope change protocol as a one-page decision template - covering the four-step process, the impact assessment format, and the three decision options - download it here. It's designed to be used the moment a scope change is identified, not filed away in a project governance folder nobody opens.