What Is Time Impact Analysis?

Article

Time Impact Analysis (TIA) is a method for estimating how a defined delay event changes the remaining critical path of a construction programme. It does not, by itself, decide entitlement, quantum, or which party is responsible. It answers a narrower question: if this event is inserted into a reliable model of remaining work, how does completion move?

What the method is doing

A usable TIA starts from an update that already reflects progress, remaining durations, and logic at a chosen data date. The analyst then adds a fragment that represents the delay event — additional work, a stoppage, a late access date, or a change that alters remaining sequence — and recalculates. The difference between the projected completion before and after that insertion is the modelled time impact.

That difference is only as good as the update, the fragment, and the logic that connects them. If the update is already out of date, if remaining work is unconstrained fiction, or if the fragment is a lump of time with no identified activities, the result is a number without a defensible basis.

When TIA is appropriate

TIA is a reasonable tool when all of the following are true, or can be reconstructed with stated assumptions:

• The delay event can be described as a discrete insertion rather than a vague period of poor performance.
• The affected remaining activities can be identified in the live programme.
• There is a progress update close to the event, or a clear method for bringing the model to that point.
• The programme has logic that actually drives remaining work, not open ends and constraints used as decoration.

It is less appropriate when the complaint is a long stretch of cumulative disruption, when records cannot locate the event, or when the only available programme is a baseline that has not been updated for months. Other delay methods exist for those conditions; using TIA anyway does not make the evidence stronger.

What the model needs

The fragment should identify the delayed work, its duration basis, and its logical ties into remaining activities. A bar labelled “delay” with no successor is not an analysis. Equally, holding completion with an artificial constraint while inserting the fragment will hide the very movement the method is meant to show.

Limitations that are easy to ignore

TIA is sensitive to data date, remaining-duration estimates, calendars, and lag. Small modelling choices can move completion by days. That is not a reason to avoid the method; it is a reason to record the choices. A TIA that cannot be rerun from stated inputs is an illustration, not an analysis.

Windows analysis, collapsed as-built, and time-chainage methods answer different questions. They are not interchangeable labels. Choosing TIA because it sounds technical, when the records support only a broader as-planned versus as-built comparison, produces a precise-looking answer to the wrong problem.

High-stakes contractual interpretation — including how a form treats concurrent delay, notice, or time at large — sits outside the method. Time Impact Analysis can inform those debates. It does not replace them.