The delivery challenge
The programme was not short of meetings, trackers or updates. The issue was that those mechanisms were not consistently converting open items into owned decisions and measurable delivery outcomes. Dates moved, dependencies were discussed repeatedly, and some milestones were marked as progressing even though prerequisite work was still unresolved.
The result was a familiar pattern: teams were busy, stakeholders were receiving frequent status, but confidence in the forecast was weakening.
What had to change
The recovery needed to make the programme easier to run, not add another management layer. Governance therefore had to become lighter, more explicit and closer to the actual critical path.
The approach
1. Re-baseline around outcomes
The plan was stripped back to the deliverables that actually changed programme readiness. Activity that did not unlock a downstream milestone was separated from critical-path work.
2. Make dependencies explicit
Cross-team dependencies were mapped directly into the schedule and RAID view. Each dependency had an owner, required-by date and consequence if missed, allowing escalation to happen before rather than after a milestone slipped.
3. Tighten ownership
Open items were assigned to named accountable owners rather than broad teams. Where ownership crossed functions, one person remained responsible for driving the outcome while contributors retained their functional responsibilities.
4. Separate decisions from actions
A decision log was used alongside the action tracker. This prevented unresolved scope or design questions from being disguised as normal tasks and made leadership intervention more targeted.
5. Define acceptance criteria
Milestones were no longer considered complete because an activity had taken place. Completion required evidence: a validated output, approved decision, signed-off test, completed handover or other explicit acceptance condition.
6. Redesign governance around exceptions
Working-level forums focused on resolving blockers. Senior forums focused on material risks, delivery confidence, decisions and support required. This reduced repetitive reporting and increased the value of each governance layer.
What the recovery model achieved
Sharper critical path
The programme could distinguish genuine delivery blockers from background activity.
Clearer accountability
Issues and dependencies had explicit owners and required-by dates.
Earlier escalation
Risks were surfaced when intervention could still change the outcome.
More credible forecasting
Milestones were tied to evidence and dependencies rather than optimistic status.
What was learned
Programme recovery is rarely achieved by producing a more detailed plan alone. It comes from changing how the programme makes decisions, validates completion, manages dependencies and escalates exceptions. Once those behaviours improve, the schedule becomes more useful because it reflects the real conditions of delivery.
What we would carry into a similar engagement
- Rebuild the plan around outcomes before adding more detail.
- Give every critical dependency an owner and required-by date.
- Track decisions separately from normal actions.
- Use acceptance criteria to define what "done" actually means.
- Escalate exceptions with a clear ask, not just a status description.
- Keep governance proportionate to the decisions it needs to make.