The business case was elegant. The steering committee had PowerPointed for months. The vendor selection ran for fourteen weeks. Then implementation started, and everything slowed down.
This is the pattern of failed enterprise programmes. Not sudden collapse — gradual suffocation.
The warning signs (usually ignored)
Month 3: "We are slightly behind on requirements, but nothing concerning."
Month 6: "The vendor needs to re-scope. We are having constructive conversations."
Month 9: "The first go-live has been moved to Q2. The business understands."
Month 12: The business sponsor has a new job. Their replacement does not understand why we are doing this.
Every programme that fails follows some version of this arc. The slide from "slightly behind" to "fundamentally stuck" is always gradual, always politely described, and almost always preventable.
The root cause: too much governance, not enough delivery
Failed programmes spend 60% of their energy on status reporting, risk registers, and steering committee preparation. They produce excellent documents and no working systems.
What we do instead:
Week 1: define the two outcomes that matter. Everything else is nice-to-have.
Week 2: name who decides when these two outcomes conflict. There will be conflicts.
Week 3: build something that works. Show it. Argue about it. Fix it.
Week 4 onwards: repeat week 3 every week until live.
The disciplines that save programmes
No status reports until something ships
If the only deliverable this month is a PowerPoint, we cancel the meeting and fix the plan. Status theatre is expensive and it substitutes for delivery.
Single-threaded ownership
One named person owns each outcome. They cannot delegate accountability. When they leave — and someone always leaves — we replace them within 48 hours or we pause the programme. An unowned outcome is a dead outcome.
Demo or die
Every fortnight, we demonstrate working capability to actual users. Not screenshots. Not prototypes. Working systems handling real scenarios. If we cannot demo, we do not proceed until we can.
The uncomfortable truth
Most programmes fail because no one with authority wants to hear bad news early. The people who know the programme is in trouble are not the people who get to say so.
We tell you immediately. Usually within the first month, we identify the constraint that will kill delivery if not addressed. Most clients do not want to hear it. The ones who do complete on time.
One question before you start
Can you name the single most important thing this programme must deliver, and the person who will be held accountable if it does not?
If not, do not start. Fix your scope and accountability first. No amount of programme management recovers a programme with no clear owner and no clear definition of done.