There's a sentence that has probably crossed your desk, your inbox, or your steering committee at least once in the last couple of years: "The scope has changed."
And I'd put money on your gut reaction being negative. A tightening somewhere behind the ribs. Because in most organisations, scope change means something has gone wrong. Someone didn't think it through. The agency overpromised. The requirements weren't nailed down properly. We're going to be late, over budget, or both.
That reaction is earned. If you've been through a digital project that drifted - and if you're a managing partner or operations director at a mid-sized B2B firm, the odds are overwhelmingly that you have - then "the scope has changed" probably triggers the same response as "we need to talk" does in a relationship. Nothing good follows.
But that instinct, while understandable, is wrong about half the time. And the half it's wrong about? That's where the best project outcomes I've ever seen have come from.
When you commission a significant digital project - a website rebuild, a CRM integration, a portal overhaul, whatever - you do it based on what you know at that moment. You've done discovery. You've talked to stakeholders. You've mapped requirements. Maybe you've even run a diagnostic sprint. All of that is good. Necessary, even.
But you're making decisions based on incomplete information. You have to. Everyone does. Because the only way to have complete information about what a project needs is to have already done the project.
I was talking to the COO of a 300-person consulting firm last year who put it brilliantly. She said, "We spent three months planning this thing. We thought we'd covered everything. Six weeks into build, we discovered that our client onboarding process - which we'd mapped in detail during discovery - bore almost no resemblance to what people actually did day-to-day. The documented process was aspirational. The real one involved four spreadsheets and a WhatsApp group."
At that point, they had a choice. Stick to the original scope and build something that reflected the documented process (which nobody followed), or change the scope to reflect reality. They changed it. The project came in two weeks later than planned and about 15% over the original budget. But the thing they built actually worked. Delivering on time and on budget to a spec that didn't match reality would have been a far more expensive failure.
If the plan changes, something has gone wrong. We should have planned better.
I hear this a lot. And sometimes it's true - sometimes scope changes because the planning genuinely was sloppy. But the assumption that better planning eliminates scope change is, honestly, a fantasy. It sounds wise in a boardroom and doesn't survive contact with reality.
Think about renovating a house. You get the surveys done. You hire a good architect. You plan everything meticulously. And then someone opens up a wall and finds wiring from the 1960s that wasn't on any drawing. That's not a planning failure. That's the wall telling you something you couldn't have known until you opened it. The question isn't "why didn't we find this earlier?" The question is "how do we handle it now?"
There are two types of scope change. They look similar from the outside. They feel different when you're in them. And they lead to completely different outcomes.
Uncontrolled creep is when scope expands without anyone making a deliberate decision. Death by a thousand "while we're at it" requests. A stakeholder who wasn't involved in planning suddenly appearing with a list of requirements. The agency saying "it would be really easy to also do X" without telling you what that means for timeline and budget. The project getting bigger without anyone formally acknowledging that it's getting bigger.
This is the bad kind. This is the kind that kills projects.
Managed evolution is when scope changes because you've learned something during delivery that changes your understanding of the problem - and the change is assessed, the trade-offs are made explicit, and someone with authority makes a conscious decision to adjust.
Same outcome on paper: the scope changed. Completely different thing in practice.
A real example. About eighteen months ago we were working with a mid-market law firm - around 120 lawyers, three offices, decent-sized client base - on a website rebuild. New CMS, modern design, better conversion paths, the usual. During the first sprint, our UX team ran some user testing with actual clients of the firm. Not prospects, existing clients. Something came up that nobody had anticipated: clients were using the website primarily to find direct contact details for their specific lawyer, and the existing site made that absurdly difficult. Four or five clicks minimum, sometimes more.
That wasn't in the brief. Nobody had flagged it during discovery. But it was clearly the single biggest friction point for the firm's most valuable audience. So we made a trade-off. We deprioritised a set of service page templates that were in the original scope - nice-to-have, not urgent - and instead built a prominent, searchable people directory that surfaced direct contact information within one click from any page on the site.
The scope changed. The budget didn't. The timeline shifted by about a week. And the deprioritised templates? They built them three months later, in a second phase, once the core site was live. The managing partner told me afterwards that the people directory alone had generated more positive client feedback than any other element of the site.
That's managed evolution. Not chaos. Intelligence.
When you're the one paying for a project and someone says "we think we should change the scope," you need to figure out pretty quickly whether this is a sign of a healthy project or a troubled one. These are the questions I'd insist on asking.
What did we learn that we didn't know before? If the answer is specific - "user testing revealed X" or "when we integrated with your CRM, we discovered Y" - that's a good sign. If the answer is vague - "we just think it would be better" or "the team feels like we should" - that's a warning.
What are we trading off? Every scope change has a cost. Always. If someone tells you they can add something without it affecting anything else, they're either not being straight with you or they don't understand their own plan. A well-managed scope change comes with a clear trade-off: we add this, we remove or defer that, or the timeline moves by this much, or the budget increases by this amount. No trade-off discussion? That's creep.
Who is making this decision? Scope changes should be decided by someone with the authority to make them. If changes are being absorbed into the project without anyone formally agreeing to them, you've lost control. This sounds obvious, but I cannot tell you how many times I've seen significant changes happen because a developer and a stakeholder had a conversation in a corridor and just... did it.
Is this the first time, or is this a pattern? One or two scope changes during a complex project is normal. Healthy, even. If you're seeing a new change request every sprint, something is structurally wrong - either the discovery was inadequate, the requirements weren't properly understood, or there's a stakeholder management problem that nobody's addressing.
Can I see the impact assessment? Not a verbal summary. A written one. Even if it's a paragraph in an email, it should exist: what's changing, why, what it costs, what it displaces, and what happens if you don't do it. If your delivery partner can't produce this within 24 hours of proposing a change, their change management process isn't mature enough.
I should talk about agile here, because it's relevant - and because there's a massive misconception about what agile actually means in the context of scope change.
A lot of clients I speak to think agile means "the scope is fluid and anything can change at any time." I understand why they think that, because frankly, some agencies have used "we're agile" as an excuse for not having a plan. That drives me a bit nuts, to be honest.
Agile - done properly - isn't about having no plan. It's about having a plan that's designed to accommodate learning. The scope of the overall project is agreed. The outcomes are defined. The budget is set. But the specific way you get there is broken into smaller chunks - sprints, typically two to four weeks each - and at the end of each chunk, you review what you've learned and adjust the next one accordingly.
The key mechanism is the trade-off conversation. In a well-run iterative project, you have a prioritised list of everything you need to deliver. When something new comes in - a requirement you didn't anticipate, a piece of learning from user testing, a technical constraint you've uncovered - it doesn't just get added to the list. It gets assessed, prioritised against everything else, and something of equivalent effort gets moved down or out. The total stays roughly the same. The contents evolve.
This is why, at Distinction, we're pretty insistent on running a quarterly rhythm using our WHNN framework even during delivery phases. It forces that re-prioritisation conversation at regular intervals, with the right people in the room, looking at what's working, what's changed, and what should happen next. It sounds like overhead. It's actually the thing that stops projects from quietly going sideways.
If you're about to commission a digital project - or if you're in the middle of one and feeling uneasy - there are a few things I'd want to hear from whoever is delivering it.
First: how do they handle change requests? Not philosophically. Mechanically. What's the actual process? Is there a form? A template? A standing agenda item in the sprint review? If the answer is "we just discuss it as a team," that's not a process. That's vibes.
Second: who has the authority to approve scope changes on their side? You want a named person. If every change has to be escalated to a partner or a board for approval, you'll create bottlenecks that slow everything down. If nobody needs to approve anything, you'll get creep. There's a middle ground, and you should agree it upfront.
Third: ask them to show you an example of a project where the scope changed and it went well. A specific, detailed example - what changed, why, what the trade-off was, what happened. If they can't give you one, they either haven't done it or they don't see it as worth remembering. Either way, concerning.
And fourth - this one's for you, not them: who on your side is actually empowered to make decisions during the project? One of the most common reasons scope change becomes chaotic is that the client-side decision-making structure isn't clear. If every change needs sign-off from a partner group that meets monthly, you're going to have problems. Appoint someone. Give them a mandate. Trust them.
I want to be direct about this, because some delivery partners - not all, but some - use the complexity of digital projects to subtly shift accountability for scope change onto the client. "Well, you changed the requirements." "Your stakeholders added things during the sprint."
So let me be clear about what you're entitled to.
You're entitled to know, at any point, what's in scope and what isn't. I had a client once - a financial services firm, about 200 people - who came to us after a previous project had gone badly wrong. When I asked them what had been in scope for the original project, nobody could tell me. Not the internal project lead, not the IT director, not the person who'd signed the contract. The scope had been discussed in meetings and referenced in emails but never formally documented and maintained. By the time the project ended, nobody had a shared understanding of what they'd agreed to build. That's not an edge case. That happens more than you'd think.
You're entitled to a written impact assessment before any scope change is agreed. Not after. Before.
You're entitled to say no. A delivery partner recommending a scope change is giving you advice. You're not obligated to take it. Sometimes the right answer is "that's interesting, but we're going to stick to the plan." A good partner will respect that. A bad one will make you feel irresponsible for saying it.
And you're entitled to a delivery partner who treats scope change as a normal, manageable part of project delivery - not as an emergency, and not as something they're embarrassed about. The ones who get uncomfortable when you ask about change management are usually the ones who don't have a process for it.
Here's where I want to flip this whole thing around. Because I've spent most of this article talking about how to manage scope change well. But what happens when firms refuse to allow any scope change at all?
I've seen this more than once. A firm commissions a project with a fixed scope, fixed budget, and fixed timeline. The contract is tight. The requirements document is 80 pages long. Everything is specified down to the pixel. And when the delivery team learns something during the project that suggests a different approach would be better, the answer is: "That's not what we agreed."
The project gets delivered on time. On budget. To spec. And it doesn't work.
Because the spec was based on assumptions that turned out to be wrong. And nobody was allowed to correct them.
I remember a financial services client - this was before they were working with us - who'd commissioned a client portal from a large systems integrator. Fixed price, fixed scope, detailed functional specification. Eighteen months of delivery. The contract was ironclad. It launched exactly as specified. And within six months, usage was so low they were considering decommissioning it. The portal did everything the spec said it should do. It just didn't do what clients actually needed. Nobody had tested that assumption with real users during the build, and even if they had, the contract didn't allow for changes.
That firm ended up spending nearly as much again rebuilding it. Roughly £800k the first time, another £600k to fix it. The "certainty" of the fixed scope had cost them double.
Good projects have a clear scope at the start. They also have a clear process for what happens when the scope needs to change. The existence of that process isn't a sign of uncertainty - it's a sign of maturity.
Good delivery partners will tell you when they think the scope should change. They'll tell you why. They'll show you the trade-offs. And they'll let you decide.
The firms I've seen get the best outcomes from digital projects aren't the ones who planned perfectly. Nobody plans perfectly. They're the ones who planned well enough to start, stayed close enough to the work to learn, and had the confidence - and the governance - to adjust when they needed to.
That's the difference between getting what you asked for and getting what you actually need.
If you're about to kick off a project and want to make sure your foundations are solid before you sign anything, our Fragility of Digital Foundations scorecard is worth fifteen minutes of your time. It'll surface the questions you should be asking - and a few you probably haven't thought to ask yet.