Windows Analysis and Time Slice: How the Contemporaneous Delay Method Works

Windows analysis is a retrospective delay analysis method that divides a project into consecutive periods, usually monthly, and measures the critical delay in each window from contemporaneous programme updates and records. It is only as reliable as the updates behind it, which is where windows claims are usually won or lost.

In its time slice form, the critical path in each window is read from the programme update current at the time.

Contractors tend to treat windows analysis, also called window analysis, as one method with one name. The SCL Protocol recognises two versions, and each makes different demands on the programme record. Commission the wrong one and you buy an argument your updates cannot finish.

What Is Windows Analysis as a Delay Analysis Method?

The Society of Construction Law Delay and Disruption Protocol, 2nd edition (February 2017), lists six commonly used delay analysis methods, and two of them are windows methods. Both are effect and cause analyses. The analyst first identifies the critical delay that actually occurred in a period, then searches the records for what caused it.

That ordering is the point. For assessments made after completion, the Protocol regards effect and cause methods as generally more forensically reliable, because they consider every potential cause of the delay. The analyst does not choose which events to model, so a properly run analysis examines the contractor's own delays alongside the employer's before it reaches any finding. The Thomas Barnes case below shows what happens to an expert who skips that step.

It is often described as the contemporaneous method for a precise reason. In a time slice analysis the critical path is determined from the programme as it stood at each update, while delay is measured retrospectively as time actually lost. Time impact analysis shares that critical path but models the impact prospectively. One asks what did happen each month. The other asks what was likely to happen.

North American practitioners following AACE International's recommended practice 29R-03 also call it contemporaneous period analysis or month-to-month analysis, and that document concedes the naming is loose. Ask your analyst which windows method is meant, and why.

The Two Windows Methods: Time Slice and As-Planned Versus As-Built Windows

The first windows method is time slice windows analysis, which measures critical delay as the movement in forecast completion between consecutive verified programme updates, typically monthly. The analyst verifies, or develops, a reliable series of updated programmes, each recording the true status of the works at a snapshot. The movement in forecast completion from one slice to the next, once changes made by re-planning are separated out, shows the net critical delay incurred in that window.

The second is as-planned versus as-built windows analysis. It relies less on scheduling software and suits projects where the baseline or the updates are doubtful or too few. Windows are framed by updates, milestones or significant events, and the analyst finds the critical path in each from the facts, so every criticality call needs written reasoning.

How to Run a Windows Analysis Step by Step

Running a windows analysis follows six steps:

1. Audit the programme record before choosing the method - collect every baseline, update and revision in native format, note which ones the Engineer reviewed, and map the gaps.
2. Set the windows - monthly windows matching the update cycle are the norm, and a window should also close at a major instruction, suspension or re-sequencing so a shift in the critical path can be tied to its cause.
3. Validate each programme - its recorded progress must match reality, and its remaining logic and durations must be reasonable, realistic and achievable.
4. Measure the critical delay - if, for example, the January update forecasts completion on 30 June and the February update forecasts 14 July, fourteen days of net critical delay were recorded in that window; where logic also changed, split the movement (AACE's half-step).
5. Attribute - the records show what drove the critical path that month, and each cause is classed as excusable, compensable or non-excusable delay.
6. Reconcile - the windows must add up to the actual overrun after mitigation and acceleration, or the analysis reads as advocacy.

Attribution and Concurrency Inside Each Window

Concurrency is where windows analysis earns its fee. Because it starts from the critical delay and hunts for every cause, it can show employer and contractor risk events driving the critical path in the same window. The Protocol treats concurrency as an issue only where each event is an effective cause of delay to completion, and it describes true concurrency, where the events themselves coincide, as rare, while recognising the more common case of events that arise at different times but bite at the same time.

In Thomas Barnes & Sons v Blackburn with Darwen Borough Council (2022), the claimant's expert said he had used as-planned versus as-built windows analysis. He did not treat the roof coverings as potentially critical.

The defendant's expert used the contemporaneous records to prove the contractor's own delay in starting and finishing the roof coverings, and argued that the roofing delay, not the steelwork, drove the critical path until December 2014.

The judge went further. Deciding causation as a matter of fact, he found that the roofing delay and the steelwork remedial delay, which was not the contractor's fault, were both causes of delay over the same period.

The money followed the finding. The court allowed a further 119 days of extension, on top of the extension already granted, but only 27 days of prolongation. The court reached that split by applying the English law position both counsel accepted.

A contractor delayed by concurrent causes can get time, but it recovers loss and expense only if it passes the but-for test. An amended clause in the JCT contract reinforced the result. The SCL Protocol takes the same line on concurrent delay: time is granted, but cost is recovered only where the contractor can separate it.

Contract wording and the governing law can change both answers. Where a GCC project is governed by a local civil code rather than English law, take advice on how that code treats delay caused by both parties.

What Records Does Windows Analysis Depend On?

Windows analysis is hungry for programme records. The Protocol recommends three habits:

• Update the programme at least monthly.
• Save each update as a separate native file rather than a PDF.
• Never overwrite a version.

Those three habits decide whether a time slice analysis can rest on contemporaneous updates rather than reconstructed ones.

FIDIC builds in part of that discipline. Sub-Clause 8.3 requires a revised programme whenever the current one no longer reflects actual progress, and monthly progress reports follow under Sub-Clause 4.21 (1999) or 4.20 (2017). A PDF shows the answer the planner reached. The native file shows how, and that is what an opposing expert tests.

Attribution happens in the site records. Diaries, labour returns, dated photographs, RFIs and instruction logs turn a measured delay into an explained one. That is why the contemporaneous records kept on site matter as much as the planner's files.

Strengths and Weaknesses of Windows Analysis

The strengths are real. Windows analysis follows the critical path as it moved, relies on documents exchanged at the time, and forces the analyst to confront contractor delay in every window. A finding of employer delay therefore carries weight, because the alternatives were tested first.

The weaknesses mirror them. An update is the contractor's own forecast, and it can carry optimistic durations or convenient logic that shift the critical path for reasons no event explains. Wide windows hide the moment the path switched, and verifying every update makes the method slow and costly on a long project.

Failed windows analyses tend to share one feature. Not a shortage of delay. A shortage of updates that prove it. Reconstructed updates are permitted, but they usually carry less weight than ones the Engineer saw at the time, so an analysis can be methodologically correct and evidentially weak.

When Do Tribunals Favour Windows Analysis?

Tribunals tend to favour windows analysis when the assessment is retrospective, the critical path moved, and credible updates exist. The Protocol draws the line by timing. During the project it recommends time impact analysis, because waiting to see the actual effect is discouraged. After completion it treats effect and cause methods such as windows analysis as generally more reliable.

The Technology and Construction Court has endorsed the monthly logic. In Walter Lilly & Company Ltd v Mackay [2012] EWHC 1773 (TCC), Akenhead J preferred the expert who analysed, broadly month by month, what was actually impacting progress. He called a monthly review of what was delaying completion the conventional approach of delay experts. He also stressed that the court decides, as a matter of fact, what delayed the works and for how long.

The problem is rarely the label on the method. It is whether the analysis engages with the facts. In Thomas Barnes the judge declined to attach much importance to whether each expert had loyally followed his named method. He accepted, though, that a manifestly inappropriate choice, or an unexplained material departure from it, can reduce an expert's weight. On GCC projects, as elsewhere, the Protocol is guidance rather than law, so the contract and the governing law come first, unless the contract itself incorporates the Protocol.

We review hundreds of programme updates across the GCC every year, and the pattern is consistent. Windows analyses that hold up rest on monthly native updates commented on while the project was live. The ones that struggle were assembled after the dispute from PDFs and recollection.

At CALIM, we audit the programme record before recommending a windows method, then build each window from verified updates and reconcile it to the actual overrun. Contractors who need that work done independently can brief our delay analysis consultant before the gaps in the record harden.

Frequently Asked Questions