Director's Field Notes

Director's Field Notes · Part 4 of 10

What I Check Before I Trust a Contractor's Recovery Programme

A recovery programme is a claim about the future. Before I let it change how the job is run, I test whether the mechanics behind it are real — or whether the dates were simply pulled left.

By Rishi JaveriPublished 29 Jul 20265 min read

A recovery programme lands showing the job back on the contractual date. That is the promise. My job is to find out whether it is a plan or a picture — and the difference is entirely in the mechanics.

Here is what I go through before I trust it.

The logic, before the dates. I do not start with the completion date; I start with the network. Has logic been relaxed to make the date work — Finish-to-Start relationships quietly changed to Start-to-Start, negative lags introduced, activities overlapped that cannot physically overlap? A recovery that is achieved by loosening logic rather than by doing the work faster is not recovery; it is arithmetic.

Remaining durations. Where durations have been shortened, I ask for the basis. A duration halved with no change in method, crew or shift pattern is a hope, not a plan. If the original 20-day activity is now 10 days, something real has to have changed to make it 10 — and if nothing has, the recovery rests on that activity failing to take the time it needs.

Resources. More work in less time needs the people, plant and materials to do it. I look at whether the resource histogram behind the recovery is achievable — whether the peak the recovery assumes has ever been reached on this job, whether the labour is actually available, whether long-lead materials will be on site when the compressed sequence needs them. A recovery that assumes a productivity or a resource level the project has never achieved is assuming its way to the date.

Constraints and calendars. I check whether the recovery date is held by real logic or by a constraint dropped onto the completion milestone. And I check the calendars — a recovery that only works because someone quietly added weekend and night working needs that working to be real, resourced and permitted, not just typed into a calendar.

The critical path and float. Then I look at the driving path of the recovered programme. Does it make engineering sense, or does it now run through improbable activities because the real critical path was compressed until something else became critical? And has all the float been stripped out to make the date — leaving a programme with no room to absorb the next problem, which on a job that is already behind is a near-certainty?

Evidence of achievability. Finally, the question underneath all the others: is there any evidence that this rate of recovery is achievable? The most honest test is the job’s own record. If the contractor could not achieve the planned rate when things were going well, a recovery that assumes a higher rate now that things are going badly deserves real scepticism.

None of this is about rejecting recovery programmes. A genuine, resourced, method-backed recovery is exactly what you want to see, and it should be supported. It is about not letting a cosmetic one quietly become the baseline everyone then measures against — because a recovery programme that is accepted without this scrutiny does not recover the job. It just resets the argument to a date that was never real, and buries the slippage that is still there.

The takeaway: a recovery programme is only as credible as the mechanics behind the dates. Test the logic, the durations, the resources and the critical path against the job’s own record before you let the new dates change how the programme is run. See how this sits in the wider method in the Director’s Playbook and Forecast Integrity.

Rishi JaveriProject Controls Director · FCIArb · PMP · PSP · MCIOB · MAPM