What is a TIA?
The phrase “Time Impact Analysis” (TIA) has several meanings within the schedule delay analysis field. Typically, a TIA refers to a modeled method of schedule delay analysis to aid in supporting requests for an extension of contract time. A TIA can be performed prospectively (in advance of a delay event), or retrospectively (after delay has been realized on a project). Industry publications define a prospective TIA as a “‘forward-looking,’ prospective schedule analysis technique that adds a modeled delay to an accepted contract schedule to determine the possible impact of that delay to project completion.” While other forensic scheduling publications classify retrospective schedule analyses as TIAs, as well. The question then becomes, if a contract requires the submission of a “TIA,” what methodology is it specifying? Is it appropriate to use a TIA to support an after-the-fact delay claim? This article explores the definition of a prospective and retrospective TIA, useful and less-useful applications of a TIA, and the downfalls of relying on a prospective model for claims development.
Prospective TIAs
A prospective delay analysis is one prepared in advance of delaying events or changed work, to model what is likely to happen as a result of the subject impact event(s). The Association for the Advancement of Cost Engineering (“AACE”) International defines prospective analyses as follows:
Prospective analyses are performed in real-time prior to the delay event or in real-time, contemporaneous with the delay event. In all cases prospective analysis consists of the analyst’s best estimate of future events. Prospective analysis occurs while the project is still underway and may not evolve into a forensic context...
A prospective TIA can be an effective tool to model a projection of an impact to project completion, a project milestone, or other key project date (“Completion Date”) for purposes of negotiation of a time extension. The steps of a prospective TIA include the addition of a fragnet to represent the delaying event or change work in question into a copy of an “unimpacted” schedule to create an “impacted” schedule. The difference between the projected Completion Date of the unimpacted and impacted schedules is what determines the time extension request. See the example in the hyperlink for a graphical depiction of a TIA.
A TIA is more effective, and subsequent negotiations tend to be more successful, if the schedule fragnet is realistic and potential contractor delay mitigation (i.e., can the impact be minimized by completing the work in a revised sequence or shorter period of time) is considered. Furthermore, a party should not “wait and see” but should submit and try and negotiate a time extension as soon as a potential delay event arises.
Since a prospective TIA is performed in advance of a delay and is only a “best estimate of future events,” it does not identify what actually delayed the project during the impact period. During the impact period, other impact events may have arisen and become more critical, or the contractor might have mitigated the subject delay on an actual basis. A TIA does not typically model extended durations of non-impact activities, and therefore, may not consider all proceeding events.
Further, a prospective TIA typically does not effectively identify concurrent delays during the impact period. Yet the determination of delay concurrency is a necessary prerequisite to establishing whether a delay is compensable or non-compensable. In this regard, while the TIA process may be able to model or estimate various simultaneous impacts or delays, the TIA process may not provide definitive guidance regarding delay compensability / entitlement to delay damages.
Retrospective TIAs
A retrospective analysis is one prepared after the delaying event(s) or change work has been performed, such that the actual sequence, timing, and resources of the work related to the subject event(s) are known.
AACE defines Retrospective analyses as:
Retrospective analyses are performed after the delay event has occurred and the impacts are known. The timing may be soon after the delay event but prior to the completion of the overall project, or after the completion of the entire project... In other words, even forward-looking analysis methods implemented retrospectively have the full benefit of hindsight at the option of the analyst.
The key, as emphasized in the definition above, is a retrospective analysis is performed with the “full benefit of hindsight.” Unlike a prospective analysis, there is not the need to estimate the timing and impact of delays – as-built data is available.
A modeled Retrospective TIA, in general terms, is a method of analysis in which, after the delaying event has occurred, a known or “as-built” fragnet or fragnets are inserted into a planned schedule. This methodology can be referred to as an “impacted as-planned” analysis (generally, if the as-planned schedule is the baseline schedule) which triers of fact have rejected because it leads to hypothetical results. As the model only analyzes impacts to a single planned schedule, it typically 1) does not address what work was contemporaneously critical in future schedule updates, 2) does not consider scope or logic changes to non-modeled paths of work, and 3) may only model delays from one party. In its typical implementation, a modeled Retrospective TIA also has similar flaws to a Prospective TIA with regard to delay concurrency.
Unless circumstances require it, a modeled Retrospective TIA should generally not be performed as a forensic evaluation to establish entitlement to a time extension and delay damages. Rather, an observational method of analysis to determine what actually occurred on the project’s as-built critical path in a chronological and cumulative basis, should be performed.
Application
Contracts often require that a TIA be performed to support requests for a time extension. A prospective TIA is a useful tool during the project and in advance of a delay event. However, if negotiations of time extensions during the course of a project fail, the claimant must decide if a modeled TIA should still be submitted with an after-the-fact delay-related claim.
In general, neither a prospective nor a retrospective TIA are recommended in this situation. Once a delay has been realized and associated as-built data is known, the actual delay impact can be observed, removing the need to forecast a potential delay or model an impact. Since a prospective analysis only projects potential impacts as of a point in time, this analysis often cannot establish that the projection is accurate. A prospective analysis also does not determine if other work during the impact period became solely or concurrently critical. As a result, the analysis may not provide the trier of fact with a proper understanding of the actual impacts on the project and the party responsible for the claimed delay damages.
When developing a claim for an extension of time and delay damages, a main focus should be to establish a cause and effect relationship between the event in question and a delay in the Completion Date. A retrospective delay analysis needs to uncover what issues caused actual effects on the work.
An observational retrospective analysis can be a more reliable forensic delay analysis tool to accurately identify actual critical and near-critical path activities without the need to model individual delay events. Furthermore, an observational analysis “allows the analyst to determine which delay impacts are concurrent, which are staggered, and which are near critical versus precisely critical with less subjectivity than if only projected dates were used.” However, contract language should be reviewed carefully. While specifications generally require a TIA to be submitted only in prospective situations, they may also require that a prospective TIA is required to “settle all delay matters, both during and after the project performance.”
Even if the contract requires a prospective TIA, preparing an observational analysis would generally aid the claimant. In an after-the-fact claim, the best as-built information available should be relied on, rather than projections of impact events. A retrospective analysis will allow a claimant to establish the actual sequence of events on the Project, the as-built critical path of the Project, and what competing or concurrent delays may have occurred. This analysis can also help support that the TIA projections were reasonable.
To avoid confusion and to guide the parties effectively, scheduling specifications should be clear as to when and how a TIA is to be prepared and submitted, what is required in the submission, and should specifically state that the TIA is to be prospective and/or retrospective in nature. Further, the scheduling specification should be clear as to whether the TIA methodology should govern the after-the-fact resolution of time-related disputes.
Conclusion
In conclusion, a prospective TIA is an important tool to deal with the negotiation of a contract time extension during the project, while an after-the-fact claim should be supported with a retrospective analysis, using available as-built data. This analysis should identify the as-built critical path to the Completion Date and apportion the source, magnitude, causation and responsibility of the associated actual critical delays to the parties.
In such cases where a contract requires the use of a prospective TIA retrospectively, it is advisable to perform a prospective TIA, bolstered with a retrospective analysis.