The Scope Ratchet: Why Projects Only Ever Grow, and What That Costs

No one ever decided to make the project bigger. There was no meeting where someone stood up and proposed doubling the scope, no board that approved a fifty percent increase in the work. Instead there was a request in a corridor, a "could we also just", a reasonable addition in week nine that nobody could find a good reason to refuse. And another in week twelve. Each one was small. Each one was sensible. And somewhere between the first and the twentieth, a three-month project became a six-month one, and no single person can tell you where it happened.

This is the most familiar failure in project delivery, and we have the wrong name for it. We call it scope creep, as though the problem were a slow leak to be sealed. The more useful way to see it is mechanical. Scope has a ratchet: a mechanism that turns easily in one direction and locks against the other. Requirements go in with almost no friction, because each addition is individually small and refusing it feels petty. They almost never come out, because removing something already promised requires someone to actively take value away from a stakeholder, and no one volunteers for that. So the total only ever climbs. This piece is about the economics of that ratchet: why each click is nearly free to add and nearly impossible to reverse, what it actually costs on the resource that sets your delivery speed, and why the single-project view cannot see the bill until it is enormous.

Every scope addition is an unpriced project you never approved

Start with what a mid-project scope addition actually is, stripped of the language that makes it sound minor. Someone has asked you to do a body of work that was not in the plan, that will consume some of your capacity, and that will push out a delivery date. That is not a tweak. That is a project. A very small one, perhaps, but structurally identical to any other piece of work competing for your resources.

Now recall how a real project is supposed to enter your portfolio. It gets sized. It gets priced against what it displaces, because in a busy system the cost of new work lands on the work already in flight, not on the newcomer. It gets ranked by what it returns on your constraint, so that it only goes ahead of existing work if it earns the queue position. It gets a go decision from someone with the authority to make it.

A scope addition receives none of this. It arrives as a conversation, not a business case. It is bolted onto work that is already moving, so it inherits that work's priority automatically, which means it jumps the entire queue without ever being ranked against the things it is now ahead of. And it is small enough that asking for a formal decision feels like bureaucratic theatre, so it is simply absorbed. Every scope addition is a project that skipped the queue, dodged the pricing, and was approved by no one. The ratchet is not a governance gap you forgot to close. It is a second, invisible intake path into your portfolio, running in parallel with the official one, admitting work that the official one would very often have rejected.

The click is small; the drag is not

Here is why the individual click feels harmless. The addition is measured against the whole project, and against the whole project it is tiny. "We are three months in, this is two more days of work, of course we can fit it." Two days against ninety is nothing. The comparison is honest and it is completely beside the point.

Because the two days are not free. If they land on your constraint, the resource that actually sets how fast your portfolio delivers, then those two days push the project's delivery out by two days, and every day of delay carries a drag cost: value not yet earned because the outcome has not yet arrived. And the delay does not stop at this project. The addition extends the time this project sits on the constraint, which means everything queued behind it on that same resource also moves out by two days, each of those projects carrying its own cost of delay. The two-day feature is charged not against ninety days of project, but against the summed cost of delay of every project it just pushed back. Measured that way, it was never small.

This is the arithmetic the corridor conversation never runs. The person requesting the addition sees its benefit clearly, because it is their benefit. What they cannot see is the denominator: the pile of unrelated work, on other projects, belonging to other people, that just got later so their feature could go in. The cost is real, it is often large, and it is structurally invisible to the only person in a position to ask for the change.

The ratchet only turns one way, so it compounds

If additions were as easy to remove as to add, scope would wander up and down and average out. It does not, because the two directions are not symmetric.

Adding is frictionless. It makes a stakeholder happy, it happens in a conversation, and the cost is deferred and diffuse. Removing is the opposite. Taking something out of scope means telling someone who was promised a thing that they are not getting it, which is a visible loss delivered to a specific face, now. Loss aversion does the rest: a benefit already promised feels owned, and removing it reads as a takeaway rather than a saving. So the friction on the way out is enormous while the friction on the way in is near zero. That asymmetry is the whole mechanism. It guarantees that over the life of a project the total does not fluctuate, it accumulates.

And accumulation compounds in a way that a single click disguises. A project scoped at ten weeks of constrained-resource work that accepts, across its life, a run of "reasonable" additions totalling sixty percent more, is now a sixteen-week project. Its batch size has grown by more than half, which means it ties up the constraint for half as long again, hides its problems for longer, and returns nothing for the extra weeks. Nobody chose a sixteen-week project. Nobody would have approved one at the outset, because at the outset it would have been ranked against the alternatives and quite possibly lost. It became a sixteen-week project one unarguable click at a time, and by the time the size is obvious the sunk cost makes stopping feel wasteful. The ratchet does not just add work. It launders a project you would have rejected into one you feel obliged to finish.

A worked example

Put numbers on it. Treat them as illustrative; the shape is the point.

A project is scoped at ten weeks of work on your constrained specialist, and once live it is worth a cost of delay of about £15,000 per week. Behind it in the constraint's queue sit three more projects, with cost-of-delay rates of roughly £10,000, £8,000, and £6,000 per week. That queue matters, because anything that extends this project delays all three.

Now run the ratchet. Over the project's life it accepts six additions, each one sold as "a couple of days", each one genuinely reasonable in isolation. Together they add four weeks of constrained work, taking the project from ten weeks to fourteen.

Read the bill. The four extra weeks push this project's own delivery out by four weeks: £60,000 of drag on its own value. But the same four weeks also push out everything behind it in the queue. The three waiting projects each deliver four weeks later, at £10,000, £8,000 and £6,000 per week, which is another £96,000 of drag spread across work that had nothing to do with the requests. The six "couple of days" favours cost the portfolio something like £156,000 in delayed value, and not one of the six was ever priced, ranked, or formally approved. Against that, the combined benefit of the six additions might be real and worth having, or might be a handful of nice-to-haves nobody will remember. The point is that no one ever compared the two, because the machinery that would have forced the comparison was never invoked. The additions came in through the side door, and the side door has no meter on it.

Had even one of those additions been sized and tested for its return on the constrained resource the way a new project would be, most of that £156,000 would have been a conscious choice rather than an accident.

Why single-project management is blind to this

If the cost is this large, why does almost every organisation let the ratchet turn? Because the frame it manages in has no place to record what is happening.

Managed as a single project against its own baseline, scope creep shows up, if at all, as the baseline being re-baselined: the plan is updated, the date moves, and the variance resets to zero. The project looks under control again the moment the paperwork catches up with reality. Nothing on the project's own instruments registers that a portfolio-level cost was just incurred, because the cost did not land on the project. It landed on the three projects queued behind it, on delivery dates nobody in this conversation is watching, in a queue that appears on no one's plan. Each addition is locally reasonable, locally approved by the person closest to the work, and locally invisible in its consequences. Every actor behaves sensibly and the aggregate is a portfolio that grows heavier every week.

This is the Project Illusion operating at the level of requirements. A project can honour every stakeholder request, keep every promise it made along the way, re-baseline cleanly each time, and be marked a success, while having consumed sixty percent more of your scarcest resource than it was ever worth, and delayed three better-returning projects to do it. The thing being optimised was stakeholder satisfaction on this project. The thing being destroyed was throughput across the portfolio, and the single-project frame has no gauge that reads it.

What to do instead

The goal is not a scope freeze. Requirements genuinely do change, and a project that cannot absorb a real discovery is brittle. The goal is to put a meter on the side door: to make each addition pass through the same economic gate any other piece of work would. A few disciplines do most of it.

1. Treat every scope change as an intake decision, not an edit. The rule is simply this: if a request would consume constrained-resource time, it is new work, and new work gets sized and priced before it is accepted, not after. This does not mean a business case for every two-day favour. It means the two days are made visible as two days of constraint time with a queue behind them, so the person saying yes is at least looking at what they are spending.

2. Price the addition against the queue, not against the project. The honest question is never "can we fit this into the project". It is "is this addition worth more than the delay it imposes on everything it pushes back". Attach the cost of delay of the affected queue to every proposed change. A request that looked obvious against ninety days of project often looks very different against the summed drag it creates.

3. Make the ratchet symmetric: for every in, force an out. The cheapest way to counter a one-way mechanism is to add friction to the easy direction and remove it from the hard one. Adopt a rule that a new requirement of size X must be paid for by removing, deferring, or descoping requirements of size X somewhere else in the project. This turns every addition into a trade the requester must justify, and it makes removal a routine act rather than a painful confrontation.

4. Protect the constraint first. Additions that do not touch your constrained resource are cheap and can be treated leniently. Additions that land on it are the expensive ones, because they extend the queue for the whole portfolio. Route scope changes through the same lens you use to protect the constraint from everything else: guard its time jealously, and let non-constraint work absorb what it can.

5. Re-test the whole project's economics after material change, not just the change. A project that has grown sixty percent is a different investment from the one you approved. Its return on the remaining investment should be recomputed once the additions mount, because the extra weeks may have moved it below projects you are currently starving to keep it fed. Scope that has ratcheted past a threshold is a trigger to re-rank, not just to re-baseline.

6. Full-kit the change before it enters, exactly as you would a project. A half-specified addition dropped into live work is rework waiting to happen: it will be built on assumptions that turn out wrong and redone at the worst possible time. Hold scope changes to the same readiness bar you hold new projects to: understood, sized, and genuinely ready before they are allowed to consume the constraint.

The objection you are already forming

"This is a recipe for rigidity. Projects exist to deliver value, and if we learn something in week nine that would make the outcome materially better, refusing it on the grounds that it was not in the original plan is exactly the bureaucratic, box-ticking behaviour that gives project governance a bad name. Sometimes the most valuable thing you can do is change course."

Agreed, and nothing here says otherwise. The argument is not that additions are bad. It is that additions should be chosen, and right now they are not chosen, they are absorbed. The genuinely valuable discovery in week nine is precisely the kind of change that will survive being sized and priced, because its benefit is large and obvious. Pricing it costs you nothing except the ten minutes it takes to confirm it is worth the drag, and it will be. What the discipline actually filters out is the other kind: the nice-to-have that seemed reasonable in a corridor, that no one would have funded as a standalone project, that goes in only because the side door was open and the click was easy. The ratchet does not select for value. It selects for whoever asks, however small the ask. All this reframe does is make the valuable changes and the vanity changes pass through the same gate, so that the first are approved with confidence and the second are seen for what they are.

The instinct to equate flexibility with saying yes to everything in the moment is one of the most expensive in delivery. Flexibility is the ability to change course deliberately, having weighed the cost. Absorbing every request without pricing it is not flexibility. It is the absence of a decision, dressed as responsiveness, and the bill for it lands weeks later on projects that were never in the room.

If this changed how you read the "small" changes on your own projects, the two ideas underneath it are worth the follow-on: why the cost of any new work lands on the work already in flight, in The Price of Yes, and why the size at which you release work is an economic choice in its own right, in The Case for Smaller Projects.