Construction Claims
The SCL Protocol, in Practice · Part 2 of 24
Delay vs Disruption: They're Not Twins
Delay is about time — an event pushes out the completion date, so you argue an extension of time. Disruption is about productivity — work becomes less efficient, so it costs more, whether or not the job finishes late. Different claims, different tests, different evidence. Run one as if it were the other and you can lose both.
Delay is about time: an event pushes out the completion date, so you argue about an extension of time. Disruption is about productivity: work becomes slower or less efficient, so it costs more — whether or not the job finishes late. They feel related, but they are different claims, with different tests, different evidence and different homes in the contract. Run one as if it were the other and you can lose both.
The construction-site version
Your tiling crew is planned to lay 100 m² a day. For three weeks they’re stop-start: access to the floor keeps getting handed over late and out of sequence, so they’re constantly setting up, packing down and reworking edges. Their real output drops to 60 m² a day.
Now — did the block finish late? Not necessarily. Suppose the crew clawed it back with Saturday shifts and the handover date held. Zero delay to completion. But those lost hours were real money: the same tiles cost far more labour than they should have. That’s disruption, not delay. The completion date is fine; the productivity was wrecked.
Flip it. Same crew, but this time the late access sits squarely on the critical path and there’s no Saturday recovery — the block, and the project, finish two weeks late. Now you also have delay to completion, and an EOT question sits on top of the disruption question. Same site, same crew, same late access — and depending on the facts you can have disruption alone, delay alone, or both.
The technical bit
Delay here means critical delay — delay to completion of the works. It is an analysis of time, and it is what supports an EOT claim (and, separately, time-related cost). If an event doesn’t affect the critical path to a contractual completion milestone, it doesn’t delay completion, however painful it felt.
Disruption means loss of productivity — work carried out less efficiently than it would have been but for the disrupting events. Disruption is fundamentally a money question about wasted resource, and it does not depend on the completion date moving at all.
Because disruption is about efficiency rather than the critical path, the preferred way to demonstrate it is usually a productivity comparison. The Protocol treats the measured mile — comparing productivity in a genuinely undisrupted period against a disrupted one on comparable work — as a leading approach, precisely because it measures the actual loss rather than theorising it. (The measured mile has been recognised judicially; it was accepted as a method of calculating lost productivity in Santos Ltd v Fluor Australia Pty Ltd (2017), which referenced the 2nd Edition.)
How three roles should read it
Delay is your native language: critical path, total float, the completion milestone. Disruption often doesn’t show up in the Gantt chart at all — a crew can be badly disrupted while the bar chart looks healthy. Watch planned-versus-actual output rates, not just planned-versus-actual dates. If your only instrument is the critical path, disruption is invisible until the cost report explains it.
Pick the right claim and prove the right thing. For delay, you are proving effect on the critical path and the completion date. For disruption, you are proving lost productivity — a clean baseline period, comparable disrupted work, and records granular enough to isolate the loss. The classic failure is bundling disruption cost into a prolongation claim and then being unable to defend either. Keep them in separate lanes.
When someone says "we got disrupted, so we’re owed time," slow down. Disruption doesn’t automatically buy an EOT, and an EOT for critical delay doesn’t automatically compensate a productivity loss elsewhere. Two problems, two mechanisms — often you have both, and they need to be quantified separately.
The trap
Assuming disrupted = delayed. They frequently occur together, which is exactly why people conflate them — but disruption can happen with zero delay to completion, and critical delay can happen without any measurable productivity loss.
Planned tiling: 20 working days at 100 m²/day = 2,000 m², finishing 30 June, on the critical path with 5 days’ float. Out-of-sequence access drops productivity to 60 m²/day for the first 15 days. The crew works three Saturdays to recover and still completes on 30 June.
Delay to completion: none — the milestone held; float wasn’t even fully consumed. Disruption: real — the lost efficiency in those 15 days, plus the Saturday premium, is wasted labour cost, quantified by comparing the disrupted rate against an undisrupted mile, not by pointing at a completion date that never moved. Change one fact — remove the Saturdays and put the access delay on the driving path — and you now add ~2 weeks of critical delay and an EOT question. Same events; the claim depends on the facts.
What the Protocol says — and doesn’t
It distinguishes delay (critical delay to completion — a time analysis supporting EOT) from disruption (loss of productivity — a distinct question about resource efficiency, independent of the completion date), and provides separate guidance for each, including recognised approaches to quantifying lost productivity such as the measured mile.
What it does not say:
- That disruption requires the project to be delayed — disruption can occur on a job that finishes on time.
- That an EOT compensates you for disruption — those are different heads.
- That you can divide a total cost overrun by “chaos” and call it disruption — you have to isolate the productivity loss.
”We were badly disrupted, so we’re entitled to an extension of time.”
Disruption is loss of productivity, not delay to completion. Unless the disrupting events also drove the critical path, there may be a disruption (money) claim and no EOT (time) claim at all.
Your P6 model shows delay to completion via the critical path — it does not natively show productivity loss. A disrupted crew can sit on a healthy-looking bar. To see disruption you track planned vs actual quantities and output rates (and resource-unit data), not just dates. Don’t ask P6 a question it isn’t built to answer.
Evidence check
For delay: the accepted baseline and updated programmes; records tying the event to the critical path; notices and the completion milestone. For disruption: labour allocation and timesheet records; output and quantity records; a defensible undisrupted baseline (the “mile”); and site diaries, RFIs, instructions and re-work records showing the events. Relevance always depends on the facts and the contract.
Rishi’s takeaway
- Delay = time (EOT). Disruption = money (lost productivity). Decide which you have before you draft anything.
- Disruption can exist with no delay to completion — and often does.
- Prove disruption with productivity data (ideally a measured mile), not with a completion date.
- Keep the two claims in separate lanes; bundling them is how you lose both.
Delay moves the finish line. Disruption makes the same work cost more. Don’t argue one as if it were the other.
References — Society of Construction Law, Delay and Disruption Protocol, 2nd Edition, February 2017: delay vs disruption; guidance on productivity loss and the measured mile. Santos Ltd v Fluor Australia Pty Ltd (2017) — measured mile accepted as a method of calculating lost productivity. The Protocol has no force of law unless incorporated into a contract. Educational commentary; not legal advice.
Common questions
What is the difference between delay and disruption in construction?
Delay is about time — critical delay to completion, which supports an extension of time. Disruption is about productivity — work done less efficiently than it would have been but for the disrupting events — and is a money question that does not depend on the completion date moving.
Can you claim disruption if the project finished on time?
Yes. Disruption is loss of productivity, not delay to completion. A crew can burn far more labour than planned while the completion date holds, leaving a disruption (money) claim with no extension of time.
Does an extension of time cover disruption costs?
No. An extension of time addresses critical delay to completion (time). Disruption is a separate head — lost productivity — quantified separately; the two should be kept in separate lanes.
What is the measured mile method?
It compares productivity in a genuinely undisrupted period against a disrupted period on comparable work, using the project's own records to measure the actual loss rather than theorising it. It has been recognised judicially, for example in Santos v Fluor (2017).
How do you prove a disruption claim?
With productivity evidence — labour and output records, a defensible undisrupted baseline (the measured mile), and records that isolate the loss — rather than by pointing at a completion date, which may not have moved.
Related