Time impact analysis vs windows analysis: which one does your dispute need?

These are the two method names everyone reaches for, frequently interchangeably and frequently wrongly. They answer different questions, need different records, and fail in different ways. Picking the wrong one wastes money at best; at worst it hands the other side their cross-examination.

Two names, one persistent confusion

Sit in enough dispute meetings and you will hear "we'll do a TIA" used to mean almost any analysis involving schedule updates, and "windows" used to mean almost any analysis divided into periods. The confusion is understandable — both methods work through the project chronologically, both lean on the contemporaneous schedules — but it is worth dispelling, because the two sit on opposite sides of the most important fork in the AACE 29R-03 taxonomy.

Time impact analysis is a modelled method. It builds something: delay fragnets inserted into a schedule, with the CPM engine forecasting the consequence. Windows analysis is an observational method. It builds nothing: it reads the schedule updates the project actually produced and measures what they already show. One predicts; the other reports. Everything else about them — their records appetite, their cost, their reception in tribunals — follows from that single difference.

Time impact analysis: the modelled forecast

TIA is MIP 3.7 in AACE terms — modelled, additive, multiple base — and one of the SCL Protocol's six listed methods. The mechanics are conceptually clean. For each delay event: take the schedule update current at the time the event arose; build a fragnet (a small network of activities representing the event — the late instruction, the redesign, the rework — with its own logic and durations); insert the fragnet into the update; recalculate; and read the movement of the completion date. That movement is the impact of the event, assessed with the knowledge available at the time.

TIA was designed as a prospective tool, and that is where it is strongest: an EOT application submitted while the project is live, assessing an event that has just occurred, using the schedule everyone was managing by at the time. Many standard forms effectively assume this is how extensions will be assessed. Used this way, contemporaneously, TIA is hard to better.

Its weakness arrives with hindsight. Run retrospectively, after completion, a TIA produces the theoretical impact each event would have had — which can diverge embarrassingly from what actually happened. The contractor may have resequenced around the event; the predicted 25-day slip may have materialised as six; other delays may have overtaken it entirely. The SCL Protocol's 2nd edition is explicit in its caution about retrospective TIA for exactly this reason: a tribunal asked to award delay that the as-built record shows never occurred tends to ask awkward questions. Analysts call this the hindsight problem, and it cuts both ways — the model can overstate impact the project absorbed, and understate impact the project compounded.

Fragnet quality: where TIAs are won and lost

The fragnet is the whole case in miniature, and it is built entirely from analyst judgement: how many activities represent the event, what durations they carry, where they tie into the network, and which existing logic they displace. Each judgement is contestable, and experienced opposing experts contest all of them. A fragnet whose durations trace back to contemporaneous records — the actual dates on the revised drawings, the actual procurement quotes — survives. A fragnet whose durations trace back to "professional judgement" exercised four years later does not, particularly when the professional exercising it is paid by the party the judgement favours.

The schedule receiving the fragnet matters just as much. Inserting an immaculate fragnet into an update with broken logic, dangling activities and a constraint holding the completion date is an exercise in garbage-in: the engine cannot transmit the impact through a network that doesn't calculate. This is the unglamorous reason quality checks come before forensic work — a schedule that fails the critical-path test in the DCMA 14-point assessment is structurally incapable of supporting a TIA, whatever the fragnet looks like.

Windows analysis: the observational record

Windows analysis — the SCL's time slice windows, AACE's observational dynamic family (MIP 3.3 as-is, MIP 3.4 with causes split) — works the other way round. Divide the project into windows, normally bounded by the update data dates. For each window: take the update at the start and the update at the end, identify the critical path in each, measure how much completion moved across the window, and then go to the contemporaneous records — diaries, progress photos, correspondence, instructions — to attribute that movement to causes.

Windows analysis is retrospective and evidence-led, and after the fact it is generally the more robust of the two: it measures delay that demonstrably occurred, in the periods it occurred, on the critical path the project was actually running. There is no hindsight problem because hindsight is the method — the analysis is a structured reading of what the project recorded about itself. It also surfaces things additive models politely ignore: contractor culpability sits in the same windows as employer delay and cannot be edited out; recovery shows up as negative movement; and concurrency tends to appear naturally when two causes drive the same window, rather than waiting for someone to plead it.

Its appetite is the catch. Windows analysis needs a full set of credible contemporaneous updates — honestly statused, logically sound, consistently maintained. Updates that fail basic structural quality checks cannot carry it, and gaps in the sequence force the analyst into the modified-or-recreated territory of MIP 3.5, where every reconstruction is a new argument. If your update discipline was poor, no retrospective heroics will fix it.

Side by side

Which one does your dispute need?

Neither method is cheap, and neither is proportionate to every dispute — a point the SCL Protocol makes explicitly. A TIA's cost scales with the number of events to be modelled; a windows analysis scales with the number of windows and the volume of records behind each attribution. On a modest final-account row, both can cost more than they recover. But where the claim justifies the work, strip away the branding and the choice usually makes itself.

• Live project, event just happened, EOT to submit: TIA. This is its native habitat — assess the event with the schedule current at the time, submit promptly, keep the fragnet honest.
• Post-completion dispute with a good update set: windows. Measure what happened, attribute it from the records, and let the as-built facts do the arguing.
• Post-completion dispute with poor records: neither, honestly. You are in as-planned vs as-built territory — less precise, but at least built on evidence that exists rather than evidence you wish existed.

The hybrid case is the common one: a contractor who submitted TIAs during the project now faces a retrospective dispute. Those contemporaneous TIAs are not wasted — they evidence what the parties believed at the time, which matters to entitlement under many forms. But expect the tribunal to want the retrospective question answered retrospectively, with a windows analysis reconciling forecast against outcome. Where the two agree, your case is formidable. Where they diverge, far better that your own expert explains the divergence than the other side's.