Essay · 16 August 2026
Why programmes stall, and why the reason is almost never the one in the status report
A stalled programme always has an official explanation. It is usually true, usually incomplete, and usually describes a symptom that somebody is already being paid to fix.
Status reports are written by people whose competence is being reported on. That is not dishonesty; it is arithmetic. The explanations that survive into a steering committee are the ones that are safe to say there, and the ones that are safe to say are usually the ones nobody in the room is responsible for.
So the reported cause is nearly always downstream: an integration took longer than expected, a vendor under-delivered, requirements changed. Each may be factually correct. None of them explain why the programme could not absorb an ordinary setback, which is the actual question.
Five structural causes account for most of what we find.
One. Nobody owns the outcome
Plenty of people own deliverables. Somebody owns the platform, somebody owns the migration, somebody owns the change communications. Ownership of whether the business is measurably better afterwards is frequently unassigned, and a programme with no outcome owner cannot make a trade-off, because a trade-off requires someone who is allowed to lose something.
The symptom it produces: endless scope. Every request is accepted because refusing one requires authority nobody holds.
Two. The organisation cannot absorb the change
The programme is sound and the receiving organisation is at capacity. The people who would have to change how they work are already fully committed to running the business as it currently is. Nothing in the plan is wrong; there is simply nowhere for it to go.
This is the one that most reliably escapes detection, because every individual workstream reports green. The failure is not in any of them. It is in the medium they are being introduced into.
The symptom: excellent delivery and no adoption. The system goes live and the old process continues beside it.
Three. The brief was wrong and nobody was paid to say so
A programme is commissioned as a website, a platform, a rebrand. The actual constraint was somewhere else entirely: the proposition, the pricing, the route to market. The firm engaged to build the website is not the firm that will tell you the website is not the problem, and asking them to is asking them to argue themselves out of a contract.
The symptom: the programme delivers exactly what was asked for and the numbers do not move. Which is then read as a delivery failure, and generates a second programme.
Four. Fragmentation across vendors
Five competent suppliers, five separate briefs, five definitions of success, and no party accountable for the outcome. Each performs adequately against its own scope. The gaps between the scopes belong to nobody, and that is where the programme actually lives.
The symptom: integration problems, blamed on integration. The integration is where the fragmentation becomes visible, not where it originated.
Five. The sponsor changed
The programme was somebody’s conviction. That person moved, and it became somebody else’s inheritance. Inherited programmes are rarely killed and rarely championed; they are continued at reduced conviction, which is the most expensive of the available options.
The symptom: slow, unexplained deceleration. Nothing is wrong on paper and nothing moves.
Why the symptom is what gets treated
Because symptoms have owners and causes do not. An integration problem has an integration team. An adoption problem has a change manager. “Nobody owns the outcome” has no owner by definition (that is what the sentence means), and so it stays in the room after the meeting ends.
Which is the whole argument for an outside party. Not superior insight. Simply somebody with no position to protect, who can say the thing that several people already suspect and none of them can afford to be the first to say.
Testing this on your own programme
The receptivity gate is five questions and is published in full. If two or more come back negative, the constraint is the medium rather than the plan, and no amount of delivery effort will change that.