Time Impact Analysis (TIA) is one of the most commonly specified delay analysis methods in construction contracts, and one of the most commonly misapplied. The contract says the contractor must submit a TIA with every delay claim or change order request. The contractor does so, usually as a forward-looking exercise to support a request for extension of time (EOT). Years later, when the project is finished and the parties are in dispute, someone decides to use TIA retrospectively to quantify the total delay impact. That retrospective use is where TIA gets into trouble.
Understanding why requires looking at what TIA is designed to do, how AACE RP 29R-03 classifies it, and why the forensic community has increasingly cautioned against stretching it past its prospective purpose.
A Quick Orientation Within AACE RP 29R-03
TIA lives in the modeled side of the AACE taxonomy. In prospective use, it is not a formal MIP under the retrospective forensic framework, but it is the method most contracts contemplate when they specify time impact analysis for change orders or EOT requests. In retrospective use, TIA maps most closely to MIP 3.7 (Modeled / Additive / Multiple Base), where delay fragnets are inserted into the contemporaneous schedule updates that were current at the time of each delay.
The distinction between prospective TIA and retrospective TIA matters because the information available to the analyst is fundamentally different, and the defensibility of the result is correspondingly different.
What the Method Does
TIA measures the impact of a specific delay event by inserting a representation of the delay (a "fragnet" of activities with logical ties to the existing schedule) into the project schedule at or near the time the delay occurred, recalculating the CPM network, and comparing the projected completion date before and after the insertion. The difference is the time impact of the event.
In prospective use, TIA is typically applied to:
- A specific change order or potential change that has just been identified.
- An ongoing delay whose full impact is not yet known but needs to be estimated for EOT purposes.
- A what-if analysis to evaluate the effect of a proposed schedule change.
The schedule used for the analysis is the most recent contemporaneous update, and the fragnet represents the delay as understood at that point in time.
In retrospective use, the analyst applies the same technique but with the benefit of hindsight: each delay event is inserted into the contemporaneous update current at the time the delay actually occurred, and the results are aggregated across the project.
The Procedure
For a single prospective TIA:
- Identify the delay event and gather supporting facts (cause, duration, responsible party).
- Select the contemporaneous schedule update that was current when the delay occurred or is expected to occur.
- Construct a fragnet that represents the delay's activities with appropriate logic ties to the existing schedule.
- Insert the fragnet into the schedule, maintaining the original logic except where the delay explicitly modifies it.
- Recalculate the CPM network.
- Compare the projected completion date before and after the insertion. The difference is the time impact.
- Document assumptions about fragnet durations, logic ties, and concurrency treatment.
For retrospective multi-event TIA (MIP 3.7), repeat the process for each delay event using the contemporaneous update current at each event's date, and aggregate.
When to Use It
TIA is well-suited for:
- Prospective EOT evaluation where a specific delay event needs to be quantified in near-real-time.
- Change order time impact assessment where the contract requires it.
- Contemporaneous claims analysis supporting requests for additional time as events unfold.
- What-if scheduling to evaluate proposed changes before committing to them.
- Single discrete delay events that are relatively easy to isolate and model.
When used prospectively, on a well-maintained schedule, for a single clearly-defined event, TIA is a clean and widely-accepted technique.
The Problem With Retrospective TIA
The forensic community has grown increasingly skeptical of retrospective TIA, and the reasons are worth understanding.
- Hindsight bias. When an analyst inserts a fragnet into a historical schedule knowing what happened afterward, the fragnet can be constructed to produce a desired result. The discipline that prospective TIA enforces (using only the information available at the time) is harder to maintain retrospectively.
- Concurrency treatment. Single-event TIA does not naturally account for concurrent delays occurring at the same time. When multiple events are TIA'd independently and summed, the total can exceed the actual project delay, which is mathematically incoherent.
- Schedule manipulation exposure. Retrospective TIA requires the analyst to choose the "right" contemporaneous update for each event. If the updates were manipulated during the project, the analysis inherits the manipulation.
- Divergence from actual events. TIA models the expected impact of a delay based on the schedule logic at the time. What actually happened on the project may differ substantially, and retrospective TIA does not correct for that divergence.
- Aggregation problems. Summing independently calculated TIAs across a project does not produce a defensible total project delay, because delays interact with each other in ways that individual TIAs do not capture.
Livengood and others in the forensic community have argued that retrospective TIA should generally be replaced by windows-based or observational methods that better respect the contemporaneous record of what actually happened.
Caveats Worth Respecting
Even for prospective use, TIA requires discipline:
- The schedule must be well-maintained. A TIA performed on a poorly updated or illogical schedule produces unreliable results.
- Fragnet construction is judgment-intensive. The logic ties and durations chosen for the fragnet drive the result. Assumptions have to be documented.
- Concurrency has to be addressed explicitly. If other delays are occurring simultaneously, the TIA has to account for them or acknowledge that it does not.
- Contract compliance matters. Many contracts specify TIA procedures in detail. Non-compliance with the contractual method can defeat an otherwise meritorious claim.
Where It Sits in the Bigger Picture
TIA is best understood as a prospective or near-contemporaneous tool. Used that way, inside the project's own rhythm of updates and change orders, it serves its purpose well. Stretched into retrospective forensic use, it accumulates problems that windows-based methods avoid. The practitioner's takeaway is to use TIA for what it was designed for, specify it clearly in contracts, and consider other AACE MIPs when the question is what actually happened on a completed project rather than what is likely to happen going forward.
The contract may require TIA. The dispute may benefit from something else. Understanding the difference is what separates a scheduler from a forensic analyst.
References
- AACE International, Recommended Practice No. 29R-03, Forensic Schedule Analysis (current edition). See MIP 3.7 and the RP's discussion of prospective versus retrospective modeled methods.
- AACE International, Recommended Practice No. 52R-06, Time Impact Analysis - As Applied in Construction.
- AACE International, Professional Practice Guide No. 20 (PPG #20), Forensic Schedule Analysis (2nd Edition). Collected papers on TIA application and critique.
- Livengood, J.C. "Retrospective TIAs: Time to Lay Them to Rest," AACE Transactions.
- Society of Construction Law, Delay and Disruption Protocol (2nd Edition, 2017). Addresses TIA as the preferred prospective method while identifying its retrospective limitations.