On any large capital project, delay is rarely caused by a single event. It builds from overlapping causes — late design, a change in scope, a slow approval, a subcontractor who under-performed, weather, a client decision that arrived three weeks late. By the time the programme has slipped, the causes are tangled together and memories have started to diverge.
Forensic delay analysis is the discipline of untangling that. It reconstructs what happened on a project, in what order, and establishes which events actually drove the completion date — as opposed to the events that were merely noise around it. Done well, it turns a contested, emotional argument about blame into a structured, evidence-based account that a contract administrator, an adjudicator or a tribunal can follow.
When you actually need it
Not every delay needs a forensic study. You reach for one when the delay has commercial consequences and the cause is contested. Typical triggers include:
- An extension of time (EOT) claim — you need to show that a delay was caused by an event the contract makes the client responsible for.
- Defending against liquidated damages — the client is charging you for lateness and you need to demonstrate how much of it wasn't your fault.
- A dispute heading to adjudication, arbitration or court — where the analysis has to withstand cross-examination.
- Project recovery — even without a claim, understanding the true drivers of slippage is the first step to getting a programme back under control.
The question forensic analysis answers is narrow but decisive: which events moved the finish date, and who was responsible for them?
The main methods
There is no single "correct" method. The right choice depends on the records available, the contract, and whether you are proving delay prospectively (as it was expected to unfold) or retrospectively (as it actually did). The recognised techniques — set out in the Society of Construction Law's Delay and Disruption Protocol — fall into a few families.
As-planned versus as-built
The simplest approach: lay the original baseline programme next to what actually happened, and identify where and why the two diverged. It is intuitive and easy to explain, but it is also the least rigorous — it shows that delay occurred more than it proves what caused the critical slippage.
Impacted as-planned
Here you take the baseline programme and insert the delay events into it, then let the logic recalculate the completion date. It isolates the theoretical effect of specific events, but because it ignores how the project actually progressed, it can produce results that don't match reality.
Time impact analysis
A more robust, prospective method. You model each delay event at the point in time it occurred, against the programme as it stood at that moment, and measure its effect on the then-predicted completion date. It respects the sequence of events and is well suited to contemporaneous EOT assessment — but it demands good, regularly updated programmes.
Windows and collapsed as-built
Retrospective methods that divide the project into time "windows" and analyse the critical path within each, or start from the as-built record and remove delay events one at a time to see what the completion date would have been "but for" them. These are powerful in dispute but rely heavily on the quality of the as-built data.
Most delay claims are not won or lost on the choice of method. They are won or lost on the quality of the underlying records. An elegant analysis built on thin, inconsistent data will not survive scrutiny; a straightforward one built on solid contemporaneous evidence usually will.
What separates credible analysis from a weak one
The method gets the attention, but the credibility comes from elsewhere:
- A defensible baseline. If the original programme was unrealistic or never properly agreed, everything built on it is contestable.
- Contemporaneous records. Progress reports, correspondence, minutes and dated programme updates written at the time carry far more weight than a narrative reconstructed afterwards.
- Honest treatment of concurrency. When client-caused and contractor-caused delays overlap, pretending otherwise destroys credibility. Addressing concurrency openly builds it.
- Critical-path discipline. Only delays to the critical path move the finish date. A rigorous analysis keeps that distinction clean rather than counting every disruption as if it mattered equally.
The real lesson: it starts long before the dispute
The projects that handle delay well are the ones that were set up to be analysed — a properly baselined programme, updated on a regular cadence, with an audit trail of change and correspondence kept as the work happened. Forensic analysis is easiest, cheapest and most convincing on a project that maintained good controls all along. On a project that didn't, the analyst spends most of the budget just reconstructing what should already have existed.
That is why forensic delay analysis and everyday project controls are two ends of the same discipline. Strong controls during delivery are, in effect, an insurance policy against the day you need to prove what happened.