Concurrent Delays and Pacing in Construction Contractor Delay Claims

AuthorBy Daniel G. Quackenbush and Kenneth A. Slavens
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.
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.
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.
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

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT