Windows Analysis exists for the situation Time Impact Analysis handles badly: a project with multiple delay events, spread across an extended period, some of them overlapping, where trying to isolate each one with its own forward-looking fragnet would mean re-litigating the whole schedule's history one event at a time. Instead, Windows Analysis steps back and asks what actually happened to the critical path, period by period, across the life of the project.

The core idea

Where TIA is prospective — inserting a hypothetical delay into a schedule and predicting its effect — Windows Analysis is retrospective. It's sometimes described as "effect and cause" rather than "cause and effect": you look at what actually happened to the completion date during a given period first, and then work out which delay events during that period were responsible.

How the "windows" are built

The project's total duration is divided into a series of sequential time periods — the "windows." In practice, these are usually tied to the schedule updates that were actually issued during the project, since each update captures a snapshot of progress and logic at a specific point in time. For each window:

Identify the critical path as it stood during that window, using the schedule update(s) covering that period.
Measure the change in projected completion date from the start of the window to the end of it.
Attribute the change to the specific delay events that occurred on the critical path during that window.

Repeating this across every window, in sequence, builds a full picture of how the completion date moved over the life of the project, and which events were responsible for each movement.

Why Windows Analysis suits overlapping delays

Because each window is analyzed on its own terms — using the critical path as it genuinely stood at that point — Windows Analysis handles concurrent and overlapping delays more naturally than TIA does. If an employer-caused delay and a contractor-caused delay both land on the critical path within the same window, that concurrency is visible directly in the analysis for that period, rather than needing to be untangled through a series of separate hypothetical insertions.

This is also why Windows Analysis tends to be the method of choice in larger, more contested disputes, where the delay history is long and multiple parties are pointing at each other's activities.

What Windows Analysis needs

The method's biggest constraint is data. It depends on having a complete, credible run of periodic schedule updates covering the whole project — not just the original baseline and the final as-built. If updates are missing, were never formally accepted, or show inconsistent logic between one and the next, the windows built from them carry that weakness straight into the analysis. This is the practical reason Windows Analysis is rarely chosen proactively at the time of a single delay event (TIA is faster and needs less data) — it tends to be the method reached for after the fact, when a dispute is being reconstructed from whatever schedule records exist.

TIA vs. Windows Analysis

The distinction comes down to timing and scope. TIA assesses one delay event, close to when it happened, using the schedule as it stood right before. Windows Analysis assesses a whole span of the project, after the fact, using the full sequence of updates that were issued during it. Projects that maintain disciplined contemporaneous notices and clean baselines tend to stay in TIA territory throughout. Projects where delays accumulated without being assessed in real time — or where the dispute only crystallized well after the fact — usually end up needing Windows Analysis to reconstruct what happened. (See the full method comparison on the delay analysis methods pillar page.)

Where Windows Analysis gets challenged

The most common attack on a Windows Analysis isn't the calculation itself — it's the choice of window boundaries. Windows drawn to align conveniently with a party's preferred narrative, rather than genuinely with the schedule updates that were actually issued, invite exactly that objection. A defensible Windows Analysis uses window boundaries that are independently justifiable — tied to real, contemporaneously issued schedule updates — not chosen after the fact to produce a particular result.