Delay Analysis Methods – Common Methods

Introduction

In my July 2021 article[1], I provided a summary of the common delay analysis methods in the industry and in my August 2021 article[2], I explained the factors to consider when selecting and implementing the delay analysis methods.

In this article, I share my experience on the common delay analysis methods in the industry, taking guidance from AACE International (AACE International) Recommended Practice No. 29R-03 (“AACE RP29R-03”), AACE International Recommended Practice No. 52R-06 (“AACE RP52R-06”) and the Society of Construction Law (SCL) Delay and Disruption Protocol[3] (SCL 2nd Protocol).

There are a number of recognised delay analysis methods in the industry. Both AACEI[4] and SCL[5], provide very good guidance on the key delay analysis methods. However, there is still a significant variance when it comes, not only to the way the methods are implemented, but also the “naming” of the methods. For example, I often hear industry professionals affirming that the “Windows Analysis” method is the most appropriate method. However, in practice, “Windows Analysis” is a widely used technique which can be applied as part of the implementation of many delay analysis methods. In my own experience, I have seen people contending how windows analysis should be implemented without realising they were debating two different methods.

In this article and the next one, I share my understanding of the six main delay analysis methods identified by SCL and highlight the equivalent methods in the AACE International’s recommended practices.

This Article includes:

  • The Impacted As Planned Method,
  • The Time Impact Analysis Method, and
  • The Time Slice Windows Analysis.

Impacted As Planned Analysis[6]

Brief Description

This method is considered as a “Cause & Effect” analysis in that it simulates the impact of the delay event(s) (the “Cause”) on the planned sequence of activities (the “Baseline” program) and analyses the modelled impact on the Baseline program (the “Effect”).

There are several method names which refer to the same “Impacted As Planned Analysis”, including:

  • As Planned Impacted
  • Impacted Baseline
  • After-the fact
  • modified CPM schedule
  • As Planned
  • What-if
  • As planned plus delay analysis
  • Affected baseline schedule

Using the AACE International’s categorisation, the Impacted As Planned method falls under the following Modelled, Additive groups:

  • 3.6 Single Base, Global Insertion
  • 3.6 Single Base, Stepped Insertion
  • 3.7 Multi Base, Fixed periods
  • 3.6 Multi Base, Variable Windows or Grouped

Product

The result is an impacted Baseline program, which shows the original planned sequence but with the impact of the delay event(s) (the “Impacted” program”). The Baseline program in this context can be any program which includes the indented sequence of works.

The critical path is determined prospectively (looking forward) and the critical delay is usually calculated prospectively as the difference between the completion dates of the Baseline and the Impacted program.

Requirements:

To perform the Impacted As Planned analysis, you require:

  • A Baseline program. This program should be capable of reflecting your planned sequence of works. Therefore, a logic linked program produced using a planning software tool (e.g. P6 or MS project) is preferred. 
  • A selection of delay events to be modelled. The modelling of the events can be created by inserting a fragnet of activities reflecting the delay impact.

Implementation Process

  • Identify the Baseline program
  • Create delay event fragnet (s)
  • Add the fragnet (s) to the Baseline program, to model the delay impact(s). This can be done:
    • Globally by inserting all delay event at the same time, or
    • In stepped manner by inserting each delay event or group of events, separately.
  • The analysis can also be performed using one baseline program (single base) or multiple baseline programs (Multi Baselines).
  • The analysis can be performed in fixed and variable windows. This selection of the window periods would depend on the number of baseline programs used and/ or the number delay events analysed.

Limitations

The method has limited use because it does not account for any change in planned sequence or the actual progress of works.

The method also relies on the quality of the Baseline program and the modelling of the delay event. For example, if the Baseline does not truly reflect the intended sequence of work, the Impacted As Planned method will likely yield unrealistic results.

In some instance, the analyst may alter the analysis to suit the project requirements and/ or to overcome the method limitations. For example:

  • The analyst may fix the issues or reconstruct the baseline program.
  • The analysis may revise the baseline program to reflect the changes in the sequence of works or even take the actual progress into account. I note that the “Time Impact Analysis” method, which I’ll discuss later in this article, is a variation of the Impacted As Planned method i.e. it uses a program updated at a point just before the occurrence of the delay event as the baseline program, instead of the initial baseline program.

Suitability

Because of the method limitations, it is generally suitable in cases:

  • Where there is limited progress or change in the sequence of the Baseline works, and
  • When the analysis requires simulating a scenario if things were performed differently. For example, when there is a requirement to demonstrate the likely delay impact had the contractor not implemented mitigation or acceleration measures.

Case Study

Let’s say a project has 7 activities (A, B, C, D, E, F and G) (the “Project”)[7]. The Project’s baseline (the “Baseline Example”) starts on day 1 and ends on day 8. it has three paths, one of which is critical (in red), as follows:

Baseline

The project was actually completed on day 12. The contractor claimed that the cause of the delay was two delay events as follows:

  • Delay Event 1 (DE1): Lack of access to activity A, 3 days (days 1 to 3 inclusive), and
  • Delay Event 2 (DE2): Lack of client supplied material 2 days (days 6 and 7).

In demonstrating its extension of time claim, the contractor submitted an Impacted As Planned analysis summarised as follows:

Impacted As Planned

The above analysis demonstrates that the delay events cause 4 days of critical delay as follows:

  • Delay Event 1 (DE1): Lack of access to activity A caused 2 days of critical delay (days 2 to 3 inclusive). Day 1 was also impacted by a DE1 delay, but it did not cause critical delay because the path had 1 day of float, and
  • Delay Event 2 (DE2): Lack of client supplied material 2 days cause 2 days of critical delay (days 6 and 7).

However, the issue in the above analysis is that it does not consider the actual progress and sequence of works, which may affect the results. In my explanation of the next methods, I’ll use the same example, to demonstrate the difference.

Time Impact Analysis (TIA)[8]

Brief Description

This method is considered as a “Cause & Effect” analysis in that it simulates the impact of the delay event(s) (the “Cause”) on the planned sequence of the remainder activities of an updated program of works at a point just before the occurrence of the delay event(s) (the “Updated” program). The method analyses the modelled impact on the Updated program (the “Effect”).

There are other method names which may refer to the same “Time Impact Analysis”, including:

  • Windows Analysis
  • What-if
  • Contemporaneous analysis method
  • Contemporaneous period analysis
  • Snapshot analysis
  • Time impact technique
  • Time slice method
  • Delay sections
  • Traditional windows analysis
  • Modified window analysis
  • CPM review method
  • Effect Based Delay Analysis Method (EDAM)
  • Isolated Delay Type Method

Using the AACE International’s categorisation, this method falls under the following Modelled, Additive groups:

  • 3.6 Single Base, Stepped Insertion
  • 3.7 Multi Base, Fixed periods
  • 3.6 Multi Base, Variable Windows or Grouped

Product

The result is an impacted Updated program (or a series of Updated programs), which show(s) the planned sequence of the remainder works in the Updated program(s) but with the impact of the delay event(s) (the “Impacted” programs)). The analyst may further update the Impacted program to assess the effect of the actual progress of works after modelling the delay (e.g. to investigate the if the contractor caused further delay or managed to achieve mitigation and/ or acceleration of the delay).

The critical path is determined prospectively (looking forward) but contemporaneously because it is determined at the time when the event actually occurred, taking account of the actual progress of works at that point of time.

The critical delay is calculated prospectively as the difference between the completion dates of the Updated and the Impacted programs.

Requirements:

To perform the Time Impact Analysis, you require:

  • A Baseline program. This program should be capable of reflecting your planned sequence of works. Therefore, a logic linked program produced using a planning software tool (e.g. P6 or MS Project) is preferred. 
  • Updated programs. These programs should be capable of reflecting the actual status of works around the time when the event(s) actually occurred, and the planned sequence of the remainder works at that point of time. Therefore, logic linked programs produced using a planning software tool (e.g. P6 or MS Project) is preferred.  If the updated programs are not available, there should be sufficient progress information to retrospectively create the Updated program(s).
  • A selection of delay events to be modelled. The modelling of the events can be created by inserting a fragnet of activities reflecting the delay impact.

Implementation Process

  • Identify the baseline and/ or the Updated program(s)
  • Create delay event fragnet (s)
  • Add the fragnet (s) to the Updated program(s), to model the delay impact(s),
  • The modelling is performed in windows. The window periods could be fixed or variable depending on the available updated programmes and the number of delay events.
  • The assessment of the delay impact can be done for each delay event individually or for a group of delay events with the same window period.

Limitations

The method relies on the quality of the Baseline and the Updated programs, and the modelling of the delay event(s). For example, if the Updated programs do not truly reflect the intended sequence of the remainder works, the method will likely yield unrealistic results.

The method also has limited use because it does not account for any change in planned sequence or the actual progress of the remainder works, where the analysis is performed retrospectively, e.g. where the analysis is performed after the actual delay event impact had already occurred.

In some instance, the analyst may alter the analysis to suit the project requirements and/ or to overcome the method limitations. For example:

  • The analyst may fix the issues or reconstruct the programs.
  • The analysis may revise the programs to reflect the changes in the sequence of works or even take the actual progress of the delay events and the remainder works into account. This is often described as “Retrospective Time Impact Analysis”.

Suitability

The Time Impact Analysis is generally suitable in cases:

  • Where the purpose of the analysis is to contemporaneously assess the impact of the delay, and
  • When the analysis requires simulating a scenario if things were performed differently. For example, when there is a requirement to demonstrate the likely delay impact had the contractor not implemented mitigation or acceleration measures.

Case Study

Following the same case study discussed under the “Impacted As Planned” section, let’s say the client rejected the contractor’s Impacted As Planned submission on the basis that the submission does not take the actual progress into account.

The contractor may then consider the improved version of the Impacted As Planned which takes the actual progress into account; i.e., the Time Impact Analysis. Let’s assume the contractor divided the 12-day actual period into 4 windows (i.e. 3 days per window)

In the first window, only event DE1 is included. DE1 impact changed the critical path and caused 2 days of critical delay (see figure below)[9]. It is observed that there is a progress delay[10] to activity F in this window which do not fall on the critical path.

TIA – Window 1

In the second window, the critical path remained the same and only 1 day of further delay is added.  Delay event DE2 caused 1 critical days of delay on day 6.


TIA – Window 2

In the third window, the critical path remained the same, but the path is impacted by a further delay of 1 day due to delay event DE2 (See figure below). It is observed that there are progress delays to activities C and G. Activity C delay did not cause any critical delay. However, Activity F delays caused critical delay and converted the path into critical path.

TIA – Window 3

In this scenario, it can be argued that the contractor’s progress delay between days 7 and 9 (both days inclusive) is the cause of day of concurrent critical delay on day 7. I note here that the choice of the window period would likely change the result of the analysis. For example, in this scenario, if daily windows are analysed, then the progress delay on day 7 would not have caused critical delay and therefore would not have been considered as concurrent[11]. The window period is one of the “level of detail” decision which require professional judgment and justification, conspiring the factors I explained in my August 2021 article[12].

The key message here is that regardless of the method you use or the window period you select, there is an element of professional judgment and subjective opinion involved where there are multiple delay events to analyse.  

In the fourth and last window, there are no further delay event impacts. However, there is a further 2 days to delay to Activity C, which results in a third critical path. However, this did not cause further critical delay to the project.

TIA – Window 4

In Summary, The Time Impact Analysis demonstrated that:

  • Window 1: Delay event DE1 caused two days of critical delay on days 2 and 3,
  • Window 2: Delay event DE2 caused 1 day of critical delay on day 6,
  • Window 3: Delay event DE2 caused 1 day of critical delay on day 7. However, the contractor’s progress delays caused concurrent 1 day of critical delay on the same day 7.
  • Window 4: No further critical delay was observed.

The Time Impact Analysis produced similar results to the Impacted As Planned. However, the analysis provided a better breakdown of the delays, considered the progress delays in addition to those claimed by the contractor, and identified a concurrent delay period.

Generally, when considering concurrent delay periods, the contractor would be entitled to an extension of time (e.g. full 4 days in this scenario) without costs (e.g. 3 days of actual costs in this scenario), unless the contractor can prove direct costs associated with the claimed delay event(s).  However, extension of time would be dependent on express contract clauses, including those relating to concurrency, and compensation would be dependent on whether the contract provides remedy for the type of delay.

Notwithstanding the above, it may still be argued that the Time Impact Analysis produces prospective results and is therefore inappropriate in cases where the project is already completed (similar to the case study in question).

Time Slice Windows Analysis (TSWA)[13]

Brief Description

This method is considered as a “Effect & Cause” analysis in that it does not simulate the impact of the delay event(s) (i.e. it is an observational method). The method starts by reviewing the planned sequence of the remainder activities of an updated program of works (the “Updated” programs) and identifies the delay periods at that point in time (the “Effect”) and then attempts to link the delay to the claimed delay event(s) (the “Cause”).

This method is the likely intended methodology when people refer to “Window Analysis”. There are other method names which refer to the same method, including:

  • Time Impact Analysis
  • Contemporaneous analysis method
  • Contemporaneous period analysis
  • Snapshot analysis
  • Time impact technique
  • Delay sections
  • Traditional windows analysis
  • Modified window analysis

Using the AACE International’s categorisation, this method falls under the following Observational, dynamic logic groups:

  • 3.3 Contemporaneous updates (As-Is)
  • 3.4 Contemporaneous updates (Split)
  • 3.5 Modified/ Reconstructed Updates

Product

The result is usually a series of updated programs, which include actual progress information and the planned sequence of the remainder works (the “Updated” programs).

The critical path is determined prospectively (looking forward) but contemporaneously because it is determined using contemporaneous programs, taking account of the actual progress of works at the relevant point in time.

The critical delay is calculated retrospectively (for the actual periods) and prospectively (for the reminder works) as the difference between the completion dates of the Updated programs. For example, if the Updated program for January forecasts a delay period of 5 days in February, that is a prospective delay period. If the February program update included those 5 days as actual delay period, then the delay becomes a retrospective delay period. I note here that these is a difference between the delay period (i.e. when the delay occurs) and the delay impact (e.g. when the impact on the completion date is observed).

Requirements:

To perform the Time Slice Windows Analysis, you require:

  • A Baseline program. This program should be capable of reflecting your planned sequence of works. Therefore, a logic linked program produced using a planning software tool (e.g. P6 or MS Project) is preferred. 
  • Updated programs. These programs should be capable of reflecting the actual status of works around the time when the event(s) occurred, and the planned sequence of the remainder works at that point of time. Therefore, logic linked programs produced using a planning software tool (e.g. P6 or MS Project) is preferred.  If the Updated programs are not available, there should be sufficient progress information to retrospectively create the Updated program(s).

Implementation Process

  • Identify the Baseline and/ or the Updated programs
  • Verify the reliability of the programs in terms of reflecting an accurate status of the works at various snapshots (being the time slices/ windows) throughout the course of the works.
  • Fix issues or develop revised programs, if needed.
  • Determine the contemporaneous critical path and assess the critical delay periods, in windows.

Limitations

The method relies on the quality of the Baseline and the Updated programs. For example, if the Updated programs do not truly reflect the intended sequence of the remainder works, the method will likely yield unrealistic results.

The method also has limited use because it does not account for any change in planned sequence or the actual progress of the remainder works, where the analysis is performed retrospectively e.g. where the analysis is performed after the actual delay event impact had already occurred.

The method heavily relies on the quality of the Updated program. If the analysis is unable to fix or recreate reliable series of update programs, then the method would not be credible.

A variation to the method maybe in producing an analysis that is less reliant on software generated programs. In such case, the analysis may become an As Planned versus As Built Windows Analysis, which I’ll discuss in my next article.

Suitability

The method is generally suitable in cases:

  • Where the purpose of the analysis is to contemporaneously assess the impact of the delay, without including a hypothetical modelling of the delay,
  • When the analysis requires assessing the contemporaneous view of the critical path and delay period.

Case Study

Following the same case study discussed under the “Impacted As Planned” and the “Time Impact Analysis” sections, let’s say the client rejected the contractor’s submissions on the basis that the submissions included modelling of the delay that is not realistic. An alternative in this scenario can be the Time Slice Windows analysis, which is an observational method.

The Time Slice Windows analysis is performed in a manner similar to the Time Impact Analysis but without modelling any of the delay events, i.e. the analyst reviews the project updated programs and observes the delays rather than introducing fragnets of the delay events.

In the first window, it is observed that Activity A did not start as planned on day 1 and is forecasted to start on day 4. This is 3 days of delay, which caused 2 days of critical delay to the completion date. The analyst then reviews the claimed delay events and assesses if any of them relates to this identified delay period. The delay in this case is caused by Delay Event DE1. 

TSWA – Window 1

In the second window, the analyst observes 1 day to the start of Activity D, which causes 1 further day of critical delay. Again, after investigating the records, the analyst would find that this delay is caused by Delay Event DE2.

TSWA – Window 2

In the third window, the analyst would observe that there is 1 day of further delay to the commencement of Activity D (because of delay event DE2). However, the analyst would also observe delays to activity G (1 day of critical delay), which are not linked to any of the claimed delay events.

TSWA – Window 3

In the fourth and final window, the analyst would observe two more delays to Activity C, which did not cause any critical delay to the completion date. 

TSWA – Window 4

In Summary, The Time Slice Windows Analysis demonstrated that:

  • Window 1: Delay event DE1 caused two days of critical delay on days 2 and 3,
  • Window 2: Delay event DE2 caused 1 day of critical delay on day 6,
  • Window 3: Delay event DE2 caused 1 day of critical delay on day 7, However, the contractor’s progress delays caused concurrent 1 day of critical delay on the same day 7.
  • Window 4: No further critical delay was observed.

In this case study, the Time Slice Windows Analysis produced similar results to the Impacted As Planned and the same results as the Time Impact Analysis.

Notwithstanding the above, it may still be argued that the Time Slice Windows analysis has a prospective element and is therefore inappropriate in case where the project is already completed (similar to the case study in question).

Summary

In this article, I summarised three of the key delay analysis methods in the industry and referred to the relevant sections and respective guidance in the Society of Construction Law Delay and Disruption Protocol’s six key methods and the AACE International’s nine retrospective forensic scheduling groups. In practice, the selection of the delay analysis method requires professional judgment of the analyst considering the factors which I discussed in my previous articles.

In my next Article, I’ll discuss the other three key delay analysis methods in the industry, namely:

  • The As Planned versus As Built Windows Analysis,
  • The Retrospective Longest Path Analysis, and
  • The Collapsed As Built Analysis.

Disclaimer: This article is intended to provide an update on the current industry practice in terms of delay analysis.  However, it does not in any way constitute any type of legal or professional advice.

[1] Delay Article 1: https://www.astonconsult.net/delay-analysis-what-is-the-most-appropriate-method/

[2] Delay Article 2: https://www.astonconsult.net/delay-analysis-methods-factors-to-consider/

[3] 2nd edition, February 2017

[4] AACE RP29R-03 and AACE RP52R-06

[5] SCL 2nd Protocol

[6] SCL 2nd Protocol, 11.5 (a)

[7] This example scenario will be used for the 6 methods discussed in this article

[8] SCL 2nd Protocol, 11.5 (b)

[9] For the purpose of this case study, I assumed the contractor’s progress did not cause further delay and did not recover any of the delays.

[10] A ‘progress delay’ is an observed delay to the contractor’s progress in the Updated program.  On further interrogation this delay could be found to be an excusable delay.  For the purpose of this exercise, it is seen as a contractor delay.  

[11] 3 Day Windows; Window 3 identifies 1 day of concurrent delay in Activity D.  1 Day Windows; Window Day 7 identifies 1 non-critical delay of delay.

[12] Delay Article 2: https://www.astonconsult.net/delay-analysis-methods-factors-to-consider/

[13] SCL 2nd Protocol, 11.5 (a)

2021-10-20T21:53:36+00:00 October 19th, 2021|Insights, News|0 Comments