Two experts, one project, one delay. Ask them to quantify it and you can get answers forty days apart. Neither has lied. They have simply chosen different delay analysis methods: and the method, not the facts, moved the number.
That is the uncomfortable truth tribunals across India, the UAE, Oman and KSA now understand well. The Society of Construction Law Delay and Disruption Protocol identifies six recognised techniques, and choosing between them is the first substantive decision in any forensic delay analysis. Get it wrong and the analysis is vulnerable before it begins.
What are the recognised delay analysis methods?
Each method answers a slightly different question, and each demands a different quality of record.
- As-planned versus as-built. Widely used in practice alongside the Protocol’s six rather than being one of them. A visual, factual comparison of the intended programme against what actually happened. Records-light and intuitive, but it shows correlation, not causation. Strong for straightforward projects; weak where multiple causes overlap.
- Impacted as-planned. Delay events are added into the baseline programme to model their theoretical effect. Prospective and cause-led, but it relies entirely on a sound baseline and ignores what really happened on site. Tribunals treat pure impacted as-planned with caution.
- Collapsed as-built (but-for). Delay events are stripped out of the as-built programme to show what would have happened without them. Powerful where the as-built record is complete, but it requires a fully logic-linked as-built, rare, and often reconstructed after the fact.
- Time impact analysis. Delay events are modelled at the point they arose, using the programme current at that moment. The most contemporaneous and forward-looking method, and often contractually mandated, but data-hungry and sensitive to update quality.
- Time slice windows. The programme is divided into periods, and critical-path movement is measured window by window against updated schedules.
- As-planned versus as-built windows. A windows analysis driven by factual records rather than programme logic, useful where updates are sparse but progress data is good.
- Retrospective longest path analysis. The as-built longest path is traced back from actual completion to identify what in fact drove the finish date. Anchored in what happened rather than in a model, but it identifies the driving path rather than allocating responsibility, and it is weaker where criticality moved between paths.
Time impact analysis and the windows methods overlap in practice, and the choice between them turns on the state of your updates. We cover that distinction in detail in time impact analysis versus windows analysis.
Should the analysis be prospective or retrospective?
The deeper divide is one of viewpoint. Prospective methods, impacted as-planned, time impact analysis, model delay as it was foreseeable at the time, before hindsight. Retrospective methods: collapsed as-built, as-planned versus as-built, windows, measure what the record shows actually happened.
This matters because contracts and forums differ. Many FIDIC-based contracts, common across the Gulf, contemplate prospective assessment at the time of the event. Tribunals reviewing a completed project, by contrast, often prefer a retrospective method anchored in fact, they can see the as-built, so a model that ignores it looks academic.
The best method is the one the records can actually support. A sophisticated technique built on a reconstructed baseline is weaker than a simple comparison built on contemporaneous fact.
What does each method need from the evidence?
Before choosing, audit the evidence honestly.
Baseline quality
Impacted as-planned and collapsed as-built live or die on the baseline. If the accepted programme is poorly logic-linked or was never properly reviewed, both methods inherit that weakness. A schedule health check against DCMA-style metrics will tell you quickly whether the baseline can bear the load, see our note on the DCMA 14-point assessment.
Progress records
Windows and time impact methods need regular, reliable updates. Where updates are monthly and disciplined, time slicing is compelling. Where they are absent, you are pushed towards an as-built-driven approach or a records reconstruction.
Concurrency
Where employer and contractor delays overlap, method choice interacts with the law on concurrent delay. A windows approach isolates concurrency period by period far better than a single global comparison, as we explore in concurrent delay in month three.
What is the commonest mistake in choosing a delay analysis method?
The error we see most often is not technical incompetence. It is choosing the method that flatters the number rather than the one that fits the facts. An expert who reaches for impacted as-planned because it yields the largest entitlement, on a project with a full and reliable as-built, has built a claim that a competent opponent will dismantle.
Tribunals are increasingly alert to this. Method selection is now itself a battleground, and an analysis whose method was chosen for its answer rather than its fit carries that flaw into cross-examination. Our work on the Hafeet Rail EOT claims turned in part on selecting a method the contemporaneous record could defend without qualification.
Choose the method your records can support, disclose your assumptions, and let the analysis withstand scrutiny. If you are weighing an EOT claim and are unsure which technique fits your evidence, our risk intelligence tool is a sound place to pressure-test the position before you commit.
| Method | Viewpoint | What it does | Strengths and limits |
|---|---|---|---|
| As-planned versus as-built | Retrospective | A visual, factual comparison of the intended programme against what actually happened | Records-light and intuitive, but it shows correlation, not causation. Strong for straightforward projects; weak where multiple causes overlap |
| Impacted as-planned | Prospective | Delay events are added into the baseline programme to model their theoretical effect | Prospective and cause-led, but it relies entirely on a sound baseline and ignores what really happened on site. Tribunals treat pure impacted as-planned with caution |
| Collapsed as-built (but-for) | Retrospective | Delay events are stripped out of the as-built programme to show what would have happened without them | Powerful where the as-built record is complete, but it requires a fully logic-linked as-built, rare, and often reconstructed after the fact |
| Time impact analysis | Prospective | Delay events are modelled at the point they arose, using the programme current at that moment | The most contemporaneous and forward-looking method, and often contractually mandated, but data-hungry and sensitive to update quality |
| Time slice windows | Retrospective | The programme is divided into periods, and critical-path movement is measured window by window against updated schedules | Needs regular, reliable updates. Where updates are monthly and disciplined, time slicing is compelling |
| As-planned versus as-built windows | Retrospective | A windows analysis driven by factual records rather than programme logic | Useful where updates are sparse but progress data is good |
| Retrospective longest path analysis | Retrospective | The as-built longest path is traced back from actual completion to identify what in fact drove the finish date. | Anchored in what happened rather than in a model, but it identifies the driving path rather than allocating responsibility, and is weaker where criticality moved between paths. |