When a project delay is disputed, the analysis method chosen shapes the credibility of the result as much as the result itself. The two most widely used and recognised approaches (including under the SCL Protocol) are Time Impact Analysis (TIA) and Windows Analysis. They don't answer the same question.
Time Impact Analysis: measuring impact at the point of the event
TIA is a prospective method: it inserts a disruptive event (a late delivery, a design change, a site stoppage) into the schedule as it existed just before that event, then measures its impact on the critical path finish date by recalculating the schedule. The exercise is repeated for each significant event, in chronological order.
Its strength: it isolates each event's contribution precisely, which makes it well suited to claims built event by event. Its limitation: it requires a good-quality baseline schedule at every step, which assumes regular, reliable updates to the original schedule — a condition that isn't always met on the ground.
Windows Analysis: comparing planned vs actual, period by period
Windows Analysis retrospectively splits the project duration into successive time windows (monthly, for example) and compares, for each window, the planned schedule at the start of the period with actual progress recorded at the end of it. The critical path slippage observed in each window is then attributed to the causes identified during that period.
This method is more robust when the schedule's update history is incomplete, since it relies on spaced measurement points rather than a recalculation at every event. It does, however, require a more interpretive causal attribution exercise, often a source of disagreement between parties.
The real selection criterion: available data, not preference
The choice shouldn't be made upfront. It depends on what's actually available: a complete history of periodic schedule updates points toward Windows Analysis; precise, dated documentation of each disruptive event, backed by a reliable baseline schedule, makes TIA workable. Applying TIA to incomplete data produces an analysis that looks rigorous but doesn't hold up under challenge.
The concurrent delay trap
In both methods, concurrent delay — two active causes of delay at the same time, each attributable to a different party — remains the most disputed issue. A rigorous analysis explicitly documents periods of concurrency rather than ignoring them, since this is often exactly where the outcome of a claim is decided.
A delay analysis only has value if it's reproducible and traceable back to the schedule's source data. That's the standard of method we apply on our schedule delay analysis assignments and contractual reviews.