A delay you can't demonstrate is a delay you'll pay for. Here's how as-planned versus as-built analysis turns 'we were late because of you' into an entitlement you can defend.
Being delayed and proving you were delayed are two entirely different things. Every contractor who's ever been held up by late information, a client change, or a possession that arrived weeks after it should have, knows the frustration of knowing it wasn't your fault. But knowing isn't a claim. When an extension of time is contested — and the ones worth having always are — you have to demonstrate cause and effect. That's delay analysis.
Get it right and a contested EOT becomes a defensible entitlement: time, relief from liquidated damages, and often the basis for loss and expense. Get it wrong — or, more commonly, have no records to do it with at all — and a genuine delay turns into damages you pay for a hold-up that wasn't yours. This is where small contractors lose real money, and almost always not because they weren't delayed, but because they couldn't prove it.
An EOT isn't awarded because something went wrong. It's awarded because a delay event that's the client's risk under the contract caused a delay to completion. Two things have to connect:
That second point is what most failed claims miss. A delay to work that had float — that wasn't driving the end date — generally doesn't earn an EOT, because it didn't delay completion. You're not proving "something bad happened." You're proving "this client-risk event delayed the critical path and therefore the finish." Cause, effect, and criticality. Miss any of the three and the claim's weak.
Before any method, two foundations. Without them, no delay analysis is possible, however clever the analyst:
A reliable baseline programme. You can't show that something was delayed without a credible plan of what should have happened. A proper baseline programme — logic-linked, with a visible critical path, agreed or at least issued at the outset — is the yardstick everything is measured against. No baseline, no analysis. This is the single most common reason small contractors can't run a claim: there was never a real programme to begin with, just a bar chart drawn for the tender.
Contemporaneous records. What actually happened, recorded as it happened — progress, site diaries, delay events, correspondence, the RFIs that went unanswered, the dates information arrived. As-built reality, captured at the time, not reconstructed from memory a year later. Records made at the time carry weight; recollections don't.
Get these two right during the job and delay analysis afterwards is possible. Neglect them and you've lost the claim before you've started — which is why the real work of protecting an EOT happens on site, in the record-keeping, long before any dispute.
There's a whole industry around delay analysis, and the SCL Delay and Disruption Protocol sets out the recognised approaches. You don't need to be an expert, but you should understand what the main methods are and roughly when each applies:
The method you use depends on what records you have, when the analysis is being done (as it happens versus after the fact), and what the contract or forum expects. The uncomfortable truth for most small firms is that the choice is made for you by your records: with a good baseline and solid as-built data you can run the persuasive methods; without them you're stuck with the weak, theoretical ones that get picked apart.
You can't write about delay without mentioning concurrency, because it's where claims get complicated and defensive. Concurrent delay is when two delays run at the same time — one the client's risk, one yours — and both are affecting completion. Whose delay "counts"?
It's genuinely contested legal territory, treatment varies by contract and by jurisdiction, and it's where a lot of EOT arguments are won and lost. The practical point for a contractor is this: expect the other side to raise concurrency to reduce your entitlement — "yes, our variation delayed you, but so did your own late labour" — and expect to need good records to show what was actually driving the critical path at any given time. The better your contemporaneous data, the stronger your position when concurrency is argued. Vague records lose concurrency arguments by default.
Here's the whole thing distilled. Delay analysis sounds like something for experts and disputes, and at the sharp end it is. But the part that decides whether you'll ever be able to run one happens on your ordinary jobs, every day, in two habits:
Have a real programme, and keep it updated. Not a tender bar chart. A logic-linked baseline you actually maintain, so there's both a plan to measure against and a record of how the predicted completion moved over time.
Record what happens, as it happens. Progress, delays, the dates things arrived, the events that held you up. Notify delay events under the contract — and under NEC4, raise the early warning — at the time, not at the end.
Do those two things and you'll be able to prove delay when you need to. Skip them and you'll be the contractor who was genuinely, provably held up by someone else — and still ends up paying the damages, because "genuinely" and "provably" turned out to be different words.
At Construction AI, the programme is a live, logic-linked tool with a visible critical path, and it sits alongside the site diaries, photos, RFIs and correspondence that form the as-built record — captured as the job runs, dated, in one place. That means the two foundations of any delay claim, a reliable baseline and contemporaneous records, are being built as a by-product of running the job properly, rather than reconstructed under pressure when a dispute lands. When you need to show cause, effect and criticality, the evidence is already there.
You can't argue your way to an extension of time. You demonstrate it, with a baseline, a critical path, and records that show what happened and why. Keep the programme real and the records contemporaneous, and a contested delay becomes an entitlement you can defend. Neglect them, and being right won't be enough.
What is delay analysis in construction?
Delay analysis is the process of demonstrating that a delay event caused a delay to completion — connecting a relevant event (a cause that's the client's risk under the contract) to an effect on the critical path — in order to support an extension of time claim.
What do you need to prove an extension of time?
That a relevant event occurred, that it affected the critical path, and that it therefore delayed completion — cause, effect and criticality. A delay to work with float that didn't drive the completion date generally doesn't earn an EOT.
What are the main delay analysis methods?
As-planned versus as-built, impacted as-planned, time impact analysis (TIA), collapsed as-built (but-for), and windows/time-slice analysis. The right method depends on the records available, whether the analysis is done during or after the job, and what the contract or forum expects.
What is concurrent delay?
Concurrent delay is when two delays — one the client's risk and one the contractor's — affect completion at the same time. Its treatment is contested and varies by contract and jurisdiction; strong contemporaneous records are essential to show what was actually driving the critical path.
Why do small contractors lose valid delay claims?
Usually not because they weren't delayed, but because they can't prove it — no reliable baseline programme to measure against, and no contemporaneous records of what actually happened. Without those two foundations, delay analysis isn't possible.
Stephen Mckenna MCIOB
30+ years in UK commercial construction, from site management to director level. Now building the project management tools he wished he'd had.
Tier-one contractor processes shouldn't only be available to tier-one contractors. Drawing registers, document control, RFIs, programmes, financial tracking — built for how you actually run projects, priced so any construction business can access them. Try everything free for 30 days.
By subscribing, you agree to our Privacy Policy.
The early warning is NEC4's best feature and its most ignored. Miss it and you can lose entitlement you were owed. Here's how to actually run the process.
NEC4 is gaining ground where JCT has dominated. Here's what's actually different, when each contract framework makes sense, and what your software must handle.
A delay that isn't notified is a delay you'll pay for. Here's how to identify delay events, notify properly, and build EOT claims that actually succeed.
Tier-one processes, priced for any size business. Try everything free for 30 days — no charge until your trial ends.