Concurrent delay: the argument every big claim ends up having

Raise a substantial delay claim and, sooner or later, someone on the other side will say the magic word: concurrency. It is the employer's best defence and the contractor's biggest fear — and most of the arguments about it would shrink dramatically if both sides agreed on what it actually means.

Why every big claim lands here

The economics are simple. A contractor claiming 20 weeks of employer delay wants 20 weeks of extension of time and 20 weeks of prolongation costs. The employer's strongest counter is rarely "those delays never happened" — the records usually say otherwise. It is "yes, and you were delaying yourself at the same time." If that lands, the widely discussed English-law position lets the contractor keep the time but lose the money — which, on a claim where prolongation runs to six figures a week, is most of the claim.

So the employer's team goes hunting for contractor delay in the same periods as their own, and the contractor's team goes hunting for reasons it doesn't count. The result is that concurrency — a reasonably precise CPM concept — gets argued as if it meant "both parties were having a bad month." It doesn't, and the difference is worth real money.

What true concurrency actually requires

True concurrent delay, in the sense the textbooks and protocols use it, requires all of the following at once:

• Two or more delay events, genuinely independent of each other;
• different parties responsible — one an employer risk event, one a contractor risk event;
• each independently driving the critical path — meaning either one, on its own, would have delayed completion;
• in the same period.

Read that list slowly and you see why genuinely true concurrency is rare. Most candidate periods fail on the third limb: one event is on the critical path and the other is merely consuming float on a non-critical chain. An employer event that eats float is not delaying completion; it is using up schedule slack — which raises its own contested question of who owns that float, but it is not concurrency.

The literature also distinguishes literal concurrency — both events occurring and biting at exactly the same time, which is rarer still — from functional concurrency, where the events arise in the same analysis window and each would independently have driven completion, even if they started days apart. Most practical "concurrency" findings are functional. Pinning down which sense an expert is using is one of the quiet wins of cross-examination preparation.

The classic positions on what concurrency means for money

Once concurrency is established, what follows? The honest answer is: it depends where you are and what your contract says. The positions below are widely discussed industry and legal commentary, not advice on any particular case.

• The Malmaison approach — the position most commonly described for English law: where a period of delay is caused concurrently by an employer event and a contractor event, the contractor gets the extension of time for that period, but not prolongation costs. Time and money decouple: the contractor is relieved of liquidated damages but bears its own time-related costs for the concurrent stretch.
• Apportionment — associated with the Scottish courts and the City Inn decision: where concurrent causes operate, responsibility for the delay (and sometimes the money) can be apportioned between the parties according to their relative causative potency. Widely discussed, applied in some jurisdictions, and pointedly not the prevailing English approach.
• The SCL Protocol 2nd edition takes a position close to Malmaison: the contractor is entitled to an EOT for employer delay that is concurrent with its own; for prolongation costs, the contractor recovers only where it can separate the costs caused by the employer delay from those it would have incurred anyway because of its own.
• "But-for" defences — the employer argument that the contractor would have been late regardless, so the employer event caused no loss; and its mirror image from contractors. Tribunals' tolerance for but-for reasoning varies with the method used to demonstrate it, as we'll see below.

The analyst's job: concurrency is demonstrated, not asserted

Concurrency is established by CPM analysis, not by adjectives in a submission. To stand up, a concurrency finding needs to show, from the schedules: the same data date and the same window; both events mapped onto the network; and both events on a critical path at that data date — not one critical and one merely erosive of float. That last distinction is where most concurrency claims die, and it is checkable: open the update, read the float on each affected chain, done. (Whether the employer event must be strictly critical, or whether eating deep into float is enough to matter, is itself argued — but the argument only starts once the float values are on the table. Float, and who owns it, is its own battlefield.)

The window matters as much as the data date. An employer event in March and a contractor event in August are not concurrent merely because both appear in the same claim; they are sequential delays to be analysed in their own periods. Conversely, two events that overlap for three weeks out of ten are concurrent — at most — for those three weeks, and the EOT and money consequences attach to the overlap, not to the whole of either delay. Sloppy submissions routinely claim "concurrency" across entire delay periods when the schedules show a fortnight of genuine overlap; an analyst who plots both events against the update data dates can usually shrink the argument to its true size before the lawyers inflate it.

All of which assumes the updates can be trusted. A network held together with constraints and missing logic — the things a 14-point check flags in seconds — cannot tell you what was critical at any data date, and a concurrency analysis built on it is assertion in a high-visibility jacket.

Pacing: the deliberate slow-down defence

The contractor's standard answer to a concurrency allegation is pacing: "we slowed that work deliberately, because your delay meant there was no point finishing it early." Pacing reframes apparent contractor delay as a reasonable response to employer delay — consuming float the employer event created, rather than causing independent delay.

It is a respectable defence with a demanding evidence test. Pacing is a decision, and decisions leave contemporaneous traces: a notice, an email, a resource plan showing crews redeployed, minutes recording the choice. A slow-down explained as pacing for the first time in an expert report, three years later, looks exactly like what it usually is — culpable delay that found a flattering name during disclosure. The geometry matters too: paced work should sit on a near-critical or non-critical chain, consuming float towards an employer-driven completion date. If the allegedly paced work is itself driving completion, it isn't pacing; it's the delay.

Method choice changes the concurrency answer

One last trap for the unwary: the analysis method you chose months earlier quietly shapes the concurrency finding. Windows analysis tends to surface concurrency — when two causes drive the same window, the per-window attribution makes them both visible and forces the argument into the open. A collapsed as-built tends to bury it: remove one party's delays from the as-built model and the model cheerfully reports the project finishing earlier, without volunteering that the other party's delays would have held completion anyway. Neither tendency is dishonest in itself, but an expert who chose the method that happens to hide the concurrency question should expect to be asked why — which is one more reason method selection deserves more care than it usually gets.