The technique forecasts the delay caused by an event or a change in the future before the affected or changed work is performed. The client and contractor will agree to an estimated value of work, prior to the work being performed. This technique has nearly universal industry approval as the best way to forecast the delay.
As the name suggests, this retrospective analysis is the one, prepared after the delaying event(s) or change work has been performed. After the affected or revised work is completed, the approach detects the delays that have happened in the past. After the work is completed, the contractor will establish the actual cost of the job plus a markup for submission to the client for approval. Regrettably, there is no consensus or adoption of this technique as the best tool to determine the delay. There are other numerous approaches for the retrospective TIA delay analysis, which are listed below:
The analyst needs this method to determine the reasons for the project’s late completion by comparing the As-Planned (Baseline) Schedule to the As-Built Performance. This analysis is normally done at the WBS (Work Breakdown Structure) level of the Project Schedule.
In this technique, a frag-net for each delay event is created and entered into the baseline schedule, named as “Impacted As-Planned Schedule”, after which the schedule is re-run. Its project completion date will be compared against the As-Planned Schedule’s project completion date (Baseline). The delay measured as a result of delay frag-nets incorporated into the schedule is the difference in project finish dates. This approach is followed by most construction businesses since it exaggerates the delay and can be used to justify a time extension to the client. The delay mitigation plan is not part of this technique.
It’s just the opposite of Impacted As-Planned Analysis. The As-Built Schedule will be prepared as fully as feasible using this process, which is based on the current project documents. The analyst then subtracts activities or shortens the duration of delayed work items that have impacted the project, as evaluated by the analyst. The difference in days between the as-built and collapsed as-built end dates is due to a delay caused by certain tasks that were eliminated. This is a highly subjective analysis that is prone to inaccuracy and manipulation.
When there is no contemporaneous schedule to support the contractor’s delay argument, they may employ a “But for” analysis. The contractor may argue that if the Owner’s delays were not factored into the initial project timeline, he could have completed the job considerably sooner. The gap between the actual completion date and the “but for” timetable is then used to calculate the amount of time the Client has caused delays.
In this technique, the analyst examines delays during the project in discrete time intervals or “windows.” Analysts usually base the window on the time period in which a specific controlling operation is crucial. When the controlling activity becomes crucial for the first time, the window will begin. Likewise, the window must close when the controlling activity is completed or no longer critical.