Key takeaways
- Treat readiness for build as a formal gate, not an assumption.
- Agree the work breakdown with every party who will deliver it, including suppliers.
- Name one accountable owner for each dependency before funding is released.
Most stalled programmes do not fail at the start. The business case is approved, the design is signed off and everyone agrees the change is needed. Then, somewhere between design and delivery, momentum quietly drains away. Months later the programme is still "about to start build".
Across telecoms, healthcare and the public sector, the pattern is remarkably consistent. The causes are rarely technical. They sit in the handover from people who designed the change to people who must deliver it.
Three reasons programmes stall
1. Nobody owns readiness
Design teams finish their artefacts and move on. Delivery teams are still finishing other work. The programme sits in between, owned by everyone and therefore by no one. A formal readiness gate, with named criteria, changes this immediately: it gives a date, an owner and a decision.
2. The plan belongs to one party
We often see an internal team and a supplier each produce their own activity list. Both are reasonable on their own. Together they double-count some work and miss other work entirely. The fix is simple but uncomfortable: put both lists in one room and build a single work breakdown that both sides sign.
3. Dependencies have no owner
Infrastructure, validation, data migration and procurement are usually outside the programme's direct control. If each dependency does not have a named owner and a date before funding is released, it becomes the reason for the first slip, and then the second.
A programme that cannot say who owns each dependency is not ready for build, however good the design is.
What good looks like
The programmes that move cleanly from design into delivery tend to share a few habits:
- A short, explicit "readiness for build" checklist reviewed at a gate, with the authority to say not yet.
- A single, jointly owned work breakdown structure with effort estimates both parties recognise.
- A delivery cadence agreed before the start, such as planning increments and fortnightly sprints.
- A risk and dependency register that is reviewed weekly, not quarterly.
- Plain-language reporting to the board: what happened, what is next and what we need from you.
Where to start this week
Pick the programme in your portfolio that has been "nearly ready" for the longest. Ask three questions: who owns readiness, is there one plan everyone has signed, and does every dependency have a named owner and a date? If any answer is unclear, that is where the next two weeks of effort should go.
At Forlanto we run short readiness reviews that answer exactly these questions and leave you with a reset plan. If a programme of yours is stuck between design and delivery, we would be glad to talk.
