Time Impact Analysis (TIA) answers one specific question: if this delay event happened exactly when and how it did, what did it do to the project's completion date? It's the method most commonly required — explicitly or implicitly — by contract notice provisions, because it's designed to be run close to the delay event, while the schedule logic is still fresh and uncontested.

The core idea

TIA is a prospective, cause-and-effect analysis. Instead of waiting until the end of the project to look back and untangle what happened, you take the schedule as it stood immediately before the delay event, insert the delay itself, and recalculate. Whatever shift appears in the completion date is the "time impact" — and it's usually the number the EOT claim is built around.

This is different from methods like Windows Analysis, which look backward over a completed period to see what actually happened. TIA looks forward from a single fixed point: the moment just before the delay occurred.

The fragnet: how TIA actually works

The mechanism at the center of TIA is the fragnet — a small fragment of a network schedule representing the delay event and its logic. The general steps:

Establish the base schedule. Take the last schedule update that was accepted or agreed before the delay event occurred — not the original baseline, and not a later update that might already reflect other changes.
Build the fragnet. Model the delay event itself as a set of activities with realistic durations and logic ties into the existing schedule — where it starts, what it depends on, and what depends on it.
Insert and recalculate. Add the fragnet into the base schedule and let the critical path recalculate.
Compare finish dates. The difference between the original projected finish date and the new one, after the fragnet is inserted, is the time impact of that specific delay event.

Because each delay event gets its own TIA, a project with multiple delay events over its life will typically have a whole series of individual TIAs, each isolating one event's impact rather than trying to explain the whole project's slippage at once.

Why TIA is the default for notice-driven contracts

Contracts with strict delay-notification windows — FIDIC's Sub-Clause 20.1-style notice provisions are the clearest example — effectively assume TIA as the assessment method. The logic lines up: if you're required to notify a delay event within a short window of it occurring, you need a method that can be run at that same point in time, using the schedule as it stood right then. TIA fits that requirement in a way that backward-looking methods, which need the project to run further before they can be applied meaningfully, don't.

Where TIA gets challenged

TIA claims are most commonly attacked on two fronts:

The base schedule itself. If the schedule update used as the "before" state wasn't properly accepted, or had unresolved logic problems (open ends, illogical constraints, missing predecessors), the whole TIA inherits that weakness — the recalculated impact is only as credible as the schedule it was calculated from.
The fragnet's realism. A fragnet with an inflated duration, unrealistic logic ties, or activities that don't reflect how the delay actually unfolded on site is an easy target for the other side to discount or reject outright.

In practice, this means the strength of a TIA claim is decided well before the analysis itself — it's decided by how disciplined the schedule maintenance was in the weeks and months before the delay happened. A schedule full of open ends, hard constraints used to force dates, or unresolved logic gaps produces a TIA that's vulnerable no matter how carefully the fragnet is built afterward.

TIA vs. the other methods, briefly

TIA isn't the right tool for every situation — it assumes a single, discrete, well-documented delay event and a clean base schedule to work from. When a project has multiple overlapping delays across an extended period, or the schedule updates themselves are inconsistent, Windows Analysis is usually the better fit. When the baseline can't be trusted at all, Collapsed As-Built becomes the fallback. (See the full comparison in the delay analysis methods pillar page.)

Keeping TIA defensible

The practical takeaway is that TIA is won or lost on schedule hygiene, not just on the day the fragnet gets built. Keeping every activity properly linked, avoiding unnecessary hard constraints, and maintaining a clean, contemporaneously-approved run of schedule updates is what makes a TIA hold up when it's challenged — and it's the same discipline that makes every other delay analysis method on this site's comparison page more defensible too.