Guide · Delay analysis
Windows analysis vs Time Impact Analysis: which method, and when
Both methods are recognised and both use the critical path. They answer different questions: a Time Impact Analysis shows what an event was expected to do to completion, a windows analysis shows what actually happened to completion. Strong claims often use both.
The short answer
| Windows analysis | Time Impact Analysis | |
|---|---|---|
| AACE 29R-03 | MIP 3.3 / 3.4 - observational, dynamic | MIP 3.7 - modelled, additive, multiple base |
| Question answered | How much did completion actually move in each period, and why? | How much would this event delay completion, given the programme at that time? |
| Main input | Baseline and the series of programme updates | The update before the event, plus a fragnet modelling the event |
| Typical timing | During or after the project, using contemporaneous records | At the time of the event (prospective), or retrospectively event by event |
| Strengths | Based on the programmes the parties used; captures progress, mitigation and concurrency | Clear cause and effect for each event; suits contractual EOT applications |
| Weaknesses | Needs reliable updates; revisions must be separated (half-step) | The result is a forecast; it may differ from what actually happened |
How a Time Impact Analysis works
The analyst takes the last accepted update before the event, adds a fragnet (a small network of new activities and links that represents the event) and recalculates. The difference in the forecast completion date is the impact of that event. For several events, the process is repeated on the update before each event.
The SCL Delay and Disruption Protocol (2nd edition) recommends that extension of time applications are made and assessed as close as possible to the time of the delay event, which is why a prospective TIA is common for contemporaneous applications under the contract.
How a windows analysis works
The project is divided into windows between programme updates. In each window, the movement of the forecast completion date is measured, the critical path is examined, and the delay is linked to events and allocated. With the half-step (MIP 3.4), the effect of progress is separated from the effect of changes to the programme. See Windows analysis explained for the full process.
Which one to use
- Applying for an extension during the project: a TIA on the event, using the current update, is usually expected.
- A claim after the events, with good monthly updates: a contemporaneous windows analysis is usually the most persuasive, because it reflects what actually happened.
- Several overlapping events and a disputed critical path: windows analysis, supported by a TIA for the main events, shows both the expected and the actual effect.
- Poor or missing updates: neither method works well without reliable programmes. The updates may need to be reviewed or recreated, and the method chosen to suit the records.
Using both: the cross-check
When a TIA predicts a delay of a similar size to the delay found in the windows, the claim is stronger: the event was expected to delay completion, and completion did move by that amount in that period. When the numbers differ, the difference needs an explanation, for example mitigation, acceleration, concurrent contractor delay or a change in the critical path. Showing both, and explaining the difference, answers the questions a reviewer is likely to ask.
Whatever the method
- Follow the contract: the method, the notice requirements and any time bars.
- Check the programmes before analysing them, and record what you changed.
- Link every delay to evidence: notices, instructions, letters and minutes.
- State how concurrency is treated, and apply it consistently.
This guide is general information about recognised practice. It is not legal advice; the contract and the facts of each project decide what applies.
Chronaxis Claim runs the windows analysis with half-step and cross-checks it with a Time Impact Analysis using fragnets.
Join the founders list