LEOPARD PROJECT CONTROLS

Delay Identification in Construction

Construction projects are prone to unforeseen delays due to many factors, such as inclement weather, design changes, new authority regulations, force majeure, etc. The baseline schedule is regularly updated to monitor and track the project’s progress.  The forecasted projected finish date and the critical path of the updated schedule are compared with the baseline to identify delays if the progress is behind schedule.

Delay Analysis in Construction

Delay analysis is the process of evaluating how the delay events impact the project completion date. The methods commonly used for delay analysis are as follows.

1. Impact As Planned Analysis

Impact as planned analysis is a cause-and-effect approach to delay analysis. In this method, the critical path and delay impact are analyzed prospectively. The delay event is included to the baseline schedule as a fragnet, and the project is rescheduled on the project start date to analyze the effect of the delay. The aforesaid schedule with a delay event is called an impacted schedule.  The impact of the delay event is established by comparing the forecasted project finish dates of the impacted schedule with the baseline schedule, as shown in the figure below.

Figure 1: Impact As Planned Analysis
2. Time Impact Analysis Method

Time impact analysis is a cause-and-effect type of delay analysis. In this method, the critical path is determined based on the updated schedule and the impacted schedule. The delay impact is determined prospectively. The baseline schedule is updated before the delay event happens, and the forecast project finish date of the updated schedule is observed.  The impacted schedule is developed by inserting the delay event in the updated schedule as fragnet. Then the program is scheduled again on the same data date of the updated schedule to study the impact of the delay event on the project finish date. The difference between the project finish date of the impacted schedule and the updated schedule is determined as the impact of the selected delay event.

Figure 2: Time Impact Analysis
3. Time Slice Windows Analysis Method

Time Slice Windows Analysis” is a retrospective, effect-and-cause approach to delay analysis. The critical path is analyzed contemporaneously, while the delay impact is evaluated by observing the updated schedule. In this method, updated schedules at regular intervals are used to evaluate the impact of delay events. The critical path and delay impacts are analyzed separately for each time slice or window. In this method, the contractor’s delay and employer’s delay in each window are analyzed to determine compensable delays.

Figure 3: The evaluated delays for each window in Time Slice Windows Analysis
4. As-Planned versus As-Built Windows Analysis

As-planned versus As-Built Windows Analysis is the other method of delay analysis using Windows to analyze the impact of the delay event.  It is an effect-cause type of delay analysis. The critical path is identified based on the facts and records. In this method, the delay impact is assessed retrospectively.  As a different method from a time slice windows analysis, it is less dependent on the programming software. This method is used when there are doubts about the accuracy or reliability of the baseline schedule or when there are too few regularly updated schedules available. The as-built data is evaluated with respect to the baseline schedule to assess how the delay event affected the project finish date.

In this method, the duration of the project is divided into time slices or windows. Those windows are defined by revised programs, contemporaneously updated schedules, milestones, or significant events. The analyst decides the actual critical path in each window by a reasonable and practical analysis of the existing facts.  As this method does not significantly rely on programming software logic and interpretation of facts are considered to determine the criticality. The circumstance and magnitude of critical delays in each window are evaluated by comparing key dates along the actual or contemporaneous critical path against the planned dates in the baseline program. Subsequently, the analyst observes the project records to find the delay events that may have caused the critical delay. The critical delays encountered, along with the mitigation or acceleration achieved in each window, are observed to identify the critical delay of the project. This method shall also be used when the approved baseline schedule for the project is not available.

5. Retrospective Longest Path Analysis

Retrospective longest path Analysis is an effect-cause type of delay analysis. In this approach, the critical path and delay impact are identified retrospectively. The as-built longest path of the updated schedule is tracked backward from the actual project finish date to identify where the delays occurred. In this approach, the analyst creates a detailed as-built schedule. After that, the analyst finds the longest continuous path backward from the actual project finish date to identify the as-built critical path.

The circumstance and magnitude of the critical delay are established by comparing key dates along the as-built critical path with the planned dates in the baseline schedule. Afterward, the analyst studies project records to identify the events that may have caused the critical delay. A limitation of this method is its restricted facility to find and allow for switches in the critical path.  This method of delay analysis is used for complex projects.

6. Collapsed As-Built Analysis

Collapsed As-Built Analysis is an effect-cause type of delay analysis. In this method, the critical path and delay impact are found by retrospective analysis without the need for a baseline schedule. This method of delay analysis is suitable where the baseline and updated schedules are not available or incorrect. Delays are extracted from the as-built schedule to estimate what might have occurred if those delay events hadn’t happened. A detailed, logic-linked as-built schedule is required for this process, though such a schedule rarely exists, meaning the analyst often needs to add logic to a verified as-built schedule—a complex and time-consuming task. Once completed, sub-networks for delay events are detected and ‘collapsed’ or extracted to establish their net impact. This method can be applied in Windows using interim or contemporaneous schedules that contain detailed as-built data.

Conclusion:

Identifying delays early in the project is crucial for implementing mitigation measures to minimize their impact.  A suitable delay analysis is required for the Contractors to submit Extension of Time claims when the project completion is delayed or likely to be delayed. The suitable method of delay analysis shall be selected depending on many factors such as contractual terms, availability of data, size, and complexity of the project, etc.

Share This Blog, Choose Your Platform!

Go to Top