Concurrent Delay

Definition

Concurrent delay arises when two or more delay events overlap in time and each, on its own, would have delayed the project's completion date. Typically one event is an employer risk (owner-caused or neutral, such as a late design release or exceptional weather) and the other is a contractor risk (contractor-caused, such as slow procurement or resource shortages). The legal and commercial question is: who pays for what? Concurrent delay is one of the most litigated topics in construction contracts and one of the least well understood on site — most disputes I have seen involve at least one party quietly hoping the other has not spotted the concurrency.

Why It Matters

The answer determines whether the contractor gets time (EOT) only, time and money (EOT + prolongation), money only, or nothing. Different jurisdictions and contract forms answer this differently. English law under the SCL Delay and Disruption Protocol (2nd ed.) generally allows an EOT for concurrent delay but disallows prolongation costs for the concurrent period. US federal contracts have historically used "apportionment" where feasible. FIDIC contracts as of the 2017 suite explicitly cross-reference the SCL approach in guidance. Getting this wrong on a live claim can be a seven-figure error.

Real-World Construction Example

On a 42-storey commercial tower, the owner released the podium façade design six weeks late. In the same window, the contractor's precast subcontractor entered administration, halting panel supply for eight weeks. The critical path ran through the façade. The contractor claimed a full eight-week EOT with prolongation of $1.8m. Analysis under a time-impact approach showed six weeks were genuinely concurrent — both events would independently have delayed completion by six weeks — and two weeks were contractor-only. The final award: eight weeks EOT (the contractor is not penalised on time), but prolongation costs paid for only the two weeks of contractor-only delay. The owner accepted the analysis because the schedule quality was strong: baseline logic was defensible and the contemporaneous updates showed the concurrency clearly.

Real-World IT / Agile Example

Concurrent-delay reasoning applies to fixed-price software programmes with hard external dates. A regulatory reporting platform had a mandated go-live. Two things slipped in the same eight-week window: the client's data-migration source (a legacy mainframe extract) arrived seven weeks late, and the vendor's identity provider integration was five weeks behind due to internal staffing gaps. In the eventual commercial settlement, the parties agreed the delay was concurrent for five weeks and client-only for two. The vendor absorbed its own costs for the five concurrent weeks; the client covered extension costs for the two client-only weeks. The lesson translates cleanly from construction: without contemporaneous evidence of which team was blocking which, the concurrency argument evaporates.

Analytical Methods

• Time impact analysis — insert each delay event into the schedule at the point in time it occurred, and observe its independent impact on completion.
• As-planned vs as-built windows — compare planned progress to actual progress in short windows (typically monthly) and attribute delay in each window.
• Collapsed as-built — remove each delay event from the as-built schedule to see how completion would have shifted without it.

Expert Tips

• Document contemporaneously. The single biggest driver of concurrent-delay outcomes is the quality of the monthly progress records. Retrospective reconstruction is always inferior.
• Update the schedule monthly with genuine as-built dates. A schedule that only shows "planned" progress is useless for concurrency analysis.
• Separate float ownership. Contracts that say who owns float remove one entire argument.
• Do not conflate "concurrent" with "sequential". Two delays back-to-back are not concurrent; only overlapping ones are.
• Get delay analysts involved early. A £5,000 early advisory review often prevents a £500,000 late dispute.

Common Mistakes

• Claiming full prolongation costs for concurrent periods (rarely succeeds).
• Ignoring contractor-caused delay when arguing an EOT — courts and adjudicators are unimpressed.
• No contemporaneous schedule updates, so concurrency cannot be proved either way.
• Confusing concurrency with cumulative delay from many small unrelated events.
• Applying US "apportionment" logic under an English-law contract (or vice versa) — the analytical rules differ.

Practical Lessons Learned

• The party with the better schedule almost always wins the concurrency argument, regardless of the underlying facts.
• Standing joint sit-downs between the owner's PM and the contractor's planner every month — reviewing progress line by line — dramatically reduce eventual dispute cost.
• When both sides agree in real time that a period was concurrent, settlement is fast; when one side pretends concurrency did not exist, disputes drag out for years.

Key Takeaways

• Concurrent delay = overlapping owner-risk and contractor-risk events, each independently critical.
• Under SCL and most modern contract forms: EOT is granted, prolongation costs are not, for the concurrent period.
• Contemporaneous schedule updates decide most concurrency arguments.
• Different jurisdictions apply different tests — check your contract's governing law.

Related Encyclopedia Entries

• Extension of Time
• Critical Path Method
• Float Management
• Time Impact Analysis

Related Research Articles, Case Studies & Tools

• Delay Analysis Templates
• Project Controls Academy: Claims & Delay
• Concurrent delay case studies