Critical path and delay measurement perspectives, à la carte? – Part 2
Orizo Consult International
Cutting Edge Expert Services - Reach a strong and legitimate position in your construction disputes
In the forensic scheduling world, two pieces of literature are regularly quoted when it comes to relying on a standard method of delay analysis: the Delay and Disruption Protocol (2017) of the Society of Construction Law (SCL), and the International Recommended Practice 29R-03 on Forensic Schedule Analysis (2011) of the Association for the Advancement of Cost Engineering (AACE). This article focuses on the methods described in the SCL Delay and Disruption Protocol (the “SCL Protocol”).
In previous articles, we have seen that?delay measurements can follow distinct perspectives. We have also seen that?critical paths could follow distinct perspectives?too. In this two-part article, we will see which method relies on which delay and critical path perspective, and what are the consequences of choosing one combination over another. Part 1 is available here.
Note: Some display glitches have been reported with the display of animated images via the LinkedIn phone App. Watch via the LinkedIn web page for the best experience.
Six methods, six questions (continued)
The Impacted As-Planned and Time Impact analysis methods were covered in Part 1. The remaining four methods are addressed below.
The Time Slices method
This method answers a question which could be phrased as follows:
As the project developed, what was the real effect of the delays to the activities which were expected to be driving the completion date during each schedule update? Optionally: and what was the likely effect of the rescheduling measures established during each schedule update?
The time slices method consists in assessing the delays impacting the project completion date between various schedule updates, hence a reliance on the contemporaneous critical path at various points in time (data dates). The main step of the method focuses on the real effects of the delays which occurred along this critical path: delays are assessed retrospectively.
In practice, this method is achieved by comparing the project completion date of a schedule against that of the previous schedule: the shift of the project completion date represents the as-built delay incurred between the two data dates. The period between the two dates is called a time slice.
However, when the schedule updates not only include as-built progress updates, but also changes to the forecast durations and/or logic in the remaining works, as-built delays alone do not allow to reconcile the shift of the completion milestone. In that case, an additional step is required, which consists in assessing the effect of the changes in the prospective side of the schedules. This is because the date of the completion milestone results from a combination of the delays incurred to date and the forecast for further delays or accelerations. The extra step answers the optional question, which aims to identify these as-planned delays and thus to fully bridge one schedule update to the next.
The time slices method is more complex than the previous methods because it requires several intermediate steps which are then repeated for each schedule update. Here below is an overall illustration of the mechanisms involved for a first time slice where both as-built and as-planned delays occurred. The full implementation details of this method will be covered in a dedicated article.
The As-Planned versus As-Built in Windows method
This method answers a question which could be phrased as follows:
As the project developed, what was the real effect of the delays to the activities which were expected to be driving the completion date at various points in time?
Note how this question is similar to that of the time slices method. It consists in assessing the delays driving the project completion date at various points in time (data dates), hence a reliance on a series of contemporaneous critical paths (one for each data date). The aggregation of this set of contemporaneous critical paths makes up for what is called the actual critical path. The method also focuses on the real effects of the delays which occurred along the critical path: delay is assessed retrospectively.
To some extent, the time-slice method is a special case of the as-planned versus as-built method (“APvAB”):
The method consists in (i) establishing the as-built unfolding of project activities, (ii) identifying the actual critical path, (iii) splitting the project into windows of time, (iv) measuring the project delay at the boundary of each window, and (v) identifying the events which were responsible for the project delay to have changed between the start and the end of the window. Whilst the detailed implementation will be addressed in the future dedicated article, an overview is available below.
The Retrospective Longest Path Method
This method answers a question which could be phrased as follows:
In the end, what was the real effect of the delays to the activities which actually drove the completion date?
This question is similar to that of the as-planned versus as-built method. This is because this method is similar to the APvAB in all points, but the assessment of the critical path. Instead of relying on contemporaneous or actual critical paths, this method is based on the sequence of activities which did eventually drive the project completion date. It relies on the as-built critical path, which is retrospective.
领英推荐
The general idea for this method is the same as the as-planned versus as-built, except for the critical path which is based on a reconstruction of the events after the facts, instead of being based on the updated forecast which were available at the time. The retrospective longest path delay analysis method considers the sequence of events disregarding the facts that such events may have not been predictable (in “hindsight”).?On the other hand, the APvAB method considers only the information known at the time the delay events took place (in “blindsight”). The strengths and weaknesses of each will be addressed in a future article.
The Collapsed As-Built method
This method answers a question which could be phrased as follows:
For a given set of delay events, when would the project have been completed, assuming that, in absence of these events, the unimpacted tasks of the project would have taken the same duration as what they actually did?
This method is typically performed once the project is completed. It seeks to identify what the project completion would have been, should some selected delay events had not occurred. It is also known as the but-for delay analysis method, because the objective is to establish what would have happened in absence of some events.
The collapsed as-built method is seducing because it seems elegant and intuitive: extract delay events from the as-built programme and compare the actual project completion date with the now collapsed as-built programme.
The SCL Protocol defines the critical path and delay assessments of this method as retrospective. This is because the input information relies on as-built data: as-built programme and as-built duration of the delay events. Whilst one would assume that as-built inputs can only produce as-built conclusions, there is one major subtility: the method assumes that in absence of some delay events, the duration of the unrelated tasks would have remained identical to the actual duration. In reality, it is likely that a project manager would have taken different decisions if some events would have not occurred. This is one of the largest limitations of the collapsed as-built method, which we will explore in greater details in a future article.
Summary
The six delay analysis methods described by the SCL Delay and Disruption Protocol rely on various combinations of prospective, retrospective, and contemporaneous delay or critical path perspectives. This is because they answer different questions:
At the beginning of the project, what was the likely impact of a given set of delay events, assuming that but for these delays, the rest of the project would develop as planned by the Baseline?
At a given data date, what was the likely impact of a given set of delay events, assuming that but for these delays, the rest of the project would develop as planned by the schedule updated at the data date?
As the project developed, what was the real effect of the delays to the activities which were expected to be driving the completion date during each schedule update? Optionally: and what was the likely effect of the rescheduling measures undertaken during each schedule update?
As the project developed, what was the real effect of the delays to the activities which were expected to be driving the completion date at various points in time?
In the end, what was the real effect of the delays to the activities which actually drove the completion date?
For a given set of delay events, when would the project have been completed, assuming that, in absence of these events, the unimpacted tasks of the project would have taken the same duration as what they actually did?
About the Author
Construction delay Expert?Ama?l Olivier?is Founder of?Orizo Consult. He cumulates over a decade of delay analysis know-how, including the review of major landmark projects across more than 25 countries. He excels in complex infrastructure and energy investments, having assessed projects ranging from 10 to 3,500 million USD in capital value. He testifies in English, French, and Spanish.
The concepts presented in this article are orientative and have been simplified for the purpose of addressing a wide audience. The opinions are these of the author at the time of writing, not necessarily these of Orizo Consult. Each case includes its own particularities, which is why we do not pretend to be providing professional advice through this content.