Your Capacity to Change Is the Real Constraint
When a transformation programme runs late, the conversation is almost always about delivery. Was the estimate wrong, was the vendor slow, did the requirements move. Those are worth asking. They are also, in most cases, not the reason.
The reason is usually that more change was scheduled than the organisation could absorb, and no one measured that before committing — because it doesn’t appear on any plan. Scope is treated as a question of money and engineering. It is actually a load being placed on human beings, and they have a finite capacity for it.
Why the code can work and the plan still be wrong
The uncomfortable version of this is a programme where nothing technically failed. Every release shipped. Every feature met its specification. And a year later a meaningful share of it is unused, worked around, or being rebuilt because the way people actually work never converged with the way the system assumed they would.
That is not a delivery failure. It’s a capacity failure, and the signals are visible well before the end. Dates start slipping by small amounts in consecutive cycles. Testing gets shortened because the people who should be testing are still absorbing the last change. Adoption of the previous release plateaus somewhere below where it needed to be, and instead of stopping to fix that, the next release lands on top of it.
If your people are tired and your dates keep slipping, the plan is wrong. Not the people.
Why change capacity behaves like a training load
The useful analogy is physical training rather than budgeting. Volume, intensity and recovery all matter, and the limiting factor is not enthusiasm — it’s adaptation. Load beyond what can be adapted to doesn’t produce faster progress. It produces injury, and then a longer layoff than the ambition was ever worth.
Organisations have the same shape. A team can absorb a certain amount of new behaviour per quarter, and that amount depends on things you can actually observe: how much change they’ve had recently, whether the last one has settled, whether there’s someone whose job it is to help it land, and how many separate things are moving at once.
None of that is mysterious. It’s just rarely written down, which is why it gets overrun by a roadmap that was built from ambition.
Why the slider should be an explicit decision
The most practical move is to make the trade-off visible and deliberate rather than emergent. Once a quarter, decide out loud what proportion of delivery capacity goes to genuinely new capability versus improving and embedding what already exists.
Left undecided, the backlog decides it, and the backlog always votes for new. Decided explicitly, it becomes a single number that leadership owns and everyone can see. Push it too far toward new and you are making a high-risk bet on an organisation’s ability to change several things at once. Leave it too low and you have chosen stagnation, which is also a decision, just not one anybody said aloud.
Three more constraints do most of the remaining work. Cap concurrent streams — two is the working maximum for most businesses, three if each has a genuinely strong owner, and four is how programmes stall. Timebox releases so a team can finish absorbing one before the next arrives. And name one person accountable for adoption on each release — not for delivering it, for it being used. Delivery already has an owner. Adoption usually doesn’t, which is why it is the thing that fails.
Why slow scope is a strength
There is a version of this argument that sounds like an excuse for moving slowly, so it is worth being precise. The recommendation isn’t to do less. It’s to have fewer things in flight, finish them, and let each one settle before starting the next — which over a year delivers more, not less, because nothing has to be rebuilt and nobody has quietly reverted to the old way while you weren’t looking.
Slow scope is not a weakness. It is the only way big change ever gets finished. The organisations that transform successfully are rarely the ones that attempted the most at once. They are the ones that were honest about how much they could carry, and kept walking.