Recovering a distressed program

By the time a program is formally acknowledged as distressed, the program owner is usually managing two problems at once: the program itself, and the loss of confidence among the bodies they answer to. Recovery is rarely a single corrective action. It is a structured reset of governance, technical truth, and decision-making discipline across the entire delivery ecosystem — and the owner who commissions that reset early, on their own terms, is in a materially stronger position than the one who waits for it to be imposed. 

Across Defence acquisition and sustainment environments including complex maritime sustainment and large-scale capability programs the pattern is consistent. Program distress is not caused by a single failure mode. It emerges from the compounding effect of weak requirements control, degraded configuration integrity, fragmented accountability, and the optimism bias embedded in reporting chains. No one of these would normally sink a program. Together, and left unexamined, they reliably do. 

This matters for how recovery is approached. A program owner under pressure is offered acceleration more resources, more reporting, a tighter schedule. But distress is not fundamentally a speed problem, and treating it as one deepens it. The first task is not to go faster. It is to find out, credibly and independently, where the program actually stands. 

Recovery begins with truth, not action

The first step in any genuine recovery is establishing technical and programmatic truth. Without a credible baseline — real scope, real configuration status, real cost-to-complete, and a schedule grounded in evidence rather than hope — every subsequent decision amplifies uncertainty rather than reducing it. Resources are committed against a picture that does not hold. The program owner ends up accountable for decisions made on numbers they had no reason to trust. 

This is also where the owner’s own exposure is greatest. The reporting chain that produced the optimism is rarely the chain that will surface the correction; it has every incentive not to. Re-establishing truth therefore usually requires a read from outside the delivery line — an independent, evidence-based assessment that owes nothing to the narrative that allowed the distress to accumulate. That independence is not a procedural nicety. It is the only thing that makes the resulting baseline defensible to the governance bodies now watching closely. 

What effective recovery requires

Once truth is established, effective recovery typically requires: 

1. Rapid reconstitution of governance and decision rights, so that authority is clear and decisions are actually made; 
2. Restoration of configuration and requirements integrity as the foundation everything else is rebuilt on; 
3. Independent schedule and cost validation, separated from the delivery line that produced the original estimates; 
4. Segmentation of scope into controllable, value-focused increments rather than a single unmanageable whole; 
5. Re-alignment of delivery, engineering, and sustainment functions toward a shared definition of success; 
6. Disciplined risk retirement rather than risk deferral — closing exposures rather than rescheduling them; and 
7. Clear accountability for system-level outcomes, not merely the completion of activity. 

In Defence environments specifically, recovery also depends on rebuilding trust between delivery authorities, engineering teams, operators, and industry partners. Where that trust has broken down, assurance becomes performative rather than corrective — forums report progress that the evidence does not support, and the program owner is left further from the truth, not closer to it. Restoring the conditions in which problems can be surfaced honestly is itself part of the recovery, not a precondition for it. 

The objective is control, not speed

Turning around a distressed program is not, in the end, about accelerating delivery. It is about restoring control over scope, over configuration, over risk, and over the velocity of decision-making so that execution becomes predictable again. A predictable program can be governed, defended, and reported with confidence. An unpredictable one cannot, regardless of how fast it appears to be moving. 

The most successful recoveries do one thing well: they replace narrative with evidence, and optimism with governed execution. That is also the hardest thing to do from inside a program already committed to its own account of itself, which is why the decisive move available to a program owner is often not to work harder on the program, but to commission an independent, structured read of where it truly stands — early enough that the options for intervention are still theirs to choose. 

So the question for any program owner sensing distress, but not yet ready to declare it, is a direct one: 

Chris Lindemann is the developer of the Program Integrity Method: a predictive systems-assurance methodology designed to identify the systemic conditions that historically precede delivery and sustainment failure in complex Defence and infrastructure programs.