This article is part of the Delay Analysis 101 series, which is also available as a LinkedIn newsletter.
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”):
- Whilst for the time slice method the critical path is assessed via the updated schedules of the project, the APvAB method allows a wider range of sources: it could be based on schedules, but also monthly progress reports, productivity rates, or any other tool or data which allows to determine which sequence dominated the project completion date at a given data date.
- In the APvAB method, the project is broken down into windows of time: it could be based on the data dates of schedule updates (as is the case for time slices), but also any event which allows to split the assessment into manageable periods of time. The choice of the windows boundaries is the object of an article I am currently working on for our Cutting Edge Delay Analysis Series newsletter.
- The optional step of the time slices method is mechanically similar to the assessment of a re-baseline under the APvAB method. This will also be addressed in a future article dedicated to the full implementation of the as-planned versus as-built in windows method.
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.
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:
- The Impacted As-Planned method
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?
- The Time Impact method
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?
- Time Slices method
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?
- The As-Planned versus As-Built in Windows method
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?
- The Retrospective Longest Path method
In the end, what was the real effect of the delays to the activities which actually drove the completion date?
- The Collapsed As-Built method
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?
