Ask any commercial manager why extension of time claims fail and you will hear the same answer: the analysis was wrong. In my experience that answer is almost never true. Most rejected claims contain perfectly competent analysis. They fail earlier, in places nobody photographs — a notice sent eleven days after a fourteen-day condition precedent, a baseline nobody ever formally accepted, a set of site diaries that stop in month seven because the engineer who kept them moved to another job.

An extension of time claim is an evidential chain, and a chain is only as strong as its weakest link. The forensic delay analysis sits somewhere in the middle of that chain. It matters, but it cannot repair what happens either side of it. This article works through the chain in the order it is built on a real project, using a station concourse and footbridge package as the running example, and deals with method selection and concurrency where they actually arise — as decisions inside a claim, not as academic topics.

The preparation sequence, in order

Every EOT submission I have seen succeed followed roughly the same seven stages. The order is not arbitrary. Stages one to three are gateways: get them wrong and nothing downstream can save the claim, regardless of how sophisticated the programme work becomes.

The seven-stage EOT claim preparation sequence

Figure 1 — The seven-stage EOT claim preparation sequence. Every assertion at every stage must be traceable to a dated, contemporaneous record — the evidence spine running underneath is not decoration.

Stage 1 — Confirm the contractual trigger before anything else

Open the contract and find three things: the clause that grants extension of time, the list of qualifying events, and the notice provision. Then answer the only question that matters at this point — is notice a condition precedent to entitlement? If it is, and you missed it, the honest position is that you may have no claim at all, and the conversation with your commercial lead needs to happen today rather than after three weeks of analysis.

Table 1 — Notice regimes by contract family. Orientation only; the governing wording is always the executed contract including amendments.

Stage 2 — Secure the record trail while it still exists

Records degrade fast. People leave, laptops get wiped, WhatsApp groups get archived, and the subcontractor who could explain the four-week gap in steel deliveries stops answering calls. Whatever the eventual method, the analysis is only as good as the contemporaneous material behind it, and the moment to collect it is the moment the event occurs.

Table 2 — Record types ranked by evidential value. The right-hand column reflects where record-keeping most often breaks down on live projects.

On the station package described below, the entire footbridge argument turned on a single dated photograph showing the crane pad still under construction on the morning the possession opened. It proved the front was not available. No analysis in the submission carried a fraction of that weight.

Expert tip. One geotagged, dated photograph of every critical work front, taken at the same time each week, filed by activity ID. It costs a site engineer ten minutes and it has resolved more disputes than any software I have used.

Stage 3 — Validate the baseline before you measure anything from it

A delay analysis measures departure from a plan. If the plan cannot calculate a meaningful critical path, the measurement is meaningless. Before running any method, put the baseline through a health check and record the result — because the other side will run the same check, and it is far better to have disclosed a known weakness than to have it discovered.

Table 3 — Baseline health check. Running this at award rather than at claim stage is the single highest-return habit in project controls.

The worked example: station concourse and footbridge

The package was a new concourse and pedestrian footbridge at an operational suburban station, with a contract duration of forty-eight weeks and a heavy dependency on engineering possessions for the bridge lift. It finished in week fifty-nine — eleven weeks late, with liquidated damages accruing weekly and a client relationship deteriorating in proportion.

Three employer-risk events were in play. A late instruction changed the footbridge parapet detail, which pushed steel fabrication out by four weeks and caused the contractor to miss its booked possession slot. A statutory undertaker diversion overran, restricting access to the north-east foundation zone. And an asbestos discovery in the existing ticket hall stopped fit-out for eleven days. Set against those were two contractor issues: a late order on the façade cladding package, and an under-strength services team during the fit-out phase.

Three-bar Gantt: baseline vs. EOT-adjusted vs. as-built

Figure 2 — Three-bar Gantt comparing the accepted baseline, the EOT-adjusted programme, and the as-built record. Red outlines mark the as-built critical path.

The three-bar presentation is worth adopting as a standard. A two-bar as-planned versus as-built chart shows the gap but implicitly invites the reader to attribute all of it to somebody. Adding the EOT-adjusted programme in the middle makes the argument visible at a glance: four weeks of the eleven belong to the employer, seven remain with the contractor, and the discussion moves immediately to whether that split is right rather than whether a split exists.

Table 4 — As-planned vs. as-built. Measuring variance against the EOT-adjusted programme rather than the original baseline isolates residual contractor delay directly.

Once an EOT is awarded or provisionally assessed, rebuild the programme with the extension applied and measure subsequent performance against that. It separates delay the employer owns from delay the contractor owns without argument, and it makes the residual liquidated damages exposure explicit and manageable. Keep the original baseline intact and untouched in a locked file. Every re-baseline should be a new revision with a written justification, not an edit to the original.

Stage 5 in practice: choosing between Time Impact and Windows Analysis

With records secured and the baseline validated, the method question finally becomes answerable. The distinction is straightforward once stripped of jargon. Time impact analysis is prospective — you take the update immediately before an event, insert a fragnet modelling that event, recalculate, and read the movement of the completion date. Windows analysis is retrospective — you divide the project into periods, measure how far the forecast completion date moved in each period, and then establish from the records what drove that movement.

On the station package we ran windows analysis as the primary method, because monthly updates had been submitted and accepted throughout, and because five overlapping events across a forty-eight week programme would have produced a set of individual time impact analyses summing to well over the actual eleven-week overrun. We then ran two focused time impact analyses inside the contested windows — the parapet change and the asbestos discovery — because those two required a clear causal demonstration that the windows result alone did not provide.

Table 5 — Method selection matrix. In practice most disputed projects justify a hybrid: windows as the primary framework, TIA for causation on contested events.

It is worth being blunt about why this matters commercially. The same facts, run through different methods, produce materially different answers — and everyone in the room knows it. That is precisely why an unexplained method choice looks like manipulation and why a justified one carries weight.

Five methods, one set of facts — the range they produce

Figure 3 — Left: EOT produced by five methods on the same station package facts. Right: the trade-off between analytical effort and the weight the result is likely to carry in a dispute.

Impacted as-planned produced eleven weeks because it ignores as-built reality entirely and simply loads events onto the original network. Collapsed as-built produced four and a half because it removes employer events from the as-built and takes no account of what the contractor would have done differently. Windows analysis produced six — and six is where the matter settled, because it was the number the contemporaneous records could be shown to support line by line.

Stage 6: concurrency and mitigation under the SCL Protocol

The asbestos discovery and the services resourcing shortfall overlapped by nine working days on the station package, and both sat on the critical path during the fit-out phase. That is the classic setting for a concurrency argument, and it is where a great many claims are conceded too readily.

The Society of Construction Law Delay and Disruption Protocol sets a narrower test than site usage suggests. For delays to be treated as truly concurrent, there must be two or more effective causes running across the same period, each of them independently critical in its own right, with neither materially outweighing the other in causative potency. Two conditions in that description do most of the work. 'Independently critical' means each event, on its own, would have delayed completion — if one event only bites because the other has already consumed the float, they are sequential, not concurrent. 'Approximately equal causative potency' means that where one cause plainly dominates, the Protocol expects that to be stated rather than obscured behind a concurrency label.

Table 6 — A sequential concurrency test. Working through it in order prevents the most common error: labelling delays concurrent simply because they shared a calendar month.

Where true concurrency is established, the Protocol separates the two remedies. The contractor receives an extension of time, because the employer risk event did prevent completion by the contract date and the employer should not profit from its own delay by levying liquidated damages. The contractor does not recover prolongation cost for that period, because it would have been on site incurring those costs anyway because of its own delay. Time yes, money no. On the station package, that principle converted nine contested days into an EOT with no associated preliminaries recovery — a result both parties could live with, reached in one meeting.

Common mistakes on concurrency

• ⚠️ Conceding concurrency to appear reasonable. Contractors give away compensable weeks every year by accepting a label the facts do not support. Run the test in Table 6 before agreeing to anything.
• ⚠️ Assuming the SCL Protocol overrides the contract. It is guidance, not law. Where a bespoke clause addresses concurrency, float ownership or notice expressly, that clause governs.
• ⚠️ Claiming float as contractor property. Unless the contract says otherwise, float is a project resource. An employer event that consumes float without moving completion generates no EOT.
• ⚠️ Confusing acceleration with mitigation. Mitigation is the reasonable-endeavours obligation. Acceleration is additional cost and resource, and it needs an instruction — or a well-documented constructive acceleration case.

Stage 7: building the submission document

The final stage is where good analysis is most often wasted. An assessor is a person with a workload, a reputation to protect and limited time. The submission has to make approval the path of least resistance. That means a narrative a non-planner can follow, figures that carry the argument, and appendices that support rather than substitute for the story.

Table 7 — Submission structure. If the executive summary cannot be read and understood in five minutes, the document needs another draft, not another appendix.

📌 Practical habits. Disclose your own weaknesses first — an assessor who finds a gap you already flagged treats the rest as honest. Give a defensible number, not a maximum one. Index every record referenced with a document number, date and author. Use consistent activity IDs from baseline through analysis to appendices — renumbering between documents is a small thing that quietly destroys confidence.

Key takeaways

• 📌 Notice compliance and baseline validity decide more EOT claims than delay analysis ever does. Check both before doing any programme work.
• 📌 Collect records at the time of the event, not at the time of the claim. Reconstructed evidence is visible and it is discounted.
• 📌 Choose between time impact analysis and windows analysis on the strength of your update history, not on which produces the larger number.
• 📌 A hybrid approach — windows as the framework, TIA for contested causation — is usually the most defensible on complex projects.
• 📌 Measure ongoing performance against the EOT-adjusted programme so employer and contractor delay stay separable.
• 📌 Apply the full concurrency test before conceding anything; true concurrency is far rarer than the term's usage suggests.
• 📌 Under the SCL Protocol, established concurrency generally yields time without prolongation money.
• 📌 Write the submission for a busy assessor. Clarity converts a correct analysis into an awarded extension.

🔗 Related career guides

• 📘 How to become a delay analyst — the forensic career that grows directly from the notice, records and method discipline in this article.
• 📘 How we fixed -19 days of negative float in Primavera P6 — the P6 mechanics behind the baseline and update hygiene an EOT claim depends on.
• 📘 How expert planners read a Primavera P6 schedule in 10 minutes — the five-layer diagnostic that surfaces baseline problems before they become claim problems.
• 📘 Inside the Riverside office building Primavera P6 tutorial — an end-to-end P6 build that rehearses the baseline, updates and logic behind any credible EOT submission.
• 📘 Schedule entropy: why great schedules slowly become chaotic — the drift that quietly destroys the evidential value of a baseline.

Companion reading in the encyclopedia: Forensic Delay Analysis, Time Impact Analysis, Windows Analysis, Baseline Schedule, Float Management, Critical Path Method and Liquidated Damages.

The uncomfortable truth about extension of time claims is that most of the work that determines the outcome happens long before anyone opens a scheduling tool. Accepted baseline, honest updates, notices issued on time, records kept because somebody decided in month one that they would be. Build that foundation and the analysis becomes a straightforward technical exercise. Skip it, and no method — however expertly executed — will recover the position.