Project Management

Concurrent Delay

Two or more delay events affecting the schedule at the same time, with at least one caused by each party. A common claims defense.

Concurrent delay occurs when two or more independent delay events affect the critical path during the same time period, with at least one caused by the owner and at least one caused by the contractor. The classic example: the owner is late on a design RFI response while the contractor is also behind on a different critical activity. Both delays would extend the project independently. The question is how to allocate responsibility.

Most jurisdictions follow some version of the rule: time is granted but money is not. The contractor gets a non-compensable time extension (no liquidated damages) but cannot recover its delay damages because its own concurrent delay would have caused the same delay anyway. Establishing concurrency requires solid baseline scheduling and contemporaneous schedule updates that show what was actually on the critical path on each day in question. This is why baseline integrity matters so much.

Frequently asked questions

What is the difference between concurrent and serial delay?+

Serial delay is one party causing delay, then the other party causing a different delay later. Concurrent delay is both parties causing delays at the same time, both affecting the critical path. Concurrency is harder to allocate.

How do owners use concurrent delay as a defense?+

Owners argue that even if the owner caused some delay, the contractor was also independently behind, so the project would have been late anyway. Without solid contemporaneous schedule documentation, the defense often succeeds.

How do contractors prove non-concurrent delay?+

Maintain a baseline schedule, update it monthly, document the actual critical path on each update, and identify which party caused each delay event in real time. Reconstruction analysis after the fact is much weaker than contemporaneous records.

Related terms