How to Identify a Concurrent Delay, Part 2
In our previous Concurrent Delay posts, we defined concurrent delays and described how the identification of concurrent delays depended on the definition of the “critical path.” In this second part of our “How to Identify a Concurrent Delay” series, we will discuss the two different concurrent delay theories.
AACE International’s Recommended Practice No. 29R-03, Forensic Schedule Analysis, identifies these two types of concurrent delay theories as literal concurrency and functional concurrency. The basic difference between the two is the “timing” of the alleged delays. Under the literal concurrency theory, for two delays to be considered concurrent, the alleged delays must delay the project’s critical path and the forecast completion date at “the same time.” Said another way, the two delays must occur simultaneously.
Under the functional concurrency theory, the alleged delays must only delay the project’s critical path within the same analysis time period, which is typically between consecutive schedule updates, and are not required to have actually occurred on the same days.
In terms of quantifying the concurrency of two alleged concurrent delays, a literal concurrency adherent would argue that the project schedule enables the parties to identify the initial critical path work activity on a daily basis, thus enabling the parties to likewise identify the days during the schedule update period when the alleged concurrent delays were literally concurrent. A functional concurrency adherent would argue that the project schedule can only identify the initial critical path work activity on the data date of an update. Because of this perceived limitation, the functional concurrency adherent would advocate increasing the measurement period to determine concurrency from a day to the entire update period.
To explain this difference, consider the following scenario. Assume on our example project that two delays occurred during the month of May, and both delays would have independently delayed the project’s critical path. The first delay started on May 2nd and ended on May 10th, and the second delay started on May 12th and ended on May 20th.
In this example, a literal concurrency adherent would say that because the first delay began and ended before the second delay started, that the two delays were not concurrently critical. To support this position, he or she would assert that when the first delay occurred from May 2nd through May 10th, this delay created float to all other work paths. Because the first delay created float, the second delay that occurred between May 12th and May 20th was on a path with float, and not on the critical path. The second delay couldn’t have delayed the project because the first delay had already delayed the project. Therefore, the literal concurrency adherent would assign responsibility for the entire delay to the first delay.
The functional concurrency adherent would say that because each delay would have separately delayed the critical path during the period and the project’s forecast completion date, had it not been for the other delay. They could also say that some schedules may lack the precision to accurately identify the initial critical path activity on a daily basis between two updates, and that the two delays should be thought of as being concurrent. Therefore, the functional concurrency adherent would assign the delay to both the first and second delays concurrently.
There is not necessarily an industry consensus regarding literal and functional concurrency, because project facts and the completeness and accuracy of project documentation differs significantly from project to project. Moreover, concurrency disputes are very, very fact intensive and require analysts to answer the question, “What did the parties know and when did they know it?” However, once you decide on a theory, whether it be literal or functional, you are most likely stuck with it for the entire analysis.
If you have any interest or questions about this topic, please feel free to reply or contact me at mark.nagata@traunerconsulting.com.
