Forensic delay analysis: choosing your method before someone chooses it for you

Before anyone argues about a single delay event, the parties argue about how to analyse delay at all. Method choice is the first battleground of every dispute — and the analyst who understands why each method exists, and what records each one needs, walks into that fight with a considerable advantage.

The first question in every delay dispute

Walk into any adjudication, arbitration or litigation about delay and you will find two experts who agree on remarkably little — including, very often, the method by which delay should be measured. One has run a time impact analysis showing 14 weeks of employer delay. The other has run an as-planned vs as-built comparison showing six. Both are competent. Both used recognised methods. Neither is lying.

This is not a scandal; it is a structural feature of the discipline. Forensic delay methods are not interchangeable instruments measuring the same quantity. They are different questions asked of different evidence, and they can return genuinely different answers on the same facts. Which means that whoever frames the method question first — in the contract, in the tribunal's directions, or simply by getting a credible analysis on the table early — has, to a worrying extent, framed the answer.

Two documents dominate this territory: AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis, which classifies the methods; and the Society of Construction Law's Delay and Disruption Protocol (2nd edition, February 2017), which lists six and tells you how to choose between them. Read together they are less contradictory than people claim — but you do need a map.

The 29R-03 family tree, in plain language

RP 29R-03 organises every recognised method along three forks, and once you internalise them the whole landscape stops being a list of acronyms and becomes a logic tree.

• Observational vs modelled. Observational methods read schedules that already exist — the baseline, the updates, the as-built — and draw conclusions from what they show. Modelled methods build or modify a CPM model and run simulations: insert this event, remove that one, see what the engine says.
• Static vs dynamic (within observational). Static methods compare two pictures — usually the plan and the outcome — without recalculating anything. Dynamic methods follow the schedule through time, update by update, watching the critical path move and float recalculate.
• Additive vs subtractive (within modelled). Additive methods insert delay events into a schedule and measure how far completion moves. Subtractive methods remove them from an as-built model and measure how much earlier the project would have finished — the "but-for" question.

The nine MIPs by their everyday names

Observational static: 3.1 and 3.2

MIP 3.1 is the gross as-planned vs as-built comparison: lay the plan beside what happened, one period, whole project. The oldest method, the cheapest, and the one with the fewest places for sophistication to hide errors — or to hide anything else. MIP 3.2 is the same comparison done periodically, in windows, which restores some sensitivity to when delays occurred without requiring usable CPM updates.

Observational dynamic: 3.3, 3.4 and 3.5

These are the methods most people call windows analysis or time-slice analysis. MIP 3.3 takes the contemporaneous updates exactly as they are and reads critical-path movement out of them. MIP 3.4 does the same but splits each window's delay between causes within the update. MIP 3.5 is for the awkward middle ground: updates exist but are flawed, so the analyst modifies them, or recreates updates that never existed — defensible work, but every modification is a cross-examination question waiting to happen.

Modelled additive: 3.6 and 3.7

MIP 3.6 is the impacted as-planned: insert the delay events into the original baseline and watch completion move. One base schedule, no account of how the project actually progressed — which is why tribunals have grown cold towards it except in the simplest cases. MIP 3.7 is time impact analysis: the same insertion logic, but into the contemporaneous schedule current at the time of each event, multiple base schedules across the project. Far more credible, far more expensive.

Modelled subtractive: 3.8 and 3.9

MIP 3.8 is the collapsed as-built (or "but-for"): build a CPM model of what actually happened, remove the delays one party is responsible for, and see how much earlier the project would have finished. MIP 3.9 applies the same collapse in multiple windows. Both depend entirely on the quality of the as-built logic — which the analyst, awkwardly, has to construct.

The SCL Protocol's six, and how the maps align

The SCL Protocol's 2nd edition lists six methods: impacted as-planned, time impact analysis, time slice windows, as-planned vs as-built windows, retrospective longest path, and collapsed as-built. Crucially, it names no single preferred method — a deliberate change of emphasis from the 1st edition's enthusiasm for TIA. The choice, says the Protocol, depends on the records available, the time and cost of the exercise relative to the dispute, the contract terms, and whether the analysis is being done prospectively (while the project runs) or retrospectively (after the dust settles).

The two frameworks map onto each other comfortably, with one or two seams:

The SCL's retrospective longest path method has no tidy MIP number: it reconstructs the as-built critical path from the records and traces delay along it, sitting somewhere between the observational families. That seam bothers taxonomists more than it bothers tribunals.

What actually decides the method

In practice four criteria do almost all of the work, and the first is brutally simple.

1 · What records exist

No contemporaneous updates means the observational dynamic family — the whole windows/time-slice branch — is dead on arrival, whatever its theoretical merits. Recreating updates under MIP 3.5 is possible but expensive and contestable. This is why baseline and update discipline during the project is really a dispute-readiness discipline wearing a project-controls badge: the records you keep in month 6 decide which methods you can afford in year 3.

2 · Prospective or retrospective

An EOT application made during the project is a forecast: what will this event do to completion? That is what additive modelling — TIA in particular — was built for. A dispute after completion is a history question: what did happen, and why? There the observational methods, which privilege what the records actually show over what a model predicts, tend to carry more weight.

3 · Proportionality

A full multi-base TIA or a windowed collapse can occupy an analyst for months. A £50k final-account squabble does not fund a six-month forensic exercise, and the SCL Protocol says so in terms: the method must be proportionate to the amount in dispute. There is no shame in a well-documented as-planned vs as-built on a small claim. There is considerable shame in spending more on the analysis than the claim is worth.

4 · What the tribunal expects

Adjudicators want something digestible in 28 days. Arbitrators and judges have time for methodological rigour and a settled scepticism about impacted as-planned. Some contracts mandate a method outright — in which case the first three criteria are commentary. Read the contract before reading the schedules.

The uncomfortable truth

Different methods give different answers on the same facts. Not occasionally — routinely. An impacted as-planned ignores everything the contractor did wrong; a collapsed as-built can quietly absorb employer delay into the as-built logic; windows analysis splits the difference period by period. This is precisely why opposing counsel cross-examine on method choice before they ever reach the delays themselves: if they can show you chose the method that flattered your client — rather than the method the records best supported — your numbers are damaged before they are examined.

It also explains why schedule quality is upstream of everything in this field. A baseline that fails half the DCMA 14-point checks cannot anchor a TIA; updates with broken logic cannot carry a windows analysis; and arguments about concurrency or float ownership presuppose a network that calculates honestly. Method choice is the first battleground, but schedule quality decides what weapons reach the field at all.