Time Impact Analysis: A Practical Guide for Construction Claims and Programme Management

Time Impact Analysis (TIA) is one of the most widely used and most misunderstood
tools in construction delay analysis. Done well, it is a powerful method for demonstrating the
effect of a specific event on a project programme. Done poorly, it produces numbers that neither
party trusts and that courts and arbitrators reject.

This post explains what TIA is, when to use it, how to do it properly, and where it commonly
goes wrong.

What Is Time Impact Analysis?

Time Impact Analysis is a prospective or retrospective method of delay analysis
that measures the time impact of a specific compensation event, variation or delay cause by
inserting it into the programme at the point in time it occurred and measuring the resulting
change to the completion date.

The core logic is straightforward:

Take the programme as it stood immediately before the event (the impacted baseline)
Insert the delay event as a new activity or constraint
Reschedule the programme
Measure the difference in completion date before and after the insertion

That difference is the time impact of the event.

When Is TIA Used?

TIA is used in three main contexts:

1. Prospective TIA (Forward-Looking)

Used during the project to assess the likely impact of an event before it has fully
played out. Common in NEC contracts where early warning and compensation event assessment
are required within defined timeframes. The programme used is the current accepted programme.

2. Contemporaneous TIA

Carried out at or near the time of the event, using the programme that was current at that
time. This is the most defensible form of TIA because it reflects the actual state of the
project when the event occurred.

3. Retrospective TIA

Carried out after the event – often as part of a claim or dispute. The analyst reconstructs
the programme as it stood at the time of the event and then inserts the delay. This is the
most common form in practice and the most contested, because it requires judgements about
what the programme should have looked like at the time.

The Building Blocks of a Credible TIA

A TIA is only as good as the inputs. The following elements must be in place before the
analysis can be trusted.

1. A Reliable Baseline Programme

The baseline must be logic-linked, resource-loaded and realistic. A programme
that was never achievable, was not updated, or was not accepted by the parties is a weak
foundation for any TIA. If the baseline is challenged, the TIA built on it will be challenged too.

2. A Contemporaneous Updated Programme

The programme used as the starting point for the TIA should reflect the actual state
of the project immediately before the event. This means:

Actual progress recorded against activities
Remaining durations updated
Any pre-existing delays already reflected
Logic changes properly documented

Using the original baseline without updating it for actual progress is one of the most common
and most damaging errors in TIA.

3. A Clearly Defined Delay Event

The event being analysed must be:

Clearly scoped (what happened, when, where)
Linked to a contractual entitlement (variation, compensation event, employer risk event)
Supported by contemporaneous records (site diaries, RFIs, instructions, correspondence)

4. Correct Insertion of the Event into the Programme

The delay event is inserted as one or more activities with:

Correct duration (based on evidence, not assumption)
Correct logic links to affected activities
Correct start date (when the event actually started to affect the works)

5. A Clean Reschedule

After insertion, the programme is rescheduled using the same scheduling parameters as the
original (calendar, constraints, resource levelling settings). The new completion date is
compared to the pre-insertion completion date.

What TIA Shows – and What It Does Not Show

TIA answers one specific question:

“If this event had not occurred, would the project have completed earlier – and by how much?”

It does not automatically answer:

Whether the contractor is entitled to an extension of time (that is a contractual question)
Whether the contractor mitigated the delay
Whether concurrent delays exist and how they should be apportioned
Whether the delay caused actual cost loss (that requires a separate quantum analysis)

These are separate questions that require separate analysis. A TIA that conflates them with
the time impact calculation will be challenged.

Common Errors in Time Impact Analysis

The following errors appear repeatedly in TIAs submitted in claims and disputes. Each one
reduces the credibility of the analysis.

1. Using an Unupdated Baseline

Starting from the original baseline without reflecting actual progress means the TIA is
measuring the impact of the event against a theoretical programme, not the real one. This
almost always overstates the impact.

2. Inserting the Event at the Wrong Point in Time

The event must be inserted at the point it actually affected the works. Inserting it earlier
inflates the impact; inserting it later understates it.

3. Incorrect Logic Links

If the inserted activity is not correctly linked to the activities it actually affected, the
reschedule will not reflect reality. This requires a genuine understanding of how the works
were being executed, not just how they were programmed.

4. Ignoring Concurrent Delays

If other delay events were occurring at the same time, the TIA must address them. Ignoring
concurrent delays – whether caused by the employer, contractor or third parties – will
undermine the analysis.

5. Using a Programme That Was Never Achievable

If the programme used as the starting point was already unrealistic – because it was
resource-overloaded, had missing logic or was based on optimistic durations – the TIA
will produce unreliable results. The other party will attack the programme, not just the
event insertion.

6. Treating TIA as a Black Box

A TIA that cannot be explained in plain language to a project manager, adjudicator or
arbitrator is not fit for purpose. The analyst must be able to walk through the logic
step by step and explain why each decision was made.

TIA in Different Contract Frameworks

NEC Contracts

NEC3 and NEC4 require compensation events to be assessed using the Defined Cost
forecast and a revised programme. TIA is the natural tool for the programme element
of a compensation event assessment. The key discipline is timeliness – NEC requires
assessments to be made within defined periods, which means the programme must be kept
current.

FIDIC Contracts

FIDIC does not prescribe a specific delay analysis method but requires the contractor to
give notice and submit a programme showing the effect of the event. TIA is widely used
in FIDIC disputes. The quality of contemporaneous programme updates is critical.

AS 4000 / AS 4902 (Australian Standards)

Australian standard form contracts require the contractor to demonstrate the effect of a
delay event on the critical path. TIA is the standard method used. Courts and tribunals
in Australia have accepted TIA as a credible method where it is properly executed.

JCT / NEC (UK)

UK courts and adjudicators have accepted TIA in many cases. The SCL Delay and Disruption
Protocol (2nd edition) endorses a prospective/contemporaneous approach as the preferred
method, which aligns with TIA.

TIA vs Other Delay Analysis Methods

Method	Approach	Strengths	Weaknesses
Time Impact Analysis (TIA)	Insert event into programme, measure shift	Transparent, event-specific, widely accepted	Requires good programme records; can be manipulated
As-Planned vs As-Built	Compare original plan to actual outcome	Simple, uses actual data	Does not isolate individual events; ignores programme updates
Collapsed As-Built	Remove delay events from as-built to find earlier completion	Uses actual data	Highly subjective; often produces unreliable results
Windows Analysis	Analyse delay in time windows across project	Handles concurrent delays well; comprehensive	Time-consuming; requires extensive records
Global Claim / Total Time	Claim total delay without isolating events	Simple to prepare	Rarely accepted by courts; difficult to defend

Practical Tips for Getting TIA Right

Keep the programme current throughout the project.
A TIA prepared at the end of a project from a programme that was never updated is
far weaker than one prepared from monthly updates. Programme discipline during
execution is the single biggest factor in the quality of any subsequent TIA.
Document the event as it happens.
Site diaries, RFIs, instructions, photographs, correspondence and meeting minutes
are the evidence base for the TIA. Without them, the duration and scope of the
inserted activity will be disputed.
Give notice on time.
Most contracts require notice of delay events within defined periods. Late notice
can extinguish or reduce entitlement regardless of how good the TIA is.
Be honest about concurrent delays.
A TIA that ignores obvious contractor-caused concurrent delays will be attacked.
Addressing them head-on – and explaining why they do not affect the critical path
or how they should be apportioned – is a stronger position than pretending they
do not exist.
Use the right programme for the right moment.
The programme used as the starting point for the TIA must be the one that was
current immediately before the event. Using an earlier or later programme will
produce the wrong answer.
Have the analyst explain the logic in plain English.
If the TIA cannot be explained without the software, it will not survive scrutiny.
The analyst must understand the construction methodology well enough to explain
why the event affected those specific activities and not others.

The Link Between TIA and Construction Methodology

One of the most overlooked aspects of TIA is that its credibility depends heavily on
understanding how the work was actually being done. A delay analyst who
does not understand the construction methodology – the sequence, the plant, the crew
sizes, the dependencies – will produce a TIA that experienced practitioners will
immediately challenge.

For example:

A delay to concrete supply on a dam project only impacts the critical path if the
RCC placement cycle was the controlling activity at that time. If the critical path
was running through the diversion works, the concrete delay may have had no impact
at all.
A delay to a TBM drive only extends completion if the TBM was on the critical path.
If the surface works or fit-out were already driving the programme, the TBM delay
may be absorbed.
A delay to steel delivery on a data centre project may or may not be critical
depending on whether the MEP fit-out or white space works were already the
controlling sequence.

This is why the best delay analysts are also experienced construction planners and
methodologists – not just programme software operators.

Summary

Time Impact Analysis is a powerful and widely accepted method for demonstrating the
effect of delay events on a construction programme. Its credibility depends on:

A reliable, updated programme as the starting point
A clearly defined and evidenced delay event
Correct insertion of the event at the right point in time with the right logic
Honest treatment of concurrent delays
An analyst who understands the construction methodology, not just the software

A TIA that meets these standards is a credible, defensible tool in compensation event
assessments, extension of time claims and dispute resolution. One that does not will
be challenged at every step.

Need Help with Time Impact Analysis or Programme Delay Claims?

We work with contractors, owners and legal teams on delay analysis, programme management
and methodology-led claims. Our approach combines deep construction methodology knowledge
with rigorous programme analysis – so the TIA reflects how the work was actually being done,
not just how it was programmed.

Use the form below to discuss your project.

Time Impact Analysis: A Practical Guide for Construction Claims and Programme Management

What Is Time Impact Analysis?