When a programme is declared off-track, the instinct is to escalate, reorganise and replan. In my experience, the first 48 hours should be spent doing something different entirely.
Programmes get into trouble for many reasons, but they all share a common symptom: the picture becomes clearer the closer you are to the delivery. The people at the top see red RAG statuses and missed milestones. The engineers at the bottom know exactly what is wrong and why.
What the first 48 hours should actually look like
The first 48 hours should be spent reading everything: the original HLD, the current LLD, the change log (if one exists), the programme risk register, and any previous review or assurance reports. Not to form conclusions — to understand the gap between what was designed and what is being built.
Programme managers will tell you about milestones. Engineers will tell you about reality. In those first 48 hours, I spend as much time as possible with the engineers. Not in workshops. Not in status meetings. In direct, informal conversations about what is actually happening.
The three questions that matter
After 21 years of infrastructure programme delivery and recovery, I have learned that almost every programme failure can be traced to the same three questions not being answered honestly:
Is the design actually fit for purpose? Not whether it was approved — whether it will work in production, at scale, under the conditions the business actually operates in.
Does the delivery team have what they need? Not whether the project plan says they should — whether they actually have the skills, the access, the environments and the clarity of requirement to deliver what is expected of them.
Does anyone have an accurate picture of where things really are? Not the RAG status in the programme report — the actual technical state of the implementation and the real gap between current state and go-live readiness.
What recovery actually requires
Programme recovery is not primarily a project management exercise. It is a technical exercise. The root cause of most infrastructure programme failures is a design problem — either the original design was flawed, or the implementation has diverged from the design, or both.
Identifying and fixing that technical root cause is what makes recovery possible. Reorganising the governance structure, re-baselining the plan and running more frequent status meetings does not fix a design problem. It just makes the failure more visible and better documented.
What recovery actually requires is an honest assessment of the technical state, a clear understanding of the gap between current state and a viable go-live position, and a realistic plan for closing that gap. Not an optimistic plan. Not a plan that tells the board what they want to hear. A plan that reflects what is actually achievable.
The role of independent assessment
One of the reasons programme recovery is difficult is that the people closest to the delivery are often the least well-placed to assess it objectively. They are under pressure, they are invested in the decisions that have already been made, and they may have been telling the programme board that things are better than they are.
Independent assessment removes that constraint. I have no stake in the decisions that led to the current position. I have no relationship with the vendors whose products are causing problems. I have no interest in any particular outcome other than whether the programme can recover to a viable go-live position.
That independence is not just useful — it is often the only way to get an honest picture of where a programme actually is. And without an honest picture, recovery is not possible.
Slow down. Establish the facts. Only then build the plan.
- The root cause is almost always in design, not delivery. Delivery teams get blamed for programme failures that were baked in at architecture stage. The implementation was fine — what it was implementing was not.
- The first 48 hours are wasted on escalation rather than assessment. Senior stakeholders want action plans before anyone has established the facts. Visible activity substitutes for diagnosis.
- Recovery plans are built around activity, not outcomes. Lists of workstreams and RAG statuses that tell you what people are doing — but not whether any of it moves the programme toward recovery.
- The programme team already knows what is wrong. In almost every recovery engagement, the people closest to the delivery have identified the core problems. They have not been asked — or have not felt safe to say.
- Scope has drifted without formal change control. What is being delivered bears little resemblance to what was signed off. The gap is rarely documented, rarely costed and rarely acknowledged.