There are several delay analysis techniques for expert reports. The SCL recognises 6 techniques while the AACE recognises 8. Many of them have different names but are very similar, or have similar names despite being completely different. However, in practice only a few of these techniques are usually used.
Collapse as built (CAB) + Impacted as planned (IAP)
Impacted as Planned is based on simulating delay events on the baseline programme by adding activities that represent the impacts that occurred. Collapse as Built is based on creating a properly linked model using as-built dates and all delay events that took place. Both techniques have significant weaknesses that make them inadvisable for an expert report on their own; however, combining both can allow a robust and precise analysis to be prepared.
The CAB+IAP technique is rarely used because of its complexity and implementation time. It is only suitable for small projects, with schedules not exceeding 600 or 700 activities and with numerous concurrent delays and subcritical paths. This method involves creating an As-Built schedule, where all activities reflect the actual duration and the logic followed in practice. It is then necessary to evaluate the delay events that affected the project, as well as logic changes and productivity losses. This advanced technique seeks to analyse the entire schedule in detail, moving from the As-Built schedule to the As-Planned schedule by collapsing delays and restoring the original logic.
Steps to implement the method
To use this technique effectively in expert reports, it is crucial to implement strategies that address its limitations. The first step is to create the model that represents the As-Built schedule. This can be done by adding specific activities, adjusting activity durations and modifying relationships so that the model reflects the construction reality.
Once the model has been created, the next step is to collapse the delays and analyse the difference between the resulting schedule and the As-Planned schedule. To collapse the model, the delay activities created must be removed (zero duration) and the original contractual duration of the activities restored. Since the logical sequence of activities is probably different from the contractual sequence, the collapsed schedule will not have the same dates as the planned schedule.
The third step is to identify the logic changes that differentiate the collapsed As-Built schedule from the As-Planned schedule. Activities in the planned schedule are normally linked Finish-to-Start, while in the As-Built they become Finish-to-Finish plus lag or Start-to-Start plus lag. Logic analysis is as laborious and complex as creating the collapsible As-Built model. To facilitate the transition from the As-Built schedule to the As-Planned schedule, it is essential to prepare spreadsheets containing all changes and allowing direct import into Primavera P6.
The responsibility for sequence and relationship changes, productivity losses and delay events must then be analysed. Once the events and logic changes have been detected, it is possible to move automatically from the contractual schedule to the As-Built schedule and calculate the delay responsibility of each party. To automate the transition from As-Built to As-Planned, it is very practical to prepare an Excel file so that a simple import into P6 can move the model from one state to the other.
At the end of the process an As-Built schedule is obtained which, once contractor and client events and changes have been collapsed, results in the contractual schedule. It will be possible to collapse only the client delays to calculate excusable compensable delay, and likewise to collapse the delay for which the contractor is responsible to calculate non-excusable delay. The remainder corresponds to excusable non-compensable delay.
This technique should only be implemented on simple projects, with few sequence changes, where the interested party is mainly responsible for the critical delays and the other party is responsible for subcritical or concurrent delays. The analysis allows concurrent delays to be detected very precisely and responsibilities and compensation to be determined fairly.
Weaknesses of CAB+IAP
- It does not consider the project's contemporaneous programmes.
- Creating the model requires a great deal of work, highly detailed as-built information and very experienced technical personnel in software use and delay analysis.
- Creating the logic to replicate as-built conditions requires subjective decisions that may not match the contemporaneous schedules.
- Difficult to explain to a tribunal.
- It ignores the critical path prospectively in contemporaneous programmes and the critical decisions that may have been made based on them.
- A reasonable and properly linked electronic baseline is required.
As Built vs As Plan Contemporaneous Windows Analysis
As-Planned vs As-Built Contemporaneous Windows Analysis is one of the most widely used techniques in expert reports because of its simplicity and because it can avoid dependence on planning software and schedule updates.
Once all necessary information has been collected, the analysis is carried out by reviewing contemporaneous programmes, site minutes and all available information that allows delay events and the critical path to be evaluated. The project is divided into windows defined by changes in criticality or relevant events.
The expert determines the real critical path for each window by applying their experience and the available information, with particular importance placed on the reasoning followed to define the critical path. The same steps as in the As-Planned vs As-Built method must be followed for this purpose.
The delay in each window is determined by comparing milestones or key dates between the contemporaneous schedule and the baseline. The events that caused that delay, and who is responsible for them, are then analysed.
The advantage of performing the analysis over several time periods is that the identification of delays or accelerations can be much more precise and easier to understand. The definition of the windows must be based on relevant milestones or changes in criticality.
This technique can be confused with Time Slice Analysis (TSA). Both consider the critical path dynamically by dividing it into sections or windows. However, TSA compares the delay in each window with the previous window, therefore taking replanning into account and depending entirely on planning software and updates. In this way, it is more susceptible to schedule modifications for commercial purposes, whereas ABAPW simply compares what was performed with the agreed plan while considering the critical path contemporaneously, because it uses the updates and the contemporaneous views of the parties.
Weaknesses of ABAPW
- It is not appropriate for projects with activities that have little total float, or in other words, several subcritical paths.
- It depends on the knowledge, experience and judgement of the technical person performing the analysis.
- It is difficult to detect and analyse concurrent delays.
- The analysis becomes complex when there are major sequence changes.
Time Impact Analysis
Time Impact Analysis (TIA) is a widely used technique for calculating and justifying extension of time (EoT) claims due to a specific event. When delays occur on the project outside the contractor's responsibility, the contractor must request an extension of time. The contractor must provide documentation proving the existence of the delay and showing that, under the contract, it is outside its scope or responsibility. The impact of that delay must also be calculated.
The main way to calculate the effect of a specific delay is through the Time Impact Analysis technique, because it allows the effect that an event will have to be quantified prospectively. This method involves adding activities to an updated schedule to represent the delay. Once one or more properly linked activities have been added to the schedule, the impact on project completion can be analysed. The more information the contractor can provide about the effect of the delay, the more likely it is that an extension of time will be approved.
Steps to implement the method
Implementation of the method can be summarised in three steps. First, identify which update will be used to insert the event or events to be analysed. Usually, this will be the last accepted schedule update before the impact date.
Then add and link the activities that model the delay event in the updated schedule. It can sometimes be difficult to determine where and how to insert the activities so that they represent the event as faithfully as possible. It is important to analyse the relationships of the critical activities because, if the event does not affect the critical path, no extension of time can be claimed.
Finally, analyse the impacts on the modelled schedule against the last approved update in order to determine the impact.
