Concurrent Delays and Pacing in Construction Contractor Delay Claims

• Author: By Daniel G. Quackenbush and Kenneth A. Slavens
• Pages: 15-22

THE CONSTRUCTION LAWYER 15Volume 41, Issue 3

Published in

The Construction Lawyer

, Volume 41, Number 3. © 2021 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion thereof may not

be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.

CLAIM EVALUATION

Concurrent Delays and Pacing

in Construction Contractor

Delay Claims

By Daniel G. Quackenbush and Kenneth A. Slavens

In construction contractor delay

claims, it is almost guaranteed

that the owner will respond to

the contractor’s delay claim

with the argument that another

delay for which the contrac-

tor is responsible is concurrent

with the claimed owner delay.

The intent of this response is

to deny payment of time-related

overhead (TRO) and other delay

damages because the contrac-

tor also caused the work to be

delayed. If there is in fact a

concurrent delay, the result is

that neither party can collect

damages from the other for the

period of concurrent delay.

This result is based on the

very old and well-supported legal principle that you

cannot sue somebody for failure to meet contractual

obligations if you fail to meet your own. Therefore, if

the contractor still would have nished late even if the

owner’s delay had not occurred, no damages will be paid

to or from either party.1 This evaluation is sometimes

called the “but-for” principle. The contractor would not

have spent the additional TRO but for the owner’s delay.

If that proves true, then the contractor should be paid

for its TRO. If the contractor caused a concurrent delay,

then the claim would not meet the but-for criteria and

the contractor should not be paid its TRO.

When the contractor hears the owner’s defense of con-

current delay, the contractor’s natural response is that it

was pacing, or performing work at a pace based on the

owner’s delay. The concept of pacing is that the contrac-

tor could have avoided what is or looks like a contractor’s

concurrent delay if it had been necessary—that is, had

the delay been on the critical path. These claims and

responses can be difcult to properly evaluate.

This article sets out a procedure to evaluate claims of

concurrent delay and pacing using critical path method

(CPM) scheduling.2 We note that, although the appli-

cable contract provisions can affect a delay analysis, the

authors have not seen a contract that sufciently iden-

ties how concurrent delays should be determined, nor

have the authors seen a contract that explicitly addresses

pacing. An important part of the concurrency evalua-

tion that we emphasize here is to determine if pacing has

occurred. This article will provide guidance for the proper

evaluation of concurrent delays and pacing for the most

common type of CPM-based delay claims.

Def‌initions

To begin with, we will dene the key terms discussed in

this article. “Concurrent delay” refers to a delay when

both owner and contractor contribute signicantly to the

delay period by separate and distinct actions that inde-

pendently affect the critical path of the project.

3

When

two or more contracting parties (one could be a force

majeure event) cause separate and independent critical

path delays within the same time period, a concurrent

delay is present.

“Pacing” refers to one of three separate actions: (1)

the act of intentionally slowing down work progress on

a task or group of tasks, or electing not to employ efforts

to mitigate or accelerate work progress on a task or group

of tasks, in reaction to an unrelated delay; (2) the contrac-

tor’s management decision to use time from owner-caused

delay that is driving project completion to improve ef-

ciency or reduce costs to their own account;4 and (3) the

contractor doing nothing to change its plans going for-

ward because it will not improve the completion date.

We also provide a denition of “critical path.” There

are three common denitions of the critical path. The rst

denes critical path as one or more continuous chains

of activities and relationships with the lowest oat value

running from the start event to the nish event in the

schedule. The second states that the critical path is made

up of activities that, if not completed within the sched-

uled performance time, will cause the completion of the

project to be delayed. The third denes the critical path

as the longest path of activities and relationships from

the start of the project (or current point in the progress)

all the way through to the completion of the work. While

each denition is correct, and there is some redundancy,

software algorithms (such as intermediate completion

Daniel G. Quackenbush

Kenneth A . Slavens