Guide · Delay analysis

Windows analysis explained: a practical guide for EOT claims

Windows analysis divides the project into periods, usually between programme updates, and measures how much the forecast completion date moved in each one and why. It is the method most often used for Extension of Time claims on projects with regular Primavera P6 updates.

What windows analysis is

A windows analysis (also called a time slice or contemporaneous period analysis) uses the programme updates that were prepared during the project. Each update is a snapshot of what the project team believed at that time: what had been done and how the remaining work would be completed.

By comparing consecutive updates, the analyst can see in which window the completion date moved, which path was critical in that window, and which delay events were on that path. The delay found in each window is then allocated to the party responsible, and the windows are added together to give the total delay and the time claimed.

In the AACE International Recommended Practice 29R-03 (Forensic Schedule Analysis) this approach is described as an observational, dynamic method:

• MIP 3.3 - Contemporaneous As-Is. The updates are used as they were issued. The movement of the forecast completion date between two updates is measured directly.
• MIP 3.4 - Contemporaneous Split (half-step). Each window is split in two steps, so that delay caused by progress can be separated from changes made to the programme itself, such as new logic, durations or activities.

Step by step

1. Check the programmes. Before any analysis, review the baseline and every update for open ends, hard constraints, negative float, invalid dates and out-of-sequence progress. A window built on a poor update produces a poor answer.
2. Define the windows. Windows normally run from one data date to the next. Shorter windows can be used around a major event; longer windows can be used in quiet periods.
3. Measure the movement. For each window, compare the forecast completion date (or a key milestone) at the start and at the end of the window. The difference is the delay, or the gain, in that window.
4. Run the half-step. Update the start-of-window programme with the actual progress only, then recalculate. The movement from this step is the delay caused by progress. The rest of the movement comes from programme revisions, which must be reviewed and explained.
5. Find the critical path. Identify the longest path to completion at the start and end of each window, and which activities on it slipped.
6. Link the delay to events. Match the slipping critical activities to the delay events: instructions, late information, access, utilities, weather, contractor issues. Correspondence and notices are the evidence that ties an event to an activity and a date.
7. Allocate the delay. Each window's delay is allocated as employer, contractor, neutral or concurrent, following the contract and the agreed approach to concurrency.
8. Sum and present. Add the windows to give the total delay, the extension of time claimed and the compensable days, and present every window with its narrative, figures and charts.

Why the half-step matters

Programme updates do not only record progress. Planners also add activities, change logic and revise durations. If these revisions are not separated, a window can show a delay that was caused by re-planning rather than by events on site, or hide a real delay behind optimistic changes. The half-step makes the effect of each visible, and a reviewer can follow both numbers.

What you need

• An accepted baseline programme and the regular updates, as P6 XER files.
• The Conditions of Contract, in particular the extension of time, notice and delay damages clauses.
• A register of delay events with dates, and the letters, instructions and minutes that support each one.
• Calendars that reflect working days, holidays and any restrictions.

Common pitfalls

• Unreliable updates. Missing logic, constraints or wrong actual dates distort the critical path. Fix or document issues before the analysis.
• Ignoring revisions. Without the half-step, re-planning is mixed with delay.
• Critical path changes inside a window. In long windows the path can shift more than once. Shorter windows give a clearer picture.
• No link to the evidence. A delay on the critical path is not entitlement until it is linked to an event, a notice and the contract.
• Concurrency left unexplained. When employer and contractor delays overlap, say how the overlap is treated and why.

When windows analysis is the right choice

The SCL Delay and Disruption Protocol (2nd edition) does not prescribe one method. It asks the analyst to consider the contract, the nature of the events, the records and the quality of the programmes available. Where reliable updates exist, a contemporaneous windows analysis is usually the most persuasive retrospective method, because it relies on the programmes the parties used at the time. Many analysts cross-check it with a Time Impact Analysis on the main events.