Concurrent Delay in Construction: How to Identify, Analyse and Resolve It

Two delay events hit your project at the same time. One is the employer’s fault. One is the contractor’s fault. Both push out the completion date. Who bears the cost? That question has launched more disputes, consumed more expert hours, and generated more contradictory case law than almost any other issue in construction contracts. And if you’re the project manager sitting across the table at a claims meeting, you need to understand exactly how concurrent delay works before you sign off on anyone’s analysis.

Concurrent delay isn’t just a legal curiosity. It determines whether the contractor gets an extension of time (EOT), whether the employer can recover liquidated damages, and whether either party can claim loss and expense. Get the analysis wrong, and you could be agreeing to an outcome that costs your project millions. The principles below sit inside the broader discipline of structured construction schedule analysis, which establishes the schedule integrity that any delay finding ultimately depends on.

Why Concurrent Delay Matters

Bent Flyvbjerg’s database of 16,000 projects across 136 countries, set out in How Big Things Get Done, shows that 91.5% of major projects run over budget, over schedule, or both. When projects run late, the question of who caused the delay becomes a financial dispute. And when multiple delays overlap, concurrent delay is the framework for working out who pays.

Callout box: Only 0.5% of projects in Flyvbjerg’s database delivered on budget, on time, and on benefits. When the other 99.5% go wrong, concurrent delay is often the battleground.

The stakes are high. In the UK, the Society of Construction Law (SCL) Delay and Disruption Protocol devotes an entire section to concurrency. In the US, courts have produced conflicting rulings for decades. In Australia, the position varies by state and contract type. If you’re reviewing a delay claim that alleges concurrency, you need to know whether the analysis is sound and whether the conclusion follows from the evidence.

The California High-Speed Rail project was approved in 2008 with a $33B budget and a 2020 completion target. As of 2024, the estimate sits above $100B, and the project has been beset by delays from every direction: environmental challenges, land acquisition problems, design changes, and contractor performance issues. When multiple delays overlap on a project of this scale, concurrent delay analysis becomes the mechanism for allocating responsibility and cost. Without a rigorous approach, the result is a project where no one is accountable and the taxpayer picks up the bill.

What Is Concurrent Delay?

Concurrent delay occurs when two or more delay events overlap in time and both affect the project’s completion date. The key requirement is that both events must independently cause delay to the critical path. If one event delays the project and the other delays an activity that has plenty of float, you don’t have concurrent delay. You have one real delay and one irrelevant event.

This distinction matters more than most people realise. A surprising number of delay claims allege concurrency based on events that simply occurred at the same time, without demonstrating that both events independently affected the critical path. Timing alone isn’t enough, which is why a sound understanding of the critical path method in construction underpins any defensible concurrency argument.

How Concurrent Delay Differs from Sequential Delay

Sequential delay is straightforward. Event A happens, it pushes out the programme, then Event B happens later. You analyse them in order. The timeline is clean.

Concurrent delay is messier. Events A and B happen in the same period, and both contribute to the same delay to completion. The analyst has to work out: would the project still have been late if only Event A had occurred? Would it still have been late if only Event B had occurred? The answers to those questions determine the outcome.

Types of Concurrency: Literal vs Functional

Literal Concurrency

Literal concurrency means two delay events start and end at exactly the same time and affect the same critical path activities. In practice, pure literal concurrency is almost impossible. Delays rarely start and finish at precisely the same moment. The concept exists in theory, but if someone argues literal concurrency in a real dispute, they’re probably oversimplifying.

Functional Concurrency

Functional concurrency is what most analysts actually deal with. Two delay events overlap in time, affect different activities, but both independently push out the project completion date. The events don’t need to be identical in duration or affect the same activities; they just need to both causally contribute to the same delay.

Most real-world concurrent delay is functional. Consider a project where the employer issues a late design change that delays the structural steel package, and simultaneously the contractor is behind on the concrete works due to poor productivity. Both delays are happening in the same window, both are pushing out completion, but they affect different parts of the programme.

What we found: A concurrent-delay argument has to show two events, each of which independently affected the critical path. The SCL Protocol’s second edition (Core Principle 10 and §10.4) is explicit that the test is independent critical-path effect, not calendar overlap. An event sitting on a near-critical path with float sufficient to absorb it does not satisfy the test, regardless of when it occurred.

What it means: Two delay events landing in the same calendar window are not concurrent in the delay-analysis sense unless each is independently critical. Concurrency arguments tend to fail at this threshold question first.

The Legal Tests for Concurrent Delay

Different jurisdictions and contracts apply different tests to determine whether concurrent delay exists and what the consequences are. Understanding which test applies to your contract is the first step in any analysis.

The But-For Test

The but-for test asks: would the delay have occurred but for the employer’s event? If the answer is yes, meaning the contractor was already delayed by its own event, then the employer’s event didn’t cause the delay to completion. The contractor gets no EOT.

This is the default position in many common law jurisdictions. The SCL Protocol, paragraphs 10.7 to 10.10, discusses competing legal views on whether an Employer Delay following a Contractor Delay is an effective cause of Delay to Completion. The Protocol’s recommended position (paragraph 10.10) is that where a Contractor Delay to Completion has already occurred, a subsequent Employer Risk Event should be seen as not causing further Delay to Completion, and so there is no concurrency. For a fuller treatment of how this plays out in practice, see our guide to the extension of time claim process.

Critics argue this creates a “first past the post” problem, where the party who caused the first delay wins regardless of the other event’s genuine impact.

Dominant Cause Test

The dominant cause test asks: which event was the predominant cause of delay? If one event was clearly more significant than the other, that event determines the outcome.

This approach was considered in City Inn Ltd v Shepherd Construction [2008] in the UK, where the Inner House of the Court of Session held that where delays are truly concurrent, the dominant cause should prevail. The case is controversial: some practitioners welcome it as a pragmatic solution; others argue dominant cause is impossible to determine when two events genuinely contribute equally.

First-in-Time Rule

Under this rule, the first event to cause delay prevails. If the contractor was already in delay when the employer’s event occurred, the contractor bears the consequence. This is a simplification of the but-for approach and has been adopted in some US jurisdictions.

Its limitation is obvious: it ignores the possibility that the second event would have caused delay even without the first. Timing of occurrence doesn’t equal causation.

Apportionment Approach

Some courts and tribunals split the delay between the parties. If both events contributed equally, each bears half. If one was 70% responsible, the cost is apportioned accordingly.

Apportionment between concurrent causes is not generally available under English law (the SCL Protocol’s recommended approach in paragraph 10.10 is to deny concurrency where a Contractor Delay to Completion has occurred first), but apportionment may be available in other jurisdictions and under some standard form contracts. The Scottish courts have been more receptive to apportionment than the English courts.

How to Analyse Concurrent Delays: Step by Step

This is the methodology for performing a concurrent delay analysis that will stand up to scrutiny. Each step builds on the previous one. Skip a step and the whole analysis becomes unreliable.

Step 1: Confirm the Schedule Is Sound

Before you analyse anything, confirm the programme is fit for purpose. A concurrent delay analysis performed on a schedule with broken logic, excessive constraints, or missing links is built on sand.

Run a schedule quality check before you start. The Defense Contract Management Agency 14-Point Assessment provides a practical set of metrics. At minimum, check:

• Missing logic: fewer than 5% of activities should have no predecessors or successors (DCMA metric 1)
• Negative float: should not exist on any activity (DCMA metric 7)
• Hard constraints: flag any schedule with more than a handful, as they override logic
• High duration activities: flag any single activity over 44 working days (DCMA metric 8)

If the programme fails these basic health checks, any delay analysis based on it will be challenged by the opposing party’s expert. Per AACE International RP 29R-03, Section 2 (Source Validation), the validity of the schedule must be established before any forensic analysis is performed.

Callout box: A schedule with 138 hard constraints and 335 positive lags isn’t driven by logic; it’s driven by dates. You can’t trust the float values, and any delay analysis based on this programme will be unreliable. Always check programme health first.

Step 2: Identify All Delay Events

Map every delay event in the analysis period. Categorise each as:

• Employer-caused (variation, late information, access delay)
• Contractor-caused (poor productivity, rework, late procurement)
• Neutral event (exceptionally adverse weather, force majeure)

Each event must be linked to a specific activity or activities in the programme. Vague events like “general project delays” don’t qualify. You need to be able to point to the activity, the planned dates, the actual dates, and the cause.

Contemporaneous records are essential here. Site diaries, daily logs, progress meeting minutes, and correspondence confirm what actually happened and when. A delay event alleged months after the fact, without any contemporaneous record, is unlikely to survive challenge.

Step 3: Determine Critical Path Impact

This is the step most analyses get wrong. Two events happening at the same time is not concurrent delay. Two events both affecting the critical path is.

For each delay event, determine whether it delayed an activity on the critical path. Use the as-built programme to trace which activities actually drove the completion date. If an event delayed an activity with three weeks of float, it didn’t cause concurrent delay. The float would have absorbed the delay.

Near-critical paths matter too. An event that delays an activity with only two days of float could become critical if another event consumes that float. Check the float values at the time of the delay events, not just the current programme.

Step 4: Perform Window Analysis

Divide the project into time windows and analyse each window separately. Windows analysis, as described in AACE RP 29R-03, Sections 3.2 to 3.4 (the observational static-periodic and dynamic methods), examines what happened in each period between programme updates.

Within each window:

1. Identify the critical path at the start of the window
2. Identify all delay events that occurred
3. Determine which events affected the critical path
4. Assess whether remaining events were truly concurrent or merely contemporaneous

Window analysis prevents the common error of treating events from different periods as concurrent. A contractor delay in March and an employer delay in June aren’t concurrent, even if they’re both cited in the same claim.

Step 5: Apply the Relevant Concurrency Test

Determine which legal test applies. Check your contract first; some standard forms specify the approach. If the contract is silent, the governing law of the contract determines the default position.

Then apply the test rigorously. Document the basis for every conclusion. If you’re applying but-for, show the analysis with and without each event. If you’re applying dominant cause, quantify the impact of each event and explain why one dominates.

Don’t mix tests. Pick one, apply it consistently, and state which test you’ve used and why.

Step 6: Prepare the Delay Analysis Report

Your report needs to be defensible, which means it needs to be verifiable. Include:

• The schedule data you started with (the baseline and each update)
• The delay events and their mapping to programme activities
• The critical path analysis for each window
• The concurrency test applied and the contractual/legal basis for it
• The results of the analysis for each window
• Extracts from the programme that support each finding
• References to contemporaneous records that confirm the events

The SCL Protocol (paragraph 11.2 and Introduction §D) emphasises that delay analysis conclusions must be sound from a common sense perspective and supported by a transparent approach to the records and analysis.

Concurrent Delay and Extension of Time Claims

Concurrent delay directly affects EOT entitlement. The basic principle is: if an employer-caused delay event occurs during a period when the contractor is already in concurrent delay, does the contractor still get an EOT?

The answer depends on the test applied. Under the but-for approach, the contractor may lose EOT entitlement if they were already in delay. Under the dominant cause approach, the contractor might get a partial EOT if the employer’s event was a substantial cause.

The SCL Protocol, Core Principles 10 and 14 (paragraphs 10.12 and 14.3), takes a practical position: where true concurrent delay exists, the Contractor should generally receive an EOT (CP 10), but recovery of prolongation compensation is restricted to costs the Contractor can show flow from the Employer Delay rather than the Contractor Delay (CP 14). This is sometimes called the “EOT but no money” approach.

Float ownership also matters. If the contract specifies that float belongs to the project, neither party can consume it to their exclusive advantage. Some contracts allocate float to the employer, which means contractor delays consume float first, and the employer-caused delay that follows may not produce concurrent delay because the float was already gone.

Common Mistakes in Concurrent Delay Analysis

A small set of errors turn up repeatedly in concurrent-delay submissions. The most common are:

Assuming concurrency without critical path evidence. Just because two events happened in the same month doesn’t make them concurrent. One might be on a parallel path with abundant float. Show the float values. Show the critical path.

Ignoring schedule quality before analysis. Performing a delay analysis on a schedule with 15% missing logic is like building a structural assessment on a foundation you haven’t tested. The numbers might look right, but they’re unreliable.

Failing to use the correct contractual test. A contractor who argues dominant cause when the contract specifies but-for is arguing the wrong case. The test is contractual first, legal second.

Not considering near-critical paths. An event that delays an activity with one day of float might not be on the critical path today, but if the critical path shortens by one day tomorrow, it suddenly is. Near-critical paths need the same scrutiny as the critical path.

Confusing contemporaneous events with concurrent delay. Contemporaneous means happening at the same time. Concurrent delay means both events independently delay the completion date. They’re not the same thing.

Real-World Concurrency: What Project Data Shows

The Holyrood Parliament Building in Scotland opened around three years later than originally programmed, with a final outturn of approximately £431 million against an initial estimate of around £40 million at the start of construction (Auditor General for Scotland, 2004). The Auditor General’s report identified multiple overlapping causes of delay: design changes, construction issues, and political interference. It was, in effect, a case study in concurrent delay on a large scale. Multiple parties contributed to the same delay period, and the subsequent arguments over who was responsible consumed years of legal proceedings. The lesson isn’t about the building itself; it’s about what happens when concurrent delays aren’t identified and managed in real time.

In professional practice, independent experts frequently find that delay analyses submitted with EOT claims either fail to demonstrate true concurrency or apply the wrong legal test. Two events from different project phases that are alleged as concurrent despite being months apart will not survive a window-based review, because the windows themselves show the delays as sequential rather than concurrent.

The practical takeaway is this: if you’re reviewing a concurrent delay claim, ask for the critical path analysis for each alleged concurrent event. If the claimant can’t show that both events independently affected the critical path in the same window, the concurrency argument doesn’t hold. Our walkthrough of forensic EOT claim analysis covers the evidence trail you should expect to see at this stage.

Tools for Concurrent Delay Analysis

Oracle Primavera P6 is the industry standard for schedule management and delay analysis. Most concurrent delay analyses will be performed using P6 data, either through direct schedule manipulation or through comparison of XER file exports.

XER file analysis allows you to compare programme versions, identify changes between updates, and verify that the schedule logic is consistent with what was submitted. This is particularly important when the contractor has made changes to logic, durations, or constraints between updates, which can distort the delay analysis.

ScheduleLens automates the schedule health checks that must precede any delay analysis: missing logic counts, constraint audits, float analysis, and critical path validation. For concurrent delay, the first question isn’t “which test applies” but “is this programme reliable enough to analyse?” ScheduleLens answers that question before you spend expert hours on an unsound schedule.

Standards and References

What to Do Next

When you receive a delay claim alleging concurrent delay, your first move should be to check the programme’s health. Run the quality checks. Verify the logic. Then ask the claimant to demonstrate, for each alleged concurrent event, that both events independently affected the critical path in the same analysis window. If they can’t, there’s no concurrency to argue about.

Concurrent delay is contentious because the stakes are high and the analysis is complex. But the principles are clear: sound schedule first, critical path evidence second, correct contractual test third. Get those three things right, and you’ll be able to assess any concurrent delay claim that lands on your desk.

This article is for educational purposes and does not constitute legal advice. Always consult qualified legal professionals for advice on specific contractual disputes.