Programme recovery: rebuilding control when a project falls behind.

Diagnose the loss before prescribing recovery.

Programme delay is an outcome, not a single cause. The project may be losing time because information is late, decisions are unresolved, procurement is behind, access is restricted, predecessor works are incomplete, productivity is below plan, interfaces are blocked or the original programme was unrealistic.

Different causes require different responses. Adding labour to a workfront waiting for approved information will not recover time. Accelerating procurement will not help if the selected system is still under technical review. Re-sequencing may create apparent progress in one area while generating congestion or rework elsewhere.

A recovery exercise should therefore begin with evidence: verified progress, remaining quantities, actual productivity, design status, procurement status, decision logs, constraints, outstanding inspections and the physical condition of each major workfront.

Separate symptoms from root causes.

Low productivity can be a root cause, but it can also be a symptom. A crew may appear inefficient because it is repeatedly moved between incomplete workfronts, waiting for access or installing around missing information. If management responds only by increasing headcount, the same constraints can simply affect more people.

The recovery team should therefore distinguish direct production problems from the upstream conditions that create them. This is where project management, technical management, procurement and site supervision need to work from the same diagnosis.

Rebuild the programme around current reality.

A baseline programme describes an intended route. Once significant delay has occurred, parts of that route may no longer represent the conditions on site. The project needs to understand the remaining critical and near-critical paths from the current position.

This means reviewing actual progress, remaining durations, dependencies and available workfronts rather than simply shifting unfinished activities forward. Some activities may now be able to overlap. Others may require a different sequence because procurement, design or access conditions have changed.

The recovery programme should expose the logic clearly enough that management can understand what must happen for the target dates to remain achievable. If the recovery relies on several aggressive assumptions at once, those assumptions should be visible and assigned for active control.

Do not confuse compression with logic.

A recovery programme can look impressive because durations have been shortened and activities overlapped. That does not make it executable. Each compression measure should have a real basis: additional resources, revised method, changed sequence, parallel workfronts, prefabrication, earlier information or a different procurement route.

A credible programme can contain difficult targets. What makes it credible is that the route between the current position and those targets is technically and operationally possible.

Recovery depends on faster decision cycles.

Many delayed projects do not suffer only from slow physical production. They suffer from slow decisions. Technical queries wait for direction, substitutions wait for approval, commercial issues remain unresolved and design comments circulate through repeated review cycles.

When programme float has been consumed, the project can no longer afford the same decision times that may have been acceptable earlier. Recovery therefore needs an escalation structure that distinguishes routine actions from decisions that directly affect critical work.

Decision meetings should focus on issues that unlock work, with clear owners and required dates. Information presented for approval should make consequences visible: what happens to programme, cost or quality if the decision is delayed or if one option is selected over another.

Create a recovery decision register.

A short register of critical decisions can be more valuable than a long general action list. Each item should identify the decision required, the information available, the responsible authority, the date needed and the workfront affected. The register should be reviewed against the recovery programme, not in isolation.

Faster decision-making does not mean reducing technical discipline. It means removing avoidable waiting between the point at which a decision is ready and the point at which someone takes responsibility for it.

Protect executable workfronts.

Recovery becomes difficult when crews are repeatedly mobilised to areas that are not genuinely ready. Labour moves between zones, supervisors spend time solving access problems and productivity data becomes unreliable because teams are working around constraints rather than through a planned sequence.

A short-horizon readiness process can help. Before an activity enters the immediate execution window, the project should verify that the required information, preceding works, access, materials, labour, equipment, inspections and permits are available.

This creates a distinction between work that is planned and work that is executable. During recovery, that distinction matters because lost time cannot be regained through optimistic scheduling of blocked activities.

Use look-ahead planning to remove constraints early.

A three- to six-week look-ahead can be used to identify the specific constraints that must be closed before each critical activity becomes due. The objective is not to create another programme; it is to translate the master recovery logic into actions that site, design, procurement and management teams can close in time.

Where workfronts are limited, management may need to concentrate resources around the paths that protect completion rather than distributing labour evenly across the project.

Acceleration should be targeted, not universal.

Additional shifts, increased manpower, prefabrication, parallel working, alternative suppliers and sequence changes can all recover time. Each also carries cost, coordination and quality implications.

More labour can reduce productivity when areas become congested. Extended hours can increase supervision and inspection requirements. Parallel working can create interface risk. Alternative materials can trigger new technical approvals. Expedited freight can protect programme at a significant commercial cost.

The project should therefore evaluate acceleration against the constraint it is intended to remove. If the critical activity is genuinely production-limited, additional resources may help. If it is information-limited or access-limited, the same expenditure may produce little benefit.

The strongest recovery measures are specific: they identify the activity, the time expected to be recovered, the resources or decision required, the cost implication and the risks introduced by the measure.

Protect quality and safety while compressing time.

Recovery pressure can encourage teams to shorten inspections, close work before testing or push multiple trades into the same space. These measures can create rework that damages the very programme the project is trying to recover. Quality controls and safe access should therefore be considered part of the recovery logic, not obstacles to it.

Recovery requires tighter control after the plan is issued.

A recovery programme can lose relevance quickly if it is not connected to daily execution. Progress should be measured frequently enough to identify whether the recovery assumptions are actually being achieved.

Short-interval planning, daily constraint reviews, package-level dashboards and focused coordination can help management identify slippage before another reporting cycle is lost. The level of control should reflect the urgency of the project rather than adding reporting for its own sake.

Key recovery assumptions should also be measured directly. If the plan assumes a new productivity rate, verify it. If it assumes a supplier will deliver earlier, track the production evidence. If it assumes a client decision by a certain date, escalate before that date is missed.

The project should resist repeatedly rewriting the programme simply to match poor performance. A recovery plan is useful only if variance against it triggers management action.

Define the point at which the project leaves recovery mode.

Recovery should not become permanent crisis management. Once critical paths are stable, workfront readiness is reliable and progress is consistently meeting the revised plan, control can return to a more normal rhythm. The objective is to restore a predictable delivery system.