Delay Analysis In Infrastructure & Construction: Choosing The Right Methodology At The Right Time

Every delay event changes more than a programme. It changes the contractual position of the parties and, eventually, the evidence available to prove it.

In large-scale construction projects, there is a greater likelihood that both the Contractor and Employer faces various kinds of hinderances, which affect the fulfillment of their respective Contractual Obligations. It becomes a cause of major concern, when these delay events, fall on the critical path and ultimately affect the scheduled completion date.

In such circumstances, delay analysis becomes an important mechanism for both Contract Administration and subsequently during Dispute Resolution. During the course of execution, it enables the parties to assess the impact of a delaying event on the prevailing programme, determine its effect on the critical path and completion date, and evaluate any resulting entitlement to extension of time or the need for mitigation. Once the project is completed, or a dispute has arisen, delay analysis assumes a retrospective and forensic character, assisting in the identification of the actual causes of delay, the allocation of responsibility between the parties, and the assessment of the contractual and financial consequences flowing from such delay events.

That, in turn, gives rise to a more important question: which delay analysis methodology should be used, and when? The distinction is not merely academic. A methodology suited to assessing delay as it unfolds may be wholly inappropriate when the same delay is examined retrospectively after completion. The choice of methodology, therefore, cannot be divorced from the stage of the project or the purpose of the inquiry.

Critical Delay Comes Before Methodology

A delay event does not, by itself, establish entitlement to an extension of time or cost. During the lifecycle of an Infrastructure Project, it encounters numerous impediments, but only those which affect the path driving completion can cause critical delay. The analysis must connect the event to the affected activity, establish its criticality at the relevant time, and demonstrate the effect on completion.

Therefore, a critical path analysis, is a crucial tool to prove the causative effect of the event on the Project completion. In the case of John Barker Construction Ltd. v. London Portman Hotel Ltd. the Hon’ble Court did not criticize the absence of a particular software technique, but that the Extension of Time (EOT) assessment lacked a logical and methodical analysis of the effect of the relevant events on the contractor's programme.¹

Importance of a Sound Baseline Programme

The soundness of a delay analysis is inseparable from the quality of the programme on which it is based. A Baseline Programme is intended to record the contractor’s planned sequence, logic and path to completion. Therefore, it becomes important for the Employer to approve the Baseline Programme after checking that the same is free from material defects in logic, sequencing, activity relationships, excessive leads or lags, unrealistic float, open-ended activities and other programming anomalies.

This is why programme health checks, such as the DCMA-14 assessment, are important.² They provide a structured means of testing whether the Baseline Programme is sufficiently sound for subsequent reliance, by examining matters such as open ends, leads and lags, relationship types, float, constraints and activity durations. These are not merely programming irregularities. If left unidentified at the baseline stage, they may later influence the calculation of the critical path and, in turn, compromise the reliability of the delay analysis founded upon it. Therefore, a well-made Programme from that start can beaccurately updated as and when the need for the same arises and can be used as irrefutable evidence at the time of dispute.³

The Six Methodologies Recognised by the Society of Construction Law (SCL) Protocol

The Second Edition of the SCL Protocol identifies the six most commonly used methodologies adopted to carry out delay analysis. The major distinction between these methodologies lies in the direction of the analysis, namely whether it proceeds from cause to effect or from effect to cause, and in the temporal standpoint from which criticality and delay are assessed. The SCL Protocol prescribes selection of a particular methodology based on the contract, nature of the project and delay events, quality of the programmes and records, time and cost available, and the forum in which the analysis is being undertaken.

1. During Execution
   The analysis carried out by the Contractor and the Employer during the execution of the Contract is ordinarily Prospective. Impacted As-Planned Analysis measures delay by inserting the relevant delay events into the original Baseline Programme. The SCL Protocol recognises the limitations of this approach and indicates that it is generally more suitable at the early stages of project execution, when the baseline still provides a reasonable representation of how the works are intended to proceed. As construction progresses, however, actual performance may depart from the original plan through resequencing, mitigation, changes in logic, altered resource deployment, or other intervening events. In such circumstances, simply impacting the original baseline may no longer reflect the project as it was actually being executed and can therefore produce an artificial assessment of delay.⁴
   
   Time Impact Analysis (TIA) goes further by inserting the delay event into the programme, close to the actual date on which the delay occurred and therefore it reflects progress at or around the time the event arose. For contemporaneous EOT administration, TIA is a preferred approach as the parties can assess what mitigation measures can be adopted to reduce the impact of the critical activities on the completion of the project.⁵
   
   
2. At the time of Dispute
   Once the analysis is undertaken after the relevant events have occurred, the inquiry becomes retrospective and the important question now to be addressed is what activities actually controlled completion, what delay occurred on those activities, and what was the main cause for that particular delay event?
   
   In Time Slice Windows Analysis⁶, the project is divided into successive periods and the contemporaneous critical path is identified from the programme updates in each window, with the causes of the delay then examined retrospectively. As-Planned versus As-Built Windows Analysis⁷ follows a similar effect-and-cause approach, but derives criticality by comparing the baseline programme with actual progress in each window. Retrospective Longest Path Analysis⁸ identifies the as-built critical path retrospectively, generally by tracing the longest continuous sequence of critical activities back from actual completion, and then investigates the events responsible for delay along that path. Collapsed As-Built Analysis⁹ adopts a different, cause-and-effect approach. The selected delay events are removed from a logic-linked as-built programme and the programme is recalculated to determine the completion date that would have been achieved but for those events.

The Expert Must Not Let the Methodology Write the Facts

The greatest faux pas that a lawyer can make is methodology-driven advocacy. In the case of Great Eastern Hotel Co. Ltd. v. John Laing Construction Ltd¹⁰., the Hon’ble Court has recognized that the biggest flaw a party can make while adopting any methodology prescribed by the SCL Protocol is to ignore the contemporaneous documents. The expert cannot pick and choose the documents from the record that work in their favor and paint a completely different picture from the work executed on the ground. The significance of the decision is not that retrospective analysis is impermissible. Rather, it demonstrates that the analytical model must remain subordinate to the established facts.

Conclusion

There is no right methodology for every Construction dispute. The delay analysis methodology to be adopted by the expert must not only depend on what time of the project the method is being used to ascertain delay but rather should be dependent upon the nature, extent and quality of the records and programme actually available. A critical activity identified by the software during a particular time period should not be in contradiction with the ground reality. Delay analysis is therefore not a competition between programme models. Its real function is to answer the right question at the right time and to demonstrate, from the contract and the contemporaneous facts, what drove completion, when it did so, and why.

Footnotes

1. John Barker Constr. Ltd. v. London Portman Hotel Ltd., 83 B.L.R. 31 (Q.B. 1996) (Eng.).

2. Def. Contract Mgmt. Agency, Earned Value Management System (EVMS) Program Analysis Pamphlet (PAP), DCMA-EA PAM 200.1, § 4.0, at 28–32 (Oct. 29, 2012).

3. P J Keane and A F Caletka, Delay Analysis in Construction Contracts (1st edn, Wiley-Blackwelll 2008) 179.

4. Soc’y of Constr. L., Delay and Disruption Protocol ¶ 11.6(a), at 35 (2d ed. 2017).

5. Soc’y of Constr. L., Delay and Disruption Protocol ¶¶ 4.7–4.12, at 24–25, ¶¶ 11.4(a), 11.6(b), at 33, 35 (2d ed. 2017).

6.Soc’y of Constr. Law, Delay and Disruption Protocol 34–36 ¶¶ 11.5, 11.6(c) (2d ed. 2017).

7. Soc’y of Constr. Law, Delay and Disruption Protocol 34, 36 ¶¶ 11.5, 11.6(d) (2d ed. 2017).

8. Soc’y of Constr. Law, Delay and Disruption Protocol 34, 36 ¶¶ 11.5, 11.6(e) (2d ed. 2017)

9. Soc’y of Constr. Law, Delay and Disruption Protocol 34, 37 ¶¶ 11.5, 11.6(f) (2d ed. 2017).

10. Great E. Hotel Co. Ltd. v. John Laing Constr. Ltd., 2005. EWHC (TCC) 181, 111., 117., 128., 99 Con. L.R. 45 (Eng