In brief: A comparison of the main construction delay analysis methods, including time impact analysis, windows analysis, as-planned vs as-built and collapsed as-built, and how to choose one.
There is no single correct delay analysis method. The right choice depends on when the analysis is done, what programmes and records exist, what the contract requires and what question needs answering. This guide compares the methods most often used on construction projects, using the terms of the SCL Delay and Disruption Protocol and AACE International Recommended Practice 29R-03.
Prospective and retrospective analysis
A prospective analysis is carried out during the project to forecast the effect of an event on the completion date. It is the usual basis for granting an extension of time while work continues. A retrospective analysis is carried out after the delay has happened, often after completion, to establish what actually caused the delay to completion. Disputes are usually decided on retrospective analysis.
The main delay analysis methods
Impacted as-planned
Delay events are added to the baseline programme and the change in the planned completion date is measured. It is quick and needs only the baseline, but it ignores what actually happened on site, including the contractor’s own delays. Tribunals give it little weight for retrospective claims.
Time impact analysis (TIA)
Each delay event is modelled as a fragnet and inserted into the programme update current just before the event. The difference in completion date is the delay attributed to that event. TIA is the method the SCL Protocol recommends for assessing EOT during the project, and many contracts and owner specifications require it. Read more about our time impact analysis service.
Windows analysis (time slice)
The project is divided into periods, usually matching the programme updates. For each window, the critical path at the start and end is compared and the delay in that window is assigned to its causes. It uses the contemporaneous programmes, which makes it persuasive where the updates are reliable.
As-planned versus as-built
The planned and actual dates of activities are compared to find where the critical activities slipped. It can be simple (comparing bars) or detailed, with the critical path identified from records. It works well where the programme updates are unreliable but the as-built records are good.
Collapsed as-built (but-for)
An as-built programme is built from the records, then the delay events are removed to show when the work would have finished “but for” those events. It needs a full as-built programme with logic, which takes time to produce, and the result depends on the logic chosen.
Longest path analysis
The as-built critical path is traced backwards from actual completion through the activities that drove it. It is often used together with windows or as-planned versus as-built analysis. Our article on critical path vs longest path explains the difference.
Comparison at a glance
| Method | Timing | Main records needed | Typical use |
|---|---|---|---|
| Impacted as-planned | Prospective | Baseline programme | Early estimate of entitlement |
| Time impact analysis | Prospective or retrospective | Programme updates, event details | EOT during the project |
| Windows analysis | Retrospective | Reliable programme updates | Disputes, final accounts |
| As-planned vs as-built | Retrospective | Baseline and as-built dates | Disputes with weak updates |
| Collapsed as-built | Retrospective | Detailed as-built programme | Disputes where records are strong |
How to choose a method
- Check the contract first. Some contracts or schedule specifications name the method, for example TIA for each change.
- Check the programmes. If the baseline and updates are sound, windows or TIA are usually preferred. If they are not, as-planned versus as-built based on records may be more reliable.
- Check the question. An EOT application during the project asks for a forecast. A dispute after completion asks what actually caused delay.
- Check proportionality. The time and cost of the analysis should suit the value of the claim.
Whichever method is used, the analyst should test the programmes for logic errors, constraints and missing links before relying on them. A schedule health check is usually the first step.
Frequently asked questions
Which delay analysis method do tribunals prefer?
None is preferred in all cases. Tribunals look for a method that suits the facts and records, applied correctly and consistently. Methods that use contemporaneous programmes and actual progress are generally given more weight in retrospective disputes than impacted as-planned.
Can two methods be used together?
Yes. It is common to use one primary method and a second method as a cross-check, for example windows analysis checked against as-planned versus as-built.
What software is used?
Most delay analysis is carried out in Primavera P6, with Excel for as-built comparisons and charts. Microsoft Project is also used where the project programme was prepared in it.
Solvix carries out construction delay analysis and forensic schedule analysis for contractors, employers and legal teams.
