Forensic delay analysis is the process of working out, after the fact, what actually caused a project to finish late and how much of that delay a contractor is entitled to have added to the completion date. It sits on two legs: a technical method for measuring the delay in the programme, and a contractual mechanism (FIDIC's claims clauses, in most international contracts) for turning that measurement into an entitlement. Get either leg wrong and the claim fails, no matter how strong the other one is.
Most guidance online covers the methods well and stops there. This post covers both, and the bit in between that decides whether either matters: whether your programme was good enough to analyse in the first place.
What Is Forensic Delay Analysis?
It's retrospective (sometimes prospective) examination of a construction programme to establish cause, effect and quantum of delay to completion. "Forensic" doesn't mean litigation-only. The same techniques run inside a live project to support a monthly EOT submission, inside adjudication, or inside full arbitration under an ICC or DIAB clause.
Two bodies of guidance dominate the field internationally. The Society of Construction Law's Delay and Disruption Protocol (2nd edition, February 2017) sets out the legal and contractual framework and the methods it recognises. AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis, gives the technical taxonomy: nine Method Implementation Protocols, grouped by whether they observe the existing programme or model a hypothetical one, and by whether they work forwards from the delay event or backwards from the outcome.
Planned works across FIDIC-governed programmes for international clients as well as NEC and JCT contracts in the UK, and the pattern repeats everywhere: the method is rarely the weak point. The programme underneath it is.
Which Methods Do the SCL Protocol and AACE RP 29R-03 Recognise?
At a practical level, four methods cover most real claims:
Impacted As-Planned. Insert the delay event into the original baseline and see how far the finish date moves. Fast, cheap, and prospective, which is exactly why the SCL Protocol treats it with caution: it ignores everything that actually happened on site after the baseline was set, including the contractor's own float consumption and any culpable delay running in parallel.
Time Impact Analysis (TIA). Insert the delay event into the last accepted programme update before the event occurred, then measure the impact from there. The SCL Protocol's preferred method where the contract calls for prospective assessment and the programme updates are contemporaneous and reliable. It needs a properly maintained, logic-linked programme at every update; a schedule with broken logic or unexplained constraints will not support it.
Windows Analysis. Break the whole programme duration into consecutive windows, usually matched to progress update periods, and identify which activities drove the critical path in each window. Good where delay is spread across the project and concurrency needs untangling window by window, rather than assumed away.
Collapsed As-Built. Take the as-built programme and strip out the delay events one at a time to see what the finish date would have been without them. Purely retrospective, and only as good as the as-built data. Where daily records are thin, this method produces a number nobody can defend.
None of these methods is universally "correct." AACE RP 29R-03 is explicit that method choice depends on the data available, the contract's timing requirements and the purpose of the analysis (interim submission versus final account versus tribunal). Picking a method because it's familiar, rather than because it fits the record, is one of the most common reasons an EOT claim gets rejected or heavily discounted.
What Does a FIDIC Extension of Time Claim Actually Require?
The technical method only earns you an entitlement if the contract lets it. Under FIDIC's Red Book, both the 1999 and 2017 editions set a 28-day notice period, running from when the contractor became aware, or should have become aware, of the event giving rise to the claim. In both editions that notice period is a condition precedent: miss it, and the entitlement to time and money is lost, regardless of how sound the delay analysis behind it turns out to be.
The 1999 form (Sub-Clause 20.1) then gives 42 days for a fully detailed claim. The 2017 form (Sub-Clause 20.2) extends that to 84 days but tightens what the detailed claim must contain: a description of the event, the contractual or legal basis relied on, contemporary records, and supporting particulars of the time and money claimed. The 2017 edition also extends the process to the Employer's claims rather than leaving it Contractor-only, and it puts new obligations on the Engineer to flag a defective notice. A late notice isn't automatically fatal the way it usually was in 1999.
None of this changes the forensic method itself. It changes when the analysis has to be ready, and what records have to exist to support it. A TIA prepared to accompany a Sub-Clause 20.2 notice needs the accepted programme update from the relevant period sitting ready to go, not reconstructed under pressure 80 days later.
For UK NEC3/4 contracts the entitlement mechanism is different (compensation events, assessed against the Accepted Programme under Clause 63), but the same forensic principle holds: the quality of the programme you're measuring against determines whether the assessment survives scrutiny. Our NEC4 Programme Requirements guide covers that mechanism in detail.
Why Do So Many EOT Claims Fail on the Programme, Not the Law?
Because the analysis is only as reliable as the programme it's built on, and most working programmes have never been checked against a quality standard. This is where the DCMA 14-point assessment earns its keep well outside its US federal-contracting origin: broken logic, excessive constraints, negative float and missing critical path links don't just make a schedule hard to read day to day. They make any downstream delay analysis built on it contestable. A time impact analysis run against a programme with dangling activities and hard constraints in place of logic links can be picked apart by the other side before anyone even argues about causation.
Practically, that means the best time to prepare for a future EOT claim is before there's a dispute to fight. A programme that's routinely health-checked, logically sound and updated to reflect actual progress produces contemporaneous records that make Time Impact Analysis and Windows Analysis straightforward instead of forensic archaeology.
How Does Concurrent Delay Change the Analysis?
Concurrent delay, where an employer-risk event and a contractor-risk event both affect the critical path over the same period, is where most disputes are actually won or lost, and it's where methods diverge most sharply between jurisdictions. The SCL Protocol's position (the "but-for" test applied to net effect) is not universally followed; some jurisdictions and some contract drafting apportion time, others don't extend time for genuinely concurrent delay at all. This is a legal question as much as a technical one, and it's exactly why the forensic analyst and the contract's governing law need to be read together rather than treated as separate exercises. Windows Analysis tends to handle concurrency more transparently than a single global comparison, because it isolates which event was actually driving the critical path in each period rather than assuming one applies throughout.
Getting the Programme Right Before You Need the Claim
A defensible EOT claim starts with a defensible programme, not with the delay event. Planned works with project teams internationally, largely FIDIC-governed and delivered remotely, and with UK teams on NEC3/4 and JCT contracts, to build and maintain programmes that hold up to DCMA-standard scrutiny long before a dispute is on the table, and to run the forensic analysis itself when one is. Our project controls service covers ongoing programme health and change control; see our Primavera P6 consultant page for schedule build, recovery and forensic support.
Book a Free Consultation to talk through a live or anticipated EOT situation, or to have a programme reviewed before you rely on it for a claim.
Frequently Asked Questions
What's the difference between forensic delay analysis and a delay claim?
Forensic delay analysis is the technical exercise of measuring what caused delay to the critical path and by how much. A delay claim, or EOT claim, is the contractual submission that uses that analysis to seek additional time (and often money) under the specific contract's claims clause. You need both: a sound method won't succeed without meeting the contract's notice and substantiation requirements, and a compliant notice won't succeed without evidence to back it.
Which forensic delay analysis method is best?
There isn't a single best method. AACE RP 29R-03 and the SCL Protocol both tie method choice to the timing of the analysis (prospective or retrospective), the purpose (interim assessment, final account, or tribunal) and, above all, the quality and completeness of the programme records available. A Time Impact Analysis run on thin records is weaker evidence than a Windows Analysis run on a well-maintained set of monthly updates.
Do I need a forensic delay expert for every EOT claim?
Not for every claim. Straightforward, single-cause delays with clear contemporaneous records can often be assessed without a full forensic exercise. Complex, multi-event or concurrent delay situations, and anything heading toward adjudication or arbitration, generally warrant a proper method-based analysis, because the informal version rarely survives challenge.
What happens if I miss the FIDIC 28-day notice period?
Under both the 1999 and 2017 Red Book, the notice period operates as a condition precedent, so missing it can extinguish the entitlement to time and cost regardless of how strong the underlying delay analysis is. The 2017 edition introduced obligations on the Engineer around defective notices that give some limited protection, but the safest position is always to issue notice within 28 days of becoming aware of the event and build the detailed substantiation afterwards.
Can concurrent delay defeat my EOT claim?
It can reduce or complicate it rather than defeat it outright. The outcome depends heavily on the contract's governing law and drafting; the SCL Protocol's default position is a starting point, not the final word. This is exactly why concurrent delay periods need careful, method-based analysis, Windows Analysis in particular, rather than a broad assumption either way.