Delay Analysis Methods Explained: Time Impact vs As-Planned vs As-Built

As-planned vs as-built delay analysis compares the programme the contractor intended with what was actually built, then attributes the gap to delay events. It is one of five common methods, alongside impacted as-planned, time impact analysis, windows analysis and collapsed as-built. The right method is the one your records can support - the wrong one can sink a valid claim.

Most analysts have a favourite method, and that preference is usually the first thing that goes wrong. The finished analysis is internally consistent and still useless, because the records underneath cannot carry the weight a tribunal places on them. The pattern repeats across the delay claims we see in the GCC. The method was chosen at proposal stage, before anyone had opened the programme file.

How Do the Five Delay Analysis Methods Compare?

The Society of Construction Law Delay and Disruption Protocol, 2nd edition (February 2017), describes six commonly used methods. Five of them account for almost every analysis that contractors and employers put forward. The sixth, retrospective longest path analysis, is used less often and works from the as-built record in a similar way to the as-built methods. Each method answers a slightly different question about the same delay, and each needs a different body of records before it is worth attempting.

The table is a starting point, not a verdict, and every method has a dedicated deep dive. Read impacted as-planned analysis for the quickest prospective view and time impact analysis vs windows analysis for the prospective or retrospective choice. Read windows and time slice analysis when the monthly updates are sound, and collapsed as-built analysis when the baseline is not.

As-Planned vs As-Built Delay Analysis: Simple and Often Misapplied

The as-planned vs as-built method is the most intuitive approach. It lays the original programme beside the actual sequence of work and maps the gap against the delay events the contractor has identified. It is easy to explain and quick to prepare, which is why it is the method most often produced by a contractor working without specialist support. The baseline and the site diaries are already on file, so the analysis can be assembled from records nobody has to create.

Simplicity is also its weakness. The method assumes the planned programme was achievable, that its logic and durations were realistic, and that the critical path at the start remained the critical path throughout. On a 24-month infrastructure project that assumption rarely survives contact with the records. Design information arrives out of sequence, access changes and resources move, so the critical path moves with them. When the baseline was optimistic, the whole gap between planned and actual completion is billed to delay events that did not cause it.

Three mistakes recur in as-planned vs as-built analyses:

• Using the tender programme instead of the accepted baseline - under FIDIC, the programme accepted under Clause 8.3 carries contractual weight, the tender programme carries none.
• Leaving the contractor's own delays out of the analysis.
• Ignoring concurrent delay entirely.

A one-sided analysis is easy to dismantle, and once the analyst's objectivity is questioned, every other conclusion in the report is questioned with it.

Impacted As-Planned vs Time Impact Analysis: What Is the Difference?

Impacted as-planned adds delay events to the original baseline and measures how far completion moves. Time impact analysis first updates the programme to actual progress, then inserts each event at the point it occurred. Both are prospective methods. They model what an event was likely to do, rather than what actually happened afterwards. The difference is the progress update, and that single step decides how much weight a tribunal will give the result.

Impacted as-planned is fast and cheap because it needs only a baseline and a list of events. It also treats the baseline as if no time had passed, so it ignores the contractor's own slippage and every resequencing decision taken on site. The Protocol describes it as the simplest and least expensive method, and for disputes argued after completion it is also the easiest to attack. A planner can produce it in a week. An opposing expert can usually discredit it in an afternoon.

Time impact analysis is the method the Protocol favours for extension of time decisions made while the project is still running. Its demands are correspondingly high: it needs an accepted baseline with sound logic, progress records good enough to update the programme to the day before each event, and event records with start dates, end dates and causes.

Without that trail, a time impact analysis is theory dressed as evidence. A tribunal that prefers the method in principle will still reject one built on a programme nobody accepted and nobody updated.

Windows Analysis: Tracking the Critical Path Period by Period

Windows analysis divides the project into consecutive periods, normally the monthly update cycle, and identifies which events drove the critical path inside each one. The Protocol treats two of its six methods, time slice and as-planned vs as-built windows, as windows methods. Their strength is that they capture a moving critical path. An event that was critical in month six may have been absorbed by float by month eight, and only a period-by-period analysis shows that clearly.

The method depends entirely on a contemporaneous programme update at every window boundary. Where the contractor submitted monthly updates that the Engineer reviewed, windows analysis is the natural fit. Where the updates have to be reconstructed after the event, every assumption inside the reconstruction becomes an argument.

Two further mistakes recur:

• Windows that are too wide hide the effect of individual events.
• Window totals that do not reconcile with the actual overrun signal a problem the opposing expert will find - for example, 120 days of employer delay shown on a project that finished only 90 days late, a credibility problem before the substance is even reached.

Collapsed As-Built: Working Backwards From Completion

Collapsed as-built starts from a fully logic-linked as-built programme and removes delay events one at a time to show when the work would have finished without them. It is the only common method that does not depend on a baseline, which is precisely why it exists. Where the baseline is unreliable or was never accepted, but the daily reports, labour returns and photographs are strong, it becomes the serious candidate.

The weakness is that the logic inside the as-built programme is the analyst's judgement, not a contemporaneous document. Removing events in a different order can also produce a different answer, so an analysis that does not test that sensitivity invites the charge that the result was chosen rather than calculated. Before committing to the method, test what your records will support with a claim readiness assessment. Discovering that the as-built record is too thin costs far less early than late.

What Does the Contract Say About the Programme?

Standard forms say less about delay analysis methods than contractors expect, and more about the programme than they remember. FIDIC requires a programme under Clause 8.3 and a revised programme whenever the current one no longer reflects actual progress. NEC goes further: the Accepted Programme is a contractual instrument, revised at the interval the contract states, and compensation events are assessed against it. A contractor who lets either regime lapse loses the update trail that time impact analysis and windows analysis both depend on.

So the contract rarely prescribes a method by name. What it prescribes is the programme regime, and the programme regime decides which methods stay available when the claim is prepared. That makes programme discipline a commercial control rather than a planning chore. The same updates that support the extension of time also support the prolongation claim that follows it, and the contemporaneous records behind them are what turn a programme into evidence.

How Do You Choose the Right Delay Analysis Method?

Match the method to what the evidence can support:

• A sound accepted baseline with regular updates points to time impact analysis or windows analysis.
• A weak baseline with strong site records points to collapsed as-built.
• Thin records across the board may leave only as-planned vs as-built, and then the analyst must state plainly what it can and cannot prove.

The problem is rarely the method itself. It is the match between the method, the records and the forum. An adjudicator working to a short timetable reads a windows analysis differently from a three-member arbitral tribunal with months of expert process. The Protocol expects the analyst to explain why the chosen method was selected and why the alternatives were rejected. A tribunal will expect the same explanation before it considers the delay events themselves.

We review hundreds of delay analyses and extension of time submissions across the GCC every year. The ones that fail rarely fail on the facts. They fail because the method was selected before the records were audited, the contractor's own delays were left out, or the window totals never reconciled with the actual overrun.

At CALIM, we audit the contemporaneous records before selecting a method, then match the method to the evidence, the contract and the forum. Where the records cannot support the method a claim needs, our EOT claims consultants say so while the project is live and the record keeping can still be repaired.

Frequently Asked Questions