Introduction

This article explores a hybrid form of delay analysis, namely the time slice window analysis (‘TSA’), to arrive at an assessment of excusable delay (‘ED’) and excusable compensable delay[1] (‘ECD’). The TSA combines two separate method implementation protocols (‘MIP’) that are described in AACE 29R-03 in a single delay analysis.

Delay analysis methods are generally classified into two types: prospective or retrospective. The TSA takes advantage of both, combining a forward-looking approach (prospective) and backward-looking approach (retrospective). Using the two methods together allows the analyst to model the likely impact of any event within a chosen period or window and thereafter, measure the actual impact based on the progress recorded during that period or window.

It is believed that the TSA has an advantage over other retrospective methods of delay analysis, such as, as-planned vs as-built in windows, as it provides a contemporaneous view more accurately modeling the impact of an event.

What methods are employed under the TSA?

The purpose of any time extension claim is to relieve the contractor from paying liquidated damages for critical delays that have occurred, for which it is excused responsibility under the contract.

AACE International Recommended Practice ‘29R-03’ provides useful guidance on delay analysis. However, as stated in the introduction section within AACEI 29R-03, it is not prescriptive and must be considered in conjunction with the provisions of the contract:

“This Recommended Practice is not intended to establish a standard of practice, nor is it intended to be a prescriptive document applied without exception. Therefore, a departure from the recommended protocols should not be automatically treated as an error or a deficiency as long as such a departure is based on a conscious and sound application of schedule analysis principles.”[2]

Primarily, TSA is a retrospective method that establishes critical delay based on actual progress and, thereafter, the assignment of responsibility for critical delays based on the provisions in the contract (an effect and cause approach). The retrospective delay analysis methods provided within the AACEI 29R-03 are separated into observational and modelled methods as shown in Figures 1 and 2.

The TSA combines MIP 3.3 (Observational / Dynamic / Contemporaneous As-Is) and MIP 3.7 (Modeled / Additive / Multiple Base) creating a hybrid method of delay analysis.

The two MIPs are relevant to TSA for the following reasons:

1. The analysis involves the addition of delay fragnets into the programmes to model the event, hence this is an additive modelled form of analysis (MIP 3.7);
2. The analysis includes reliance on programme progress updates as-is at different points in time, hence the analysis is based on contemporaneous data (MIP 3.3);
3. The progress updates represent a multi-base scenario as opposed to a single phase to imply modelling the event into the baseline (MIP 3.7); and
4. The analysis is based on dynamic logic wherein the effect of the event modelled to contemporaneous data is analysed (MIP 3.7, MIP 3.3).

MIP 3.7[5] is an additive modelled method wherein the likely impact of any delay event on the final completion date or any interim control milestone is established by inserting the delay events into the programme closest to the event trigger[6] date. Though termed retrospective, the MIP 3.7 is a forward-looking tool that provides the prospective impact of a delay event or event(s) at any point in the past. Whereas MIP 3.3[7] is an observational dynamic logic method carried out on a retrospective basis, where the actual progress of the works is measured against the effects of the events (if any). MIP 3.3 is a backward-looking tool, and the term dynamic logic is used to refer to the progress update programmes at intervals of time to establish the contemporaneous longest path based on the actual progress of the works.  

Method Implementation Protocol

The TSA focuses on sequential periods of time (windows) to analyse the effect of the delay events (employer, contractor, and neutral events) on the contemporaneous longest path within each window. Windows may either have equal time intervals based on progress update programmes or different intervals based on shifts in the critical drivers. The easiest approach to selecting the windows is where the window finish dates coincide with the programme data date, this avoids having to make adjustments with respect to the data date.

As stated above, in the TSA both prospective and retrospective elements are compared by combining MIP 3.7 and MIP 3.3 within a single window. Thus, in any window, two separate programmes are analysed, namely, the impacted programme (‘IP’) at the start of the window, which satisfies MIP 3.7 and the rescheduled programme (‘RP’) at the end of the window, which satisfies MIP 3.3.

The IP establishes the likely impact of the delay event at the start of the window to arrive at the impacted completion date using a prospective model of the impact of the event, where the analyst does not have sight of the future progress within the window. Whereas the RP records progress for the window and establishes the forecast completion of works at the end of the window, wherein, the analyst takes benefit of the actual recorded progress of the works. IP models the contractor’s intent or the estimated impact at the start of the window, (a theoretical model), while the RP assists assessing the actual impact (if any) of delay events allowing for possible mitigation, contractor contributory acts and concurrent delay events, that may negate any potential compensable period.[8] The analysis results for any window will always be determined based on the retrospective approach, which represents the contractor’s actual position at the end of any window.    

Defining and Understanding MIP 3.7

The MIP 3.7 provides an estimate of the impact of the delay events on the primary longest path at the start of any window period. In page 75 of 29R-03, AACEI provides literature on MIP 3.7 as below:

“MIP 3.7 is a modeled technique since it relies on a simulation of a scenario based on a CPM model. The simulation consists of the insertion or addition of activities representing delays or changes into a network analysis model representing a plan to determine the hypothetical impact of those inserted activities to the network. The additive simulation is performed on multiple network analysis models representing the plan, typically an update schedule, contemporaneous, modified contemporaneous, or recreated. Each base model creates a period of analysis that confines the quantification of delay impact.”[9]

The MIP 3.7 is a multiple base modelled method, wherein the term ‘multiple base’ refers to the use of multiple progress programme updates within the overall analysis period. Here, the delay event fragnets[10] related to the employer, any other third party, or neutral cause are inserted into the programme at the start of the window to establish the impacted programme.[11] Each delay event has a trigger date (this being the start date) and a finish date, the event duration is defined by these two dates. However, to arrive at the impact for any window, the delay event duration is sliced at the window cut-off date, the slicing of any ongoing delay event is an important deviation from the MIP 3.7.

Defining and Understanding MIP 3.3

The MIP 3.3 provides for the quantification of actual critical delays at the end of each window period. In page 51 of 29R-03, AACEI provides literature on MIP 3.3 as below:

“MIP 3.3 is a retrospective technique that uses the project schedule updates to quantify the loss (delays) or gain (mitigation) of time along a logic path that was or became critical and identify the driver activity at the end of each window period. Although this method is a retrospective technique, it relies on the forward-looking calculations made at the time the updates were prepared. That is, it primarily uses the information to the right of the updates’ data dates. Because the method uses schedule updates whose logic may have changed from the previous updates as well as from the baseline, it is considered a dynamic logic method.”[12]

Why should the forecast completion based on actual progress recorded within any window be considered? The contractor’s mitigation (if any) or contributory culpable delays on the primary longest path and the possible shift in the primary longest path are identified using this approach, and as such, it reflects the actual impact on the works. Furthermore, the observational analysis derives results based on the actual critical delay (and not based on the possible impact of any delay event) at the end of the window. An important deviation from the MIP 3.3 is the inclusion of the same delay event fragnets that are progressed to the end of the window. It also allows any concurrency to be assessed, wherein the progressed path at the end of any window is compared to the impacted path at the start of the window. In addition, the progress update at the end of the window represents the contractor’s intention to complete the balance works, and this therefore must be taken into consideration with respect to the planned logic at the start of each window being analysed.

Steps in Time Slice Window Method

The concept of TSA method is illustrated in Figure 3.

The delay events are modelled in the programme at the start of the window to establish the estimated effect of delay events (impacted programme), this being the prospective view (MIP 3.7). The status of the works at the end of the window is based on the actual progress achieved (rescheduled programme), this being the retrospective view (MIP 3.3).

The five steps under TSA for each window are described below.

• Step 1 (MIP 3.7): A copy of the baseline (or progress update after the first window) was taken and renamed as W*A, where the asterisk refers to the relevant ‘window number’ (i.e., W1A for the ‘first window’). This is the impacted programme (‘IP’).
  Programme Explanation: The baseline is the start-point for the TSA, the first impacted programme is based on this baseline. The impacted programme for the second window is based on the progress update programme at the end of the first window. Likewise, the same approach applies for the subsequent windows.

• Step 2 (MIP 3.7): The delay fragnets for each window are inserted into the IP and linked to relevant affected baseline activities, to model the estimated impact. To establish the effect within this window, the delay event duration is sliced[13] at the end of the window. The programme is thereafter rescheduled to calculate the effect of a delay event on the longest paths[14] and arrive at an ‘impacted completion date’. This is the prospective view at the start of any window.
  Programme Explanation: The intent of the IP is not to measure the impact of a single event but a host of delay events that are in play during the window period. However, it is possible to determine the impact of each delay event within any window using the ‘but-for’ approach, wherein events were individually inserted into the IP [15]. In the case of an impacted completion date, the first activity on the primary longest path is the critical driver for this window. 

• Step 3 (MIP 3.3): The progress update programme[16] at the end of the window is copied and re-named as W*B, where the asterisk refers to the ‘window number’. This is the rescheduled programme (RP). The delay fragnets are progressed to the end of the window, inserted into the progress update programme and thereafter, the programme is rescheduled[17] to arrive at the ‘forecast completion date’. The actual progress achieved against effects of delay events at the end of each window period is the retrospective view. The difference between the ‘forecast completion date’ between successive windows is the actual critical delay for the window. 
  Programme Explanation: A variation to this would be to use a copy of the impacted programme and import progress data from the progress update programme at the window cut-off date.  However, in any case, it is necessary to have a progressed delay fragnet in the RP for two reasons; firstly, to allow for any scope insertions into the baseline programme, and secondly, to allow for the continuation of the impact of the progressed delay fragnets on the affected baseline activities within the RP. Here, the contractor is obligated to perform the additional scope from this point, however, the contractor has an implied obligation to mitigate the impact of any employer-driven delays without incurring cost or expending additional resources.  

• Step 4 (Compare MIP 3.7 and MIP 3.3): After establishing the prospective and retrospective views within the window, the impacted and forecast completion dates with the corresponding primary longest paths are compared. The comparison enables to establish the actual critical delays (in comparison to RP from the previous window) and determine if the contractor mitigated the effect of an employer or neutral delay event or if there were additional delays beyond what was anticipated (in comparison to the impacted date in IP). The results are always based on the rescheduled programme.
  Programme Explanation: The objective to compare the longest path between the programmes is four fold, to determine (a) if there has been a loss (delay) or mitigation at the end of the window, (b) if an employer or contractor event is the critical driver, (c) if any other secondary delay event attributed to the contractor or employer is the critical driver – arrive at excusable delay periods, and (d) if there is concurrency, which forms the basis of excusable compensable delay periods.

• Step 5 (Establish Excusable and Compensable Periods): Accordingly, the primary longest paths for impacted and rescheduled programmes, critical delays, and critical drivers[18] are established for each window. Based on this, excusable and compensable periods are derived for each window (as explained further below). Compensable Periods of Delay (Project Level)

The aim of the TSA is to arrive at an assessment of the excusable delays and compensable periods of delay for each window. The compensable periods are assessed on the following set of principles:

• If the primary longest paths on the impacted and rescheduled programmes are similar, the contractor is eligible for excusable and compensable delays (subject to the provisions in the contract). It would indicate that the delay event is the primary cause of critical delays within the window.
• If the primary longest paths are different, it would mean that critical delays attributable to the contractor are concurrent with the employer’s delay on the primary longest path, the contractor will only be eligible for excusable periods and no compensable periods.
• If there is no impact caused by an excusable delay event within the window, the contractor will be culpable for any critical delay (if any).

In normal cases, the critical delay within a window should be less than or equal to the window duration. However, if the delay event involves additional scope introduced by the Employer, it is possible for the impact of this event to be greater than the window period and must be qualified likewise for the window being analysed.

Conclusion

In summary, the time slice windows (TSA) method considers the effect of delay events or additional scope instructed by an employer in sequential window periods to derive excusable delay and excusable compensable delay periods. The TSA combines prospective and retrospective elements in a progressive manner to provide a thorough review of delay events and critical delays to various contract milestones. Under TSA, two method implementation protocols listed under AACEI 29R-03 are combined in a single delay analysis to assess the contractor’s entitlement in conjunction with the provisions in the contract. The delay analysis is based on the actual critical delay to the primary longest path. In addition, the TSA allows the analysis of the concurrent and contributory effects of any contractor delay events as well as the impact of any mitigation implemented.

However, it is imperative for the analyst to clearly set out the rules under the TSA that will allow the establishment of excusable delays and excusable compensable delays. Here, the impacted programme at the start of any window is primarily used as a mirror to the progress update programme which provides actual status (progress and delays to works) at the end of each window; the results are always based on the actual status of the works.

---

References

[1] It relates to time related costs, i.e., indirect labour cost for the extended period the Contractor will have to spend at site and those which define prolongation costs. For compensation to be considered, the critical delays must be excusable.

[2] AACEI 29R-03 (Page 9 of 136).

[3] Figure 1 of AACEI 29R-03.

[4] Ibid.

[5] Modelled / Additive / Multiple Base (Page 75 of 134, AACE 29R-03).

[6] The start date of any delay event.

[7] Modelled / Additive / Multiple Base (Page 51 of 134, AACE 29R-03).

[8] AACE 29R-03 (Page 30 of 136).

[9] AACE 29R-03 (Page 75).

[10] A delay fragnet is defined as a subset of programme activities which model the delay event chronology.

[11] Delay Analysis | Knowing the unknown unknowns by Sean Hugo (Driver Trett).

[12] AACE 29R-03 (Page 52).

[13] The slicing applicable only to an on-going delay event is an important deviation within the MIP 3.7.

[14] On the existing primary longest path and other secondary longest paths.

[15] It is possible to have zero impact from the delay events.

[16] All necessary valid implementation protocols are to be satisfied while importing data from a progress update programme into the rescheduled programme.

[17] Prior to rescheduling, all the existing delay events within the programme are to be statused to data date.

[18] The critical driver is first activity on primary longest path within the impacted and rescheduled programmes.