INSIGHTS
Society of Construction Law’s Rider 1 to its Delay and Disruption Protocol
16/12/2015
Get in touch
INSIGHTS
Society of Construction Law’s Rider 1 to its Delay and Disruption Protocol
December 16, 2015
Get in touch
In July of this year, the Society of Construction Law (SCL) published Rider 1 (“the Rider”) of its 2002 Delay and Disruption Protocol (“the Protocol”). The Rider’s Preamble lists a series of amendments to the Protocol intended to serve as an update reflecting (a) legal and industry practice developments, (b) feedback, (c) technological developments, (d) increase in scale of larger projects, and (e) international use of the Protocol. The Rider is intended to serve as the first part of the amendments to the Protocol, the totality of which should feature in a consolidated and updated version of the Protocol later this year.[1]
The main changes
The main changes addressed by this Rider are described in the Preamble as follows:
- Time impact analysis has stopped being the expressed preferred recommended method of delay analysis wherever circumstances permit and has been substituted by a more pragmatic approach, i.e., the method is still the first choice for contemporary analysis, but not in retrospective delay analysis where the effects of the delay are known and the choice of method should depend on a number of factors.
- The list of delay analysis methods has increased from the original four (as-planned v as-built, impacted as-planned, collapsed as-built and time impact analysis) to six. Two new retrospective analysis methods have been added: time slice window analysis and longest path analysis. The as-planned v as-built analysis (which is also retrospective) has been amended to make it a windows approach.
Time impact delay analysis limited to contemporaneous assessment
As mentioned above, one of the main updates is the SCL’s abandonment in Section 3 of its general recommendation to use the time impact delay analysis method in assessing both prospective and retrospective delay. The Protocol explained that it was “the best technique for determining the amount of the Extension of Time that a Contractor should have been granted at the time an Employer Risk Event occurred”.[2]
However, because it is a prospective approach, time impact analysis produces theoretical entitlements that set out the likely, as opposed to the actual, effect of a delaying event.[3] Therefore, the result of a time impact analysis may be at odds with what actually happened during the project. Furthermore, in addition to time impact analysis being both lengthy and expensive, it is only useful in awarding extension of time (“EoT”) entitlements and not costs, so that, the interested party would need to invest in an additional investigation to evaluate costs.[4]
Furthermore, the new approach is good news to those in the field who have rightly realised the many drawbacks of prescribing a particular method. The main criticisms have been summarised as follows[5]:
- By endorsing time impact analysis, the SCL has given undue confidence to claimants in what may amount to hypothetical and therefore potentially inaccurate entitlements to EoT, thus promoting instead of discouraging disputes.
- The Protocol contradicts itself by both recommending contemporaneous assessments of EoTs and suggesting that a contemporaneous or prospective analysis is still possible even years after the event and its effects have been felt.
By retracting its express general endorsement of time impact analysis, the Rider dissuades intransigence during disputes. Also, Section 4 of the Rider prescribes that prospective analyses are not relevant or appropriate in EoT applications assessed after completion of the works or considerably after the delay event or its impact thus removing the contradiction.
This is not to say that the SCL does not recommend the use of time impact analysis at all. In fact, the method is still the preferred method for determining the prospective or likely impact of delay events in a contemporaneous analysis and is still the preferred method where “Employer Risk Events and Contractor Risk Events occur sequentially but have concurrent effects”.[6]
The common-sense approach
The new recommendation when assessing EoTs is that users should take a common-sense approach based on an appropriate method of delay analysis. Common sense should be applied when both the analysis is undertaken during the course of the project and after the delay event.
As with the Protocol, the drafters of the Rider have determined that, although prospective approaches to delay analysis may be misleading, “clarity was of greater value for all parties than a ‘wait and see approach’” [7] so that their recommendation that EoTs should be assessed and awarded contemporaneously or “as close in time as possible to the delay event that gives rise to the application”[8] stands. In fact, there is now an express discouragement of the ‘wait and see’ approach.[9] However, where an EoT is assessed at a time distant from the delay event, Section 4 of the Rider has reviewed its approach in some ways and expanded the menu of methods to be used.
Section 4 lists criteria to be used to determine the method of delay on a particular project. The list has remained the same as in the Protocol except for the deletion of the “programmer’s skill level and familiarity with the project” and the addition of “the forum in which the assessment is being made”.[10] These may prove to be quite sensible recommendations; under English law at least, a programmer will presumably be obliged to exercise reasonably competent skill and care and parties seeking to analyse delay are well advised to consider whether a robust albeit costly, time-consuming or complicated method is really that necessary at whatever the stage of the dispute. For example, at the claims stage or perhaps even before then, certainty of the analysis may be outweighed by the need to control costs and make a simple point so that a low cost but less precise method that produces a straightforward result may be a more sensible idea.
In addition, the Rider no longer recommends particular methods of analysis depending on whether liquidated damages are based on actual or likely delay.
The six options of retrospective delay analysis
One of the most useful additions is Section 4.4 of the Rider. It provides a handy general explanation of the characteristics that describe and differentiate the various delay analysis methods. First of all, it explains that some methods require the analyst to identify the cause of delay before establishing its impact on the project (i.e., “cause and effect”) whereas others take the opposite approach, that is, identifying the delay before attributing a cause to it (i.e., “effect and cause”). It adds that the critical path must be identified because that is where the analyst will find the delays that impact the completion of the works (or a milestones thereof). Critical paths may be “a sequence or chain of activities through the remaining works” or a “collection of related work activities to distinct sequences.”[11] Also, whereas programming software may be very useful, the Rider warns that a practical analysis of the relevant facts and historical data may be more reliable. In addition, the Section provides a description of prospective and retrospective delay analysis. The former aims to get at the likely impact of delay events, i.e., what could happen, whereas the latter seeks to arrive at the actual impact of the delay events, i.e., what actually happened in the project. To complete the explanation this Section lists three options to determine criticality, which depend on the point of view the analyst takes in the timeline of the project:
- Purely prospective critical path positions the analyst at the beginning of the project and does not consider any progress that happened during the works.
- Contemporaneous critical path takes into account work progress and changes in strategy during the course of the project.
- Retrospective critical path takes a view from the end of the project.
Finally, Sections 4.5 to 4.12 provide a robust explanation of the six methods of analysis:
- Impacted As-planned
- Time Impact
- Time Slice Window
- As-planned v As-built Window
- Longest Path
- Collapsed As-built
The Table in Section 4.5 is a particularly useful summary on the determinative characteristics of each method, mainly, whether it is a “cause and effect” or “effect and cause” analysis, how the critical path and delay impact are determined and what each method requires.
The two new methods in the group are the time slice windows and longest path analyses. In addition, the as-planned v as-built analysis has now been upgraded to a windows analysis to become one of the two windows analyses on the list.
As an afterthought, the Rider also mentions, though without describing, five other methods which may be adopted having considered the criteria in Section 4.3. These are:
- Summary level as-planned versus as-built analysis
- Time chainage analysis
- Line of balance analysis
- Resource curve analysis
- Earned value analysis
Conclusion
Taken together, a delay analyst will be well positioned to determine the most appropriate and sensible method to use for an analysis. The Rider and the future amendments to the rest of the Protocol promise to be very useful in the industry. Together with the additional amendments expected later this year, we hope the updated SCL Delay and Disruption Protocol becomes a welcomed addition to this specialised field of analysis for years to come.
[1] http://www.scl.org.uk/resources
[2] Protocol at 4.8.
[3] See David Falkenstern, ¨Delay and Disruption Protocol: Easy Rider¨ on Building Magazine Issue No 33 dated 21 August 2015 at page 38; and David Barry, “The SCL Delay and Disruption Protocol—10 years on” on Construction Law Journal Vol 29 No 5 [2013] at page 368
[4] David Barry, “The SCL Delay and Disruption Protocol—10 years on” on Construction Law Journal Vol 29 No 5 [2013] at page 368.
[5] David Barry, “The SCL Delay and Disruption Protocol—10 years on” on Construction Law Journal Vol 29 No 5 [2013] at page 368.
[6] Rider 1 at 3.2.12.
[7] Rider 1 Preamble at paragraph 11.
[8] Protocol at 1.2.4.
[9] Rider 1 Core Principles at paragraph 3.
[10] Rider 1 at 4.3.
[11] Rider 1 at 4.4.2.