When you need it: When delay has occurred
Part of Project Planning skills: Recovery
What it is: The process of analysing a project schedule to identify the cause, responsibility and quantum of delays — and presenting that analysis in a form that can support a claim, a dispute resolution process or a contractual negotiation.
When you need it: When your project is delayed. When a contractor is claiming the delay was the client’s fault. When you need to quantify an Extension of Time entitlement under NEC3, NEC4 or FIDIC.
▌ THE MECHANIC
A delay analysis is not a timeline of what went wrong. It is a structured comparison between what was planned and what happened, using the project schedule as the analytical tool.
The starting point of any delay analysis is a credible baseline schedule. Without a credible baseline, delay analysis is enormously difficult, because you have no agreed starting point for the comparison. This is why Skill 8 — The Baseline Lock — matters so much before the project is in trouble.
There are four main delay analysis methodologies:
Impacted As-Planned (IAP): Take the baseline schedule, add the delay events to it, re-run the schedule, and measure how the end date moves. Strength: relatively simple to construct and explain. Weakness: assumes the plan was achievable and does not account for simultaneous delays. Use for: early-stage analysis, simpler projects.
Time Impact Analysis (TIA): Work chronologically through the project, analysing each delay event in the context of the programme at the time it occurred. For each event, update the programme to the status immediately before the event, add the event, and measure the impact on the end date. Strength: more accurate, captures concurrent delays. Weakness: time-consuming, requires programme snapshots. Use for: major disputes, multiple delay events, NEC4 contracts.
Windows Analysis: Divide the project into time windows and analyse the delay within each separately. Strength: handles concurrent delays well. Weakness: the choice of windows is subjective. Use for: complex projects where concurrent delay is significant.
As-Built vs As-Planned Comparison: Compare the as-built programme with the as-planned programme and measure the differences. Strength: based on what actually happened. Weakness: does not on its own establish causation. Use for: as a foundation for other analyses.
▌ THE CRITICAL PATH OF CRITICAL PATHS
The single most important question in delay analysis is: was the delaying event on the critical path at the time it occurred? A client instruction that added two weeks to an activity with four weeks of float is not a delay — it is an inconvenience. It did not affect the end date. A client instruction that added two weeks to a critical activity is a two-week delay, subject to demonstrating that the contractor was not concurrently in delay for the same period.
Concurrent delay — where both the client and the contractor are causing delay simultaneously — is one of the most contested areas in construction law. The general principle under English law is that where there is true concurrency on the critical path, the contractor is entitled to an Extension of Time but not to delay damages from the client.
▌ A STORY FROM THE FIELD
On a project I worked on, there was a three-month delay. The contractor claimed the delay was entirely the client’s fault: late design approvals and access restrictions. The client claimed it was the contractor’s fault: slow mobilisation and productivity problems in the first four months.
When I built the TIA, something interesting emerged. The client’s design approvals were indeed late — but they were late on activities that, at the time of lateness, had between two and five weeks of float. They did not become critical until later, when the contractor’s productivity problems had consumed that float. The contractor’s slow mobilisation was what consumed the float that would otherwise have absorbed the client’s lateness.
The analysis showed concurrent delay for approximately six weeks, and a period of approximately six weeks where the client’s instruction was the sole cause of delay. The contractor was entitled to a time extension for six weeks, not twelve. Neither side liked the answer. But it was defensible — and it was right.
▌ COMMON MISTAKES
Starting the delay analysis without a credible baseline.
Confusing delay to an activity with delay to the project. Not all delays affect the end date.
Ignoring concurrent delay. Failing to identify and address concurrent delay is the fastest way to have an analysis challenged.
Presenting the schedule without a narrative. A P6 printout is not a delay analysis. The schedule is evidence. The narrative is the argument.
Not maintaining programme updates during the project. If you are a planning engineer on a live project, keeping your programme updates is not optional. It is your protection.
If you need to learn more about Claim Management with Primavera P6, join our dedicated advanced class:
Training Primavera: Delay analysis and Claims management with Oracle Primavera – ecostar plan