Concurrent Delay Explained (With a Worked Example)

Two delays. Same week. Same critical path. One is the Employer's fault, one is the Contractor's. Who pays, and who waits? Concurrent delay is the question that turns a calm progress meeting into a staring contest, and it is one of the most argued-over corners of construction law.

Here is the honest starting point: there is no single right answer that works everywhere. The treatment of concurrent delay changes with the contract, the governing law, and the facts on the ground.

This guide explains what concurrent delay actually is, walks through a clear day-by-day example, and separates the time question from the money question — because they really are two different questions, and confusing them is how good claims fall apart.

What Concurrent Delay Actually Means

Concurrent delay is when two separate causes of delay operate at the same time, and both affect the critical path. Usually one cause is the Employer's responsibility and the other is the Contractor's. Both are pushing the completion date out at once.

The key word is "critical". A delay only matters for the completion date if it sits on the critical path — the chain of activities that, if delayed, delays the whole project. If a delay only eats into spare time on a non-critical activity, it is not driving the end date, and it is not really part of the concurrency question.

Picture two people pushing the same door from the same side at the same moment. The door was going to open anyway. That image — two independent pushes, one outcome — is the heart of true concurrency.

Where it gets messy is that delays rarely line up neatly. They overlap by a few days, run at different intensities, and the records are usually thinner than anyone admits. Site life is not a Gantt chart with crisp edges, which is exactly why this topic generates so many disputes.

True Concurrency vs Sequential Delay

Many delays that get called "concurrent" are not concurrent at all. They are sequential — one happens, then the other — and people only group them because they fell in the same month. Getting this distinction right is half the battle.

True concurrency means both delay events are genuinely critical over the same period, and each on its own would have caused roughly the same delay. Neither one is just sitting in the background.

Sequential delay means the events follow one another in time. The Employer's late drawing delays you in March, then your own labour shortage delays you in April. These are two separate delay events, each analysed on its own — not concurrency.

There is also the case where one delay is critical and the other is not. If the Employer's delay is driving the end date and your own delay is comfortably absorbed by float, that is not concurrency either. Only one push is actually moving the door.

The reason this matters: true concurrency triggers the special rules below. Sequential or non-critical delays do not. Labelling a sequential mess as "concurrent" is a common own goal — it invites the Engineer to take the whole claim apart, and a delay analyst will spot it in about five minutes.

A Worked Example, Day by Day

Numbers make this concrete. Say a Contractor is building a pump station. The baseline programme shows the critical path running through the concrete pour, then the mechanical install, with completion due on 30 June. There is no spare float on this chain.

Now two delays land in the same window:

1. 1–14 June (Employer delay): The Engineer issues a Variation changing the pump foundation design. Work on the foundation stops while the Contractor waits for the revised drawing. This is an Employer-side cause and it sits on the critical path.
2. 1–14 June (Contractor delay): Over the exact same fortnight, the Contractor's specialist rebar crew fails to mobilise. Even if the revised drawing had arrived on day one, the crew was not there to build the foundation. This is a Contractor-side cause, and it sits on the same critical path.

Both delays are 14 days. Both are critical. Both run over the identical period. Neither alone would have let work proceed — the drawing was missing, and so was the crew. That is true concurrency, textbook clean (real life is rarely this tidy, but the principle holds).

What happens to time? The completion date moves from 30 June to roughly 14 July — a 14-day slip. Under the most common approach, the Contractor gets that 14-day Extension of Time, because an Employer-cause genuinely contributed to it.

What happens to money? This is where it splits. The Contractor was going to be on site for those extra 14 days anyway because of its own missing crew. So the prolongation cost for that fortnight is usually not recoverable — the Contractor would have incurred it regardless.

Now change one fact. Suppose the rebar crew was only missing for 1–7 June, but the drawing was missing the full fortnight. For the second week, only the Employer's delay is critical. That week is no longer concurrent, and prolongation cost for those seven days becomes arguable. Float and overlap are everything — shift the dates by a few days and the answer changes.

The Main Approaches: Malmaison, Apportionment, Dominant Cause

Different legal systems handle concurrency in different ways. You do not get to pick your favourite — the governing law and your contract decide. But you should know the main approaches, because they shape what you can realistically claim.

• Malmaison (time but not money). Named after the Henry Boot v Malmaison case in English law. On true concurrency the Contractor gets the Extension of Time but not the prolongation cost. This is the most common position in English-law contracts.
• Apportionment. The delay is split between the two causes on a fair basis — say 50/50, or some other share reflecting their relative weight. Scottish courts have leaned this way (the City Inn case is the headline example). It feels intuitive but is hard to do precisely.
• Dominant cause. The delay is attributed entirely to whichever cause was the real driver. Clean in theory, painful in practice, because on true concurrency the whole point is that neither cause clearly dominates.

There is also the older, harsher view where any concurrent Contractor delay cancels the Extension of Time entirely. It still appears in some bespoke contracts through express concurrency clauses, so read the amendments before you assume the friendly default applies.

The lesson is not to memorise case names. It is to find out, early, which approach your contract and jurisdiction follow — because that single fact decides whether your concurrency argument is worth running at all. Contracts have a way of humbling everyone who assumes the default.

Time vs Money: Why You Might Get the EOT but Not the Cost

This is the part that surprises people most. You can win the Extension of Time and still recover nothing for the prolongation cost over the same period. They run on different tests.

Time asks a causation question: did an Employer-cause contribute to the delay to completion? If yes, the Contractor is usually relieved of liquidated damages for that period — the project simply finished later for a reason the Employer shares.

Money asks a stricter "but-for" question: would the Contractor have avoided this cost but for the Employer's delay? During genuine concurrency the honest answer is often no, because the Contractor's own delay was already keeping it on site and racking up the same preliminaries.

So the Contractor avoids the penalty for finishing late, but does not get its weekly site costs paid for the overlapping period. It is a strange split until you see the logic: you cannot charge the Employer for an extended stay you were going to make anyway. Many a Quantity Surveyor has learned this the hard way at final account.

The practical takeaway is to claim time and cost separately, with separate evidence. Bundling them into one number invites the Engineer to reject the whole thing when only the cost piece is weak.

How Courts and the SCL Protocol Treat It

The Society of Construction Law Delay and Disruption Protocol is the most widely cited industry guidance on delay analysis, and it has a clear core position on concurrency. It broadly supports the Malmaison line — time for the Contractor, but not the prolongation cost for the concurrent period.

The Protocol is guidance, not law. It does not override your contract or the governing law, and tribunals treat it as a sensible reference rather than a binding rulebook. Still, when an Engineer or arbitrator reaches for a neutral starting point, the Protocol is usually it.

English case law has circled this area for years. Henry Boot v Malmaison set the time-but-not-money tone, and later cases such as Walter Lilly and the North Midland decision refined it — the latter confirming that parties can agree their own concurrency rule by contract, even a tough one.

Outside England the picture shifts. Scotland's City Inn opened the door to apportionment, and many civil-law jurisdictions in ChatNotice's core markets across the Gulf and Asia approach causation through their own civil codes rather than English precedent. The destination can be similar, but the road there is different.

The point is not to become a comparative-law scholar. It is to confirm the framework that applies to your project before you build a claim on assumptions that belong to someone else's legal system.

How to Argue Concurrent Delay in a Claim

A concurrency argument lives or dies on structure. The Contractor's job is to show the Engineer, step by step, that both events were real, both were critical, and both ran together — and to be honest about its own delay rather than hide it.

A clean submission usually contains:

• The baseline programme — an accepted plan with a clearly identified critical path before the delays hit.
• Both delay events, separately described — the Employer-cause and the Contractor-cause, each with its own start and end dates and contractual basis.
• A delay analysis — a recognised method showing both events were genuinely critical over the same window.
• The time claim — the Extension of Time sought, in calendar days, flowing from the analysis.
• The cost position — handled separately, with the but-for test addressed head-on rather than glossed over.

The instinct to bury your own delay is the one to resist. Engineers and delay analysts find it anyway, and once they catch you hiding one delay, they stop believing the rest of the claim. Owning the Contractor-cause and explaining why an Extension of Time still follows is far stronger than pretending the crew showed up on time.

This is also where getting the notice right at the very start pays off. If the Employer-side event was never properly noticed, the concurrency argument can be dead before it begins. Tools like ChatNotice help Contractors get that first notice served on time, so the entitlement is preserved while the delay analysis catches up.

Common Mistakes With Concurrent Delay

• Calling sequential delays concurrent. Two delays in the same month are not concurrent unless both were critical at the same time. This is the most common error and the easiest to disprove.
• Ignoring float. A Contractor delay that float absorbs is not critical, so it is not concurrent. Treating it as concurrent gives away cost you could have claimed.
• Bundling time and money. Claiming them as one number lets the Engineer reject everything when only the cost piece is weak. Split them.
• Hiding the Contractor-cause. The Engineer finds it, and your credibility goes with it. Disclose and explain instead.
• Assuming the friendly default. Some bespoke contracts have express concurrency clauses that cancel the time entirely. Read the amendments before you rely on Malmaison.
• No contemporaneous records. Concurrency is proved with programmes, daily reports and correspondence — not with a story written after the fact.
• Late notice on the Employer event. If the Employer-cause was never noticed in time, there may be no entitlement to attach the concurrency argument to.

None of these are exotic. They are the same honest-bookkeeping failures that sink most delay claims — just with higher stakes, because concurrency is already a fight before you add self-inflicted wounds to it.

Frequently Asked Questions