When a programme is declared off-track, the instinct is to escalate, reorganise and replan. In my experience - as a CCDE and CCIE certified consultant who has spent 21 years working at the intersection of engineering and programme delivery - the first 48 hours should be spent doing something different entirely. Reading the designs.
Most programme failures are not project management failures. They are network and security design failures. The routing architecture does not support the traffic model. The firewall policy contradicts the segmentation design. The LLD has diverged from the HLD and nobody has formally documented what changed or why. These are technical problems, and they require a technical diagnosis before any recovery plan can be meaningful.
What the first 48 hours should actually look like
Most programme failures are not project management failures. They are network and security design failures - and they require a technical diagnosis before any recovery plan can be meaningful.
Before any workshop, stakeholder meeting or re-baseline conversation, I read 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.
Then I talk to the engineers. Not in workshops. Not in status meetings. In direct, informal conversations about what is actually happening at the network and system level. Engineers know exactly what is wrong. They have usually known for some time. They have not always felt safe to say so - or nobody with the right technical background has asked the right questions.
The technical questions that matter
After 21 years of network and security programme delivery and recovery, I have found that almost every failure traces back to the same technical questions not being answered honestly before implementation began:
Is the network design actually fit for purpose? Not whether it was approved - whether the routing, switching, segmentation and security architecture will support the traffic patterns, failover requirements and compliance obligations the business actually operates under.
Does the LLD deliver what the HLD promised? In a significant proportion of troubled programmes, the Low-Level Design has drifted materially from the approved High-Level Design. The drift is rarely documented. The technical implications are rarely understood by anyone outside the engineering team.
Is the implementation technically achievable with the current design? Some designs look credible on paper but cannot be implemented as specified - because of hardware constraints, vendor limitations, environmental dependencies, or timing conflicts that only become visible when you read the LLD alongside the implementation plan.
The bridge between engineering and the boardroom
One of the reasons programme recovery is difficult is that the people with the technical picture - the engineers - are rarely the people presenting to the board. And the people presenting to the board rarely have the technical depth to know whether what they are presenting is accurate.
The engineers know exactly what is wrong. They have usually known for some time. They have not always felt safe to say so - or nobody with the right technical background has asked the right questions.
My role in recovery is to close that gap. I can read a Cisco routing configuration and identify a design flaw. I can also stand in front of a CTO or IT Director and explain, in plain language, what that flaw means for the programme - what the risk is, what the remediation requires, and what a realistic recovery timeline looks like.
That combination - CCDE and CCIE certified technical depth, with the communication skills to translate it clearly for non-technical stakeholders - is what makes recovery possible when a programme has lost trust in its own reporting.
What recovery actually requires
Technical recovery is not a project management exercise. Re-baselining the plan, reorganising the governance structure and running more frequent RAG status meetings does not fix a routing design problem. It documents the failure more carefully.
What recovery requires is an honest technical assessment, a clear identification of the root cause at the design level, and a realistic remediation plan that the engineering team can actually implement. Not an optimistic plan. Not a plan built to give the board what they want to hear. A plan grounded in what the network and security architecture can actually support.
Slow down. Read the designs. Talk to the engineers. Only then build the plan.
- The root cause is almost always in the network or security design, not the delivery. Delivery teams get blamed for failures that were baked in at architecture stage. The implementation was executed correctly - what it was implementing was not fit for purpose.
- The LLD has diverged from the HLD without formal change control. What is being built bears little resemblance to what was approved. The gap is undocumented, uncosted and unacknowledged.
- The engineers already know what is wrong. In almost every recovery engagement, the people closest to the implementation have identified the core technical problems. They have not been asked by someone with the right credentials - or have not felt it was safe to say.
- Nobody has read both the HLD and the LLD end to end. Particularly not someone with the technical depth to identify the discrepancies between them and understand what those discrepancies mean in production.
- The board is working from a picture that does not reflect technical reality. RAG statuses and milestone reports describe the programme management view of the programme - not the engineering view. Closing that gap is where recovery begins.