Delay Analysis Techniques in Projects

Throughout the life cycle of a project, from the project baseline is created until we obtain a schedule that shows how activities have been executed (as-built schedule), a large number of unknown events occurred. These events might cause delays in the achievement of the different work packages, as well as for contractual project milestones. These delays may be the responsibility of the client, the contractor or third parties. In this post, we will show you the 6 delay analysis techniques more used in project management. These will be used as a tool to improve the relationship with your clients, to prepare time and/or cost claims, and to well-record all the events that occurred during the life cycle of a project.

6 Delay Analysis techniques in projects

1. “Impacted As-planned” Delay Analysis technique

This method is based on adding a Delay Event within the Project Baseline schedule, logically linked. Once it has been correctly linked to the corresponding Baseline activities, the calculation of the schedule will be carried out again thanks to the planning tool being used. In our case, this tool is Primavera P6 by Oracle. In this way, the prospective or future-time impact that the Delay Event has on the contractual completion milestone of the project will be determined. This contractual milestone is often referred to as “Contract Completion Date”.

It is important to have a solid Baseline of the project, where it has been confirmed that the sequence and duration of the work to be done are reasonable, realistic and achievable. In the same way, it is necessary to ensure that all activities have been linked correctly.

Normally, this is the simplest and least expensive of all the analyses described in this article about the techniques for project delay analysis. However, it has some limitations such as not considering the actual progress of the project or the changes to what was originally planned. In certain contracts, and depending on the terms that have been agreed with our client, this Delay Analysis technique would be sufficient to assess the extension of time we are entitled to request.

2. “Time Impact” Delay Analysis technique

In the same way as in the Delayed Analysis method called “Impacted As-planned Analysis”, we must introduce and link the Delay Events within the Project Baseline and calculate this updated program with the planning tool which we are working with. As in the previous case, the future impact of the Delay Event on the project completion date will be determined.

The schedule used as the Baseline for each analysis can be a contemporary schedule or the updated Baseline that reflects changes in logic, the actual progress of the work, or new work packages or activities. In other words, the Baseline to be analyzed should reflect the actual progress of the work and a realistic, achievable and reasonable sequence of the remaining work. Any mitigation and/or acceleration plan will be incorporated and taken into account in the updated Baseline.

The number of Delay Events that are modeled has a considerable impact on the complexity and cost in the use of this method.

3. “Time Slice” Delay Analysis technique

This is the first of the two Delay Analysis methods by windows that exist. This method requires that the person who analyzes the delays verify or develop a series of updated schedules to be considered as Baselines, as snapshots during the course of work. Through this process, the progress of the work is split into time intervals, typically monthly intervals, that reflect the actual critical path of each period. This allows the person to analyze the delays to determine the extension of time of each critical delay within each “window.”

The analyst investigates the project reports to determine what events could have caused the critical delay identified in each time interval. For the schedule referring to each “window”, the analyst needs to verify that the history of events occurred reflects the actual work performed and that the sequence and duration of the remaining work are reasonable, realistic and achievable, apart of showing a logical sequence. This method depends largely on the planning software.

4. “As-planned versus As-built Windows” technique

This is the second Delay Analysis technique based on “windows”. This method depends less on the planning software we use and is usually applied when there is some concern about the validity of the Project Baseline. The duration of the work is divided into “windows”, which are framed by revised schedules, updated schedules, milestones and important events that have happened. The analyst determines the real critical path for each “window” through a common-sense analysis and a practical analysis of the available facts.

Since this task does not depend so much on the planning tool that is used, it is important that the analyst sets out the reasons why the criticality has been determined.

The incidence and extent of the critical delay in each “window” are determined by comparing key dates along the contemporary or actual critical path with the corresponding planned dates in the baseline schedule. Subsequently, the analyst investigates the project records to determine what delay events could have caused the identified critical delay. The critical delay incurred and the mitigation or acceleration achieved in each window are accumulated to identify the critical delay during the duration of the work.

5. “Retrospective Longest Path” technique

The retrospective analysis method of the longest path involves the determination of a retrospective mode of the critical path as per as-built. This should not be confused with the contemporary or actual critical path identified in the previous window-based methods. In this method, the analyst must first verify or develop a detailed as-built schedule, just as the work has been executed. Once completed, the analyst traces the longest path backward from the actual completion date to determine the critical path of the executed project.

The incidence and scope of the critical delay is determined by comparing the key dates along the critical path of the executed works (as-built) with the corresponding planned dates in the Baseline program. Subsequently, the analyst investigates the project records to determine which events could have caused the identified critical delay.

A limitation of this method is its more limited ability to recognize and allow switches in the critical path during the course of work.

6. “Collapsed As-built” Delay Analysis technique

The collapsed as-built delay analysis technique involves the extraction of delay events from the “as-built” schedule. This provides a hypothesis of what could have happened if the delay events had not occurred. This method does not require a baseline any. However, a detailed as-built program with a well-defined logic in the execution of activities is required. It is rare that this schedule of activities exists in the project. It is generally required that the analyst introduce the logic to a verified as-built schedule. This can take a long time and is a rather complex effort. Once completed, the Delay Events are identified within the as-built schedule and “collapsed” or extracted to determine their net impact.

This method is sometimes done in “windows”, using the appropriate software tools that contain detailed and complete data of the work actually done. A limitation of this method is that it only measures the incremental delay to the critical path. The completion date will not collapse more than the closest critical path.

IN PROJECT 2080 WE WOULD LIKE YOU TO REMEMBER

There are different methods of Project Delay Analysis. The use of one or the other will depend on the particular circumstances and on the terms established in the contract with our client. In order to minimize future disputes, it is good that the most appropriate technique to be used for the Delay Analysis in projects is agreed before it is launched. This article has shown the 6 most common Delay Analysis techniques to find out the project delays. But there are other methods such as the earned value analysis, the balance line analysis or the analysis of the resource curve. What is the method you use in your projects?