When a project finishes late, someone pays — through liquidated damages, prolongation costs, or both. Delay analysis is the discipline of proving who caused which delay and how much it mattered. The method you choose can swing a claim by crores.
The main methods
| Method | Type | Needs | Typical use |
|---|---|---|---|
| Impacted As-Planned | Prospective | Baseline only | Early, simple claims |
| Time Impact Analysis (TIA) | Prospective | Baseline + updates | During the project |
| Windows / Time Slice | Retrospective | Regular updates | Complex, contested claims |
| As-Planned vs As-Built | Retrospective | Baseline + as-built | Records-poor projects |
| Collapsed As-Built | Retrospective | Good as-built | "But-for" arguments |
Impacted As-Planned
Insert delay events into the unimpacted baseline and measure the shift in completion. Simple and cheap, but widely criticised because it ignores actual progress and concurrent delays — the baseline may bear no resemblance to what really happened. Weak in formal disputes.
Time Impact Analysis (TIA)
Insert the delay event into the updated schedule current at the time the delay arose, and compare completion dates before and after. This is the method most standard forms (and the SCL Protocol for prospective analysis) favour for assessing extensions of time as events occur.
The discipline it demands — a well-maintained, regularly updated schedule — is exactly why it's respected.
Windows / Time Slice Analysis
Divide the project into windows (usually monthly updates). In each window, identify the critical path as it actually was, measure the slippage, and attribute causes. The most forensically robust method for retrospective analysis, and the one most likely to survive expert cross-examination — but it needs consistent schedule updates and good records.
As-Planned vs As-Built
Compare the baseline against the as-built programme and reason about the differences. Best when schedule updates don't exist. Its credibility depends heavily on the quality of as-built records and the analyst's logic — it can drift into advocacy.
Collapsed As-Built ("but-for")
Take the as-built schedule, remove the delays attributable to one party, and see when the project would have finished. Intuitive to tribunals but sensitive to how the as-built logic is reconstructed — small logic choices produce big swings.
Choosing in practice
- During the project, assessing an EOT request → TIA.
- After completion, with good monthly updates → Windows analysis.
- After completion, with poor records → As-Planned vs As-Built (and manage expectations).
- Rebutting a claim → often Collapsed As-Built to show the "but-for" date.
Concurrent delay: the hard part
When employer and contractor delays overlap, jurisdictions differ. The common English-law position: the contractor gets time but not money for the concurrent period. Whatever the position, you can only argue it with contemporaneous records — daily reports, photos, correspondence, and schedule updates.
The best delay analysis is the one you never need to do retrospectively: update the schedule monthly, record impacts as they happen, and notify on time.
Estimate first-order impacts with our Delay Impact Calculator, and see the SCL Delay and Disruption Protocol and AACE RP 29R-03 for authoritative guidance.