The Society of Construction Law Delay & Disruption Protocol
The Society of Construction Law (UK) first published their Delay and Disruption Protocol in October 2002 and have since provided an updated version in February 2017. The Protocol aims to provide guidance on issues that arise in construction contracts in relation to time and delay events. It was published as a guide and not a document that becomes apart of the contract or any statement of law.
As we are working through delay claims we are finding that this document is referenced more and more, so thought it would be insightful to review the different methods of delay analysis. The Protocol reviews six delay claim methodologies:
1. Impacted as Planned Analysis
2. Time Impact Analysis
3. Time Slice Windows Analysis
4. As-Planned versus As Built Windows Analysis
5. Retrospective Longest Path Analysis
6. Collapsed As-Built Analysis
The protocol presents a clear and concise table which details each delay methodology, the type of analysis and whether the methodology is a prospective or retrospective methodology. It also details the type of information required for each delay methodology.
1. Impacted as Planned Analysis is defined as the following:
The impacted as-planned analysis method involves introducing delay event sub-networks into a logic-linked baseline programme and its SCL Delay and Disruption Protocol 2nd Edition: February 2017 35 recalculation using CPM programming software in order to determine the prospective impact these events have on the predicted contract completion dates shown within the baseline programme. Before embarking upon the analysis, the analyst needs to confirm that the sequences and durations for the works shown in the programme are reasonable, realistic and achievable and properly logically linked within the software, to deal with the risk that the baseline programme contains fundamental flaws which cannot be overcome.
In general, this is thought to be the simplest and least expensive form of delay analysis, but has material limitations, principally because it does not consider actual progress and changes to the original planned intent. The product of this method of analysis is a conclusion as to the likely effect of the modelled delay events on the baseline programme. In limited circumstances this analysis may be deemed sufficient for assessing EOT entitlement. Such circumstances include where the impacted as-planned method is dictated by the terms of the contract and/or where the delay events being considered occurs right at the outset of the works.
2. Time Impact Analysis is defined as the following:
The time impact analysis involves introducing delay event subnetworks into a logic-linked baseline programme and recalculation of this updated programme using CPM programming software in order to determine the prospective impact the delay event would have on the then predicted completion dates. The baseline programme for each analysis can be either a contemporaneous programme or a contemporaneously updated baseline programme (i.e. an Updated Programme), the difference being the revised contemporaneous programme may have logic changes / activity / resource changes from the original baseline programme. In either case, the analyst needs to verify that the baseline programme’s historical components reflect the actual progress of the works and its future sequences and durations for the works are reasonable, realistic and achievable and properly logically linked within the software.
Mitigation and acceleration already incorporated into the updated baseline programme need to be considered as these can conceal or distort the projected impact of the delay events. The number of delay events being modelled has a significant impact on the complexity and cost of deploying this method. The product of this method of analysis is a conclusion as to the likely delay of the modelled delay events on the programme/critical path that is most reflective of the contemporaneous position when the delay events arose. This method usually does not capture the eventual actual delay caused by the delay events as subsequent project progress is not considered. This method is also described in the guidance to Core Principle 4 in the context of a contemporaneous assessment of an EOT application.
3. Time Slice Analysis is defined as the following:
The time slice analysis method is the first of two ‘windows’ analysis methods. This method requires the analyst to verify (or develop) a reliable series of contemporaneously updated baseline programmes or revised contemporaneous programmes reflecting an accurate status of the works at various snapshots (being the time slices) throughout the course of the works. Through this process, the progress of the works is SCL Delay and Disruption Protocol 2nd Edition: February 2017 36 divided into time slices.
The time slices are typically carried out at monthly intervals. The series of time slice programmes reveals the contemporaneous or actual critical path in each time slice period as the works progressed and the critical delay status at the end of each time slice, thus allowing the analyst to conclude the extent of actual critical delay incurred within each window. Thereafter, the analyst investigates the project records to determine what events might have caused the identified critical delay in each time slice period.
For each time slice programme the analyst needs to verify that the historical components reflect the actual progress of the works and that its future sequences and durations for the works are reasonable, realistic and achievable and properly logically linked within the software.
4. As Planned versus As-built Windows Analysis is defined as the following:
The as-planned versus as-built windows analysis method is the second of the ‘windows’ analysis methods. As distinct from a time slice analysis, it is less reliant on programming software and usually applied when there is concern over the validity or reasonableness of the baseline programme and/or contemporaneously updated programmes and/or where there are too few contemporaneously updated programmes. In this method, the duration of the works is broken down into windows. Those windows are framed by revised contemporaneous programmes, contemporaneously updated programmes, milestones or significant events. The analyst determines the contemporaneous or actual critical path in each window by a common-sense and practical analysis of the available facts.
As this task does not substantially rely on programming software, it is important that the analyst sets out the rationale and reasoning by which criticality has been determined. The incidence and extent of critical delay in each window is then determined by comparing key dates along the contemporaneous or actual critical path against corresponding planned dates in the baseline programme.
Thereafter, the analyst investigates the project records to determine what delay events might have caused the identified critical delay. The critical delay incurred and the mitigation or acceleration achieved in each window is accumulated to identify critical delay over the duration of the works.
5. Retrospective Longest Path Analysis is defined as the following:
The retrospective longest path analysis method involves the determination of the retrospective as-built critical path (which should not be confused with the contemporaneous or actual critical path identified in the windows methods above). In this method, the analyst must first verify or develop a detailed as-built programme. Once completed, the analyst then traces the longest continuous path backwards from the actual completion date to determine the as-built critical path.
The incidence and extent of critical delay is then determined by comparing key dates along the as-built critical path against corresponding planned dates in the baseline programme. Thereafter, the analyst investigates the project records to determine what events might have caused the identified critical delay. A limitation to this method is its more limited capacity to recognise and allow for switches in the critical path during the course of the works.
6. The collapsed As-built Analysis is defined as the following:
The collapsed as-built (or but-for) analysis method involves the extraction of delay events from the as-built programme to provide a hypothesis of what might have happened had the delay events not occurred. This method does not require a baseline programme. This method requires a detailed logic-linked as-built programme. It is rare that such a programme would exist on the project and therefore the analyst is usually required to introduce logic to a verified as-built programme. This can be a time consuming and complex endeavour.
Once completed, the sub-networks for the delay events within the as-built programme are identified and they are ‘collapsed’ or extracted in order to determine the net impact of the delay events. This method is sometimes done in windows, using interim or contemporaneous programmes which contain detailed and comprehensive as-built data. A limitation to this method is that it measures only incremental delay to the critical path, because the completion date will not collapse further than the closest near critical path.
Prospective vs Retrospective Delay Methodologies
There are several different methods by which delays to a project can be assessed. These are generally categorised as “prospective” or “retrospective”:
Prospective methods attempt to analyse what the effect of a cause will be: whereas
Retrospective methodologies attempt to analyse what the cause of an effect was.
Prospective methodologies, therefore, look at what might occur (or might have occurred) whereas retrospective methodologies look at what has happened. Also, delay methodologies can be dynamic (i.e., programme-based) or static (i.e., based on the whole of the available evidence and less reliant on programme modelling).
In any project, the most appropriate method is usually determined by reference to:
- The contract requirements or any agreement between the parties; and
- The available evidence.
- The time of the delay claim.
Delay Claims are generally complex and detailed so from the outset of the analysis it is important to use the correct analysis methodology for the project at hand.
