Time Impact Analysis vs Windows Analysis: Prospective or Retrospective?

Time impact analysis is prospective: it inserts a fragnet for the delay event into the live programme and forecasts the effect on completion. Windows analysis is retrospective: it splits the project into periods and measures the critical delay that actually occurred in each. Used at the wrong moment, a valid extension of time can fail on method alone.

Most contractors treat the two as rival methods and pick whichever one their planner knows best. They are not rivals. They answer different questions: what an event is likely to do to completion while the job is live, and what actually delayed it once the facts are in. Our guide to delay analysis methods covers the wider field.

What Is Time Impact Analysis?

Time impact analysis, usually shortened to TIA, models one delay event at a time against the live programme. Following the SCL Delay and Disruption Protocol, the analyst first updates the latest programme to just before the event, including all progress and every delay suffered by either party. The programme is then adjusted for the contractor's realistic recovery plans.

Next comes the fragnet, which the Protocol calls a sub-network: a small, logic-linked group of activities representing the work that flows from the event. For a variation it holds the instruction, the new activities and their links into the programme. Insert it, recalculate, and the movement in the completion date is the predicted delay.

The output is a forecast, and that is the point. It tells the Engineer or Project Manager how much time the event is likely to cost while there is still time to replan. The Protocol accepts the trade-off: a TIA usually does not capture the eventual actual delay.

What Is Windows Analysis?

Windows analysis starts from the other end. It asks what actually happened to the critical path within each period, and only then works back to the cause. The Protocol describes two versions, both covered in our guide to windows analysis and time slice delay analysis:

1. Time slice analysis - the analyst verifies or develops a reliable series of updated programmes, typically monthly. Comparing them reveals the critical path and the critical delay in each slice, and the records then show which events caused it.
2. As-planned versus as-built windows - used where updates are unreliable or too few, this method fixes the critical path in each window from the facts.

Because it measures effect first and cause second, windows analysis considers every potential cause of delay, including the contractor's own. That is uncomfortable for a claimant and persuasive for a tribunal, and it is why the Protocol treats effect-and-cause methods as generally more forensically reliable after completion.

Time Impact Analysis vs Windows Analysis: Side by Side

The table compares the two on the points an Engineer, adjudicator or arbitral tribunal will test.

The table hides one point the Protocol makes explicit. In both a TIA and a time slice analysis, the critical path comes from programmes reflecting progress at the time. What differs is how delay is measured: forward from the data date as a forecast, or back to it as a matter of record. With liquidated damages of QAR 50,000 a day, for example, a 30-day gap between the two answers is QAR 1.5 million of exposure.

When Does Each Method Fit?

During the project, time impact analysis fits the contract machinery. Under FIDIC the contractor gives notice within 28 days under Clause 20.1 (1999) or Clause 20.2 (2017), and the 2017 editions require a fully detailed claim within 84 days. Where the effect continues, interim claims follow at monthly intervals. A TIA at notice, refreshed with each monthly update, feeds that rhythm, and many employer-drafted Particular Conditions ask for one by name. The full process is set out in managing EOT claims on GCC projects.

NEC writes the same logic into the contract. Under clause 63.5 of the NEC4 Engineering and Construction Contract, delay to the Completion Date is the time by which the compensation event makes planned Completion later than planned Completion on the Accepted Programme current at the dividing date. That is a time impact analysis in contractual form. An implemented assessment is generally not reopened when the forecast proves wrong, so a quotation for a compensation event under NEC deserves the rigour of a claim.

After completion the question changes from what an event was likely to do to what it did. In Walter Lilly & Co v Mackay [2012] EWHC 1773 (TCC), Akenhead J noted that a court or arbitrator reviewing extensions after the event knows what actually happened. It must decide, on the balance of probabilities, what delay the events actually caused. Windows analysis is built for that question.

What Does the SCL Protocol Recommend?

The answer depends on timing. For contemporaneous assessment the Protocol recommends time impact analysis, which its guidance to Core Principle 4 sets out step by step. That principle discourages a 'wait and see' approach and asks for EOT applications to be dealt with as close in time as possible to the delay event.

For analysis long after the event, the 2nd edition of 2017 deliberately dropped the 1st edition's preference for TIA. Core Principle 11 warns that a prospective analysis may no longer be appropriate after completion, and the method is chosen instead on listed criteria:

• the contract and the events themselves
• the project and considerations of proportionality
• time, records and the programme information available
• the forum in which the analysis will be used

Two further points carry commercial weight. The Protocol urges the parties to agree the method before significant after-the-event work, warning that a failure to consult may count on costs. It also gives way to the contract and governing law, so an EOT clause that prescribes a method prevails.

Hybrids: Prospective Analysis With a Reality Check

The two methods are often combined. A common hybrid runs a TIA inside each window, updating to actual progress at the window's start, inserting that window's fragnets and checking the prediction against what happened by its end. Where the results agree, the analysis is strong. Where they diverge, the gap usually points to mitigation, acceleration or contractor delay that needs explaining.

Walter Lilly shows why the reality check matters. Akenhead J preferred the expert who analysed, month by month, what was in reality impacting progress, using actual progress and the contractor's planned intentions for the remaining work. He saw nothing wrong with testing the analysis against what actually happened.

Common Mistakes That Undermine Each Method

The most damaging TIA mistake is running one after completion as though the project were still live, measuring events against the original dates and ignoring actual progress. In Adyard Abu Dhabi v SD Marine Services [2011] EWHC 848 (Comm), a shipbuilding case, the contractor argued that any event running past the contractual date earned time, whatever was already delaying the works. Hamblen J held that notional or theoretical delay is not enough. The contractor had to show the variations were likely to cause, or did cause, actual delay to progress.

He also accepted that the Protocol's procedure, then in its 1st edition, contemplates a TIA on an updated programme showing progress. A prospective model is not wrong after completion in itself. It becomes wrong when it ignores a project already in critical delay for the contractor's own reasons. A delay event can be genuine and still prove nothing.

Windows analysis fails differently. Run without reliable updates, it becomes a reconstruction, and every reconstructed status date is an assumption the opposing expert can attack. The Protocol expects each time slice to be verified against actual progress, and where updates are missing the analyst must explain how criticality was decided.

Both methods share one failure. Modelling only employer events, or passing over contractor delays visible in a window, produces a one-sided answer that a tribunal will discount. The problem is rarely the method. It is the record behind it.

In CALIM's experience across dozens of engagements, the contractors who recover time on disputed projects are rarely those with the most sophisticated analysis. They are the ones whose TIAs went in on time and whose honest monthly updates can later carry a windows analysis.

At CALIM, we build the contemporaneous TIA and the forensic windows analysis from the same update trail, so the EOT application and any later dispute rest on one record. Contractors facing a live delay or a disputed final extension can bring in a delay analysis consultant before the method is chosen for them.

Frequently Asked Questions