Two things going wrong on a project at the same time is normal. Two things going wrong that are both somebody else’s fault, at exactly the same time, on the critical path, is where things get contentious – and where quantity surveyors earn their fee. Concurrent delay is one of the most argued-over concepts in construction law, precisely because the answer to “who pays for this delay?” can flip entirely depending on how the concurrency is characterised and which forensic method is used to prove it.
This guide sets out what concurrent delay actually means, how English law treats it, how the major standard forms handle it, and the delay analysis techniques QSs and delay experts use to work out whose delay is really driving the completion date.
What actually counts as concurrent delay
The most widely used definition, from the Society of Construction Law’s Delay and Disruption Protocol, describes concurrent delay as two or more effective causes of delay of approximately equal causative potency – one an employer risk event and the other a contractor risk event – both affecting the critical path at the same time. That “equal potency” test matters: genuinely concurrent delay is rarer in practice than the word gets used for. If a contractor is already five weeks behind because of its own resourcing problems, and the employer then issues a variation that would only have caused a one-week delay on an unimpeded programme, the variation isn’t concurrent with the contractor’s delay in any meaningful sense – it simply isn’t on the critical path, because the project was already going to finish late regardless. The SCL Protocol calls this the “dominant cause” test: where one event is clearly driving the delay and the other is not, there’s no true concurrency, whatever the diary might suggest.
The Malmaison approach: time, but not money
Where true concurrency is established, English law’s default position comes from Henry Boot Construction (UK) Ltd v Malmaison Hotel (Manchester) Ltd (1999) 70 Con LR 32. The case established what’s now known as the Malmaison approach: if an employer risk event and a contractor risk event cause concurrent delay to completion, the contractor is entitled to a full extension of time for the employer’s event, even though its own delay was happening at the same time. Critically, that entitlement doesn’t extend to loss and expense – a contractor can’t recover the financial cost of prolongation for a period it would have overrun anyway because of its own default. You get the days back on the programme; you don’t get paid for them. If you’re assessing or preparing an EOT claim, our quick guide to extension of time claims covers the wider notice and substantiation requirements that sit alongside this principle.
Apportionment north of the border, and contracting out
Scotland took a different route. In City Inn Ltd v Shepherd Construction Ltd (2010), the Court of Session allowed apportionment of the delay period between concurrent causes where neither was dominant – splitting time, and potentially financial entitlement, on a fair and reasonable basis rather than awarding the contractor the full period. English courts have not followed this approach, so which jurisdiction and governing law your contract sits under can genuinely change the answer.
Just as importantly, Malmaison is a default position, not a mandatory rule – parties can draft their way out of it. In North Midland Building Ltd v Cyden Homes Ltd [2018] EWCA Civ 1744, the Court of Appeal upheld a bespoke amendment to a JCT contract stating that where a Relevant Event and a contractor culpable delay occur concurrently, the contractor’s entitlement to an extension of time would be reduced to the extent of its own delay – effectively disapplying Malmaison by agreement. The lesson for QSs reviewing amended JCT or bespoke contracts: always read the concurrent delay wording in the extension of time clause itself before assuming the common-law default applies. A clause allocating concurrency risk entirely to the contractor also has knock-on consequences for liquidated damages exposure – worth checking against our guide to liquidated and delay damages if that’s the sharp end of the argument.
How NEC4, JCT and FIDIC each approach it
The standard forms don’t all handle concurrency the same way, which is one more reason it’s worth knowing which suite you’re working under – we cover the broader differences in our comparison of NEC, JCT and FIDIC. JCT has no standalone concurrency clause in its unamended forms, so the Malmaison position governs by default, subject to whatever bespoke amendments have been made to the Relevant Events wording. NEC4 sidesteps the traditional EOT/loss-and-expense split altogether: delay and its cost are assessed together through the compensation event mechanism, prospectively, against the Accepted Programme, with no standalone concurrency rule written into the contract itself – which is precisely why maintaining an accurate, regularly accepted programme matters so much under NEC. FIDIC’s 2017 suite leaves concurrent delay largely to the governing law and whatever claims procedure the Particular Conditions set out, rather than addressing it head-on with an express clause the way some bespoke NEC and JCT amendments do.
Delay analysis methods: proving whose delay it actually is
Establishing whether delay is genuinely concurrent, and quantifying it, comes down to forensic programme analysis. The method chosen can materially change the result, and disputes over methodology are almost as common as disputes over the underlying facts. The main techniques are:
- As-Planned vs As-Built – a straightforward comparison of the original baseline programme against what actually happened, activity by activity. It’s quick and intuitive but weak at isolating cause and effect on complex projects, and it doesn’t directly test criticality.
- Impacted As-Planned – delay events are inserted as “fragnets” into the original baseline and the programme is recalculated to see the effect on completion. Simple to run, but it assumes the baseline logic held throughout the job, which is rarely true once variations and acceleration start layering in.
- Time Impact Analysis (TIA) – each delay event is modelled against the programme as it stood immediately before that event occurred, showing its incremental effect on the completion date. It’s the method most aligned with how compensation events are meant to be assessed prospectively under NEC4, and delay analysts generally favour it when reliable, regularly updated programmes exist, since it avoids reconstructing hindsight assumptions.
- Windows Analysis – the as-built programme is broken into consecutive periods, commonly monthly, with critical path movement analysed within each window. It spreads the analysis across the life of the project, reducing the risk that one contested assumption skews the whole result, at the cost of being considerably more time-consuming.
- Collapsed As-Built (the “but-for” method) – delay events are logically removed from the as-built programme to see what completion date would have resulted without them. It’s retrospective and doesn’t rely on a baseline programme at all, which makes it useful where planning records are poor, but the logic links it depends on are open to challenge and manipulation.
All five methods live or die on the quality of the underlying programme and site records – which is exactly why the discipline of maintaining a properly logic-linked, regularly updated critical path programme (see our piece on the critical path method) isn’t just good practice, it’s what makes any of these analyses defensible later.
What this means for you on site
Concurrency arguments are won or lost on contemporaneous records, not clever advocacy after the fact. Keep progress photographs, site diaries, updated programmes and instruction records as delays happen, not months later when you’re reconstructing events for a claim. Notify promptly under whatever mechanism your contract requires – NEC4’s compensation event notice periods are unforgiving, and JCT’s Relevant Event notice provisions matter just as much even when they feel more forgiving in practice. And before you concede or argue that concurrency exists at all, test it against the dominant cause question first: is the other party’s event actually on the critical path, or does it just happen to overlap in the diary? Getting that distinction right is usually worth more to the outcome than the analysis method you pick afterwards. For a deeper look at the guidance underpinning all of this, the SCL Delay and Disruption Protocol is the standard reference, and RICS’s journal commentary on concurrent delay is a useful practitioner-level summary of how the case law has developed.