What windows analysis is
Windows analysis (also called time slice or contemporaneous period analysis) divides the project into periods, usually between consecutive updates, and measures the movement of the forecast completion and of the critical path within each. Because it relies on the updates the project actually produced, it is often preferred for retrospective delay claims.
How it runs in Nexora
- Import the baseline and the statused updates (XER files work).
- Define the windows — typically update to update, or around key events.
- For each window, compare the critical path and completion at its start and end.
- Attribute the slip to the events and performance in that window, and record concurrency.
- Report the slip window by window with the evidence behind it.
Worked example
Illustrative values only.
| Window | Period | Completion movement | Driver |
|---|---|---|---|
| W1 | Baseline → update 01 (D30) | 0 days | On programme |
| W2 | Update 01 → update 02 (D55) | +9 days | Drainage productivity, re-estimates (contractor) |
A new employer instruction notified at update 02 is a future event at that point; its effect is assessed prospectively with a time impact analysis.
Good practice
- Use updates that were actually issued, with consistent data dates and settings.
- Check each update's logic and progress before relying on it.
- Keep the critical path of each window, not only the completion date.
- Show concurrent delays and how they were treated.
Why the windows follow the updates
Each update is a snapshot of what the project team believed at the time. Bounding the windows by updates means every measurement uses a programme that existed and was used — the strength of a contemporaneous method. Windows can also be bounded by key events or milestones, as long as the same rule is applied throughout the analysis.
Half-step: separating progress from revisions
Between two updates, the forecast can move for two different reasons: the progress that was recorded, and the changes made to the logic or durations of the remaining work. A half-step (bifurcated) approach first applies only the progress to the earlier update, then the revisions. The slip is split into what performance caused and what re-planning caused — often the decisive distinction in a claim.
Attributing the slip in each window
| Item | Why it matters |
|---|---|
| Critical path at start and end | Shows which work drove completion in the window |
| Completion movement (working days) | The slip to be explained |
| Events active in the window | Candidates for responsibility |
| Concurrent delays | Overlapping causes on the critical path |
| Mitigation achieved | Time recovered within the window |
Windows analysis and the rest of the claim
Windows analysis tells you how much time was lost and when. It is often combined with a time impact analysis for events that are still in the future at the latest update, and with a recovery schedule for the time the contractor intends to win back. Keeping the three separate — measured slip, forecast impact, planned recovery — makes the submission easier to review.
Common questions
What is the difference between windows analysis and TIA?
Windows analysis measures what happened between updates; a TIA forecasts what an event will do from the last update before it.
How many windows should I use?
Usually one per update period, or windows bounded by key events. Consistency matters more than the number.
Can windows analysis show concurrent delay?
Yes. Within each window, overlapping delays on the critical path are identified and reported with their treatment.
Try it on your own programme
Bring a representative work package — a BOQ extract or an XER — and review every assumption with your team.