Delay analysis in construction is always a live issue on distressed projects. Once progress starts slipping, the argument usually moves quickly from programme updates to responsibility, extension of time entitlement, mitigation, and downstream cost exposure. Among the different approaches used to assess delay, time impact analysis is one of the most common, but also one of the most misunderstood.
Time Impact Analysis (TIA) is a modeled schedule analysis in which the analyst inserts the activities and logic associated with a delaying event into the relevant programme update and measures the resulting movement in project completion or milestone dates.
In practice, it often sits behind Extension of Time (EOT) Claims, variation-related time assessments, contemporaneous contract administration, and later dispute positions. Used properly, it helps the project team test the time effect of a specific event while the project is still live.
In this article, we will further discuss the TIA analysis, how it works, and when it suits the most for delay analysis.
What Is Time Impact Analysis (TIA)?
Time impact analysis is a prospective delay analysis method, which takes a live delay event, inserts its effect into the programme update closest to that event, and measures what happens to completion or key milestones.
That is why TIA is usually associated with current contract administration rather than purely historical review. It is designed to answer a practical question: if this event is accepted as a valid delay event, what is its expected impact on time?
AACE International, in Recommended Practice 29R-03 Forensic Schedule Analysis, places the main split in delay analysis between prospective and retrospective methods. Within that framework, TIA is generally treated as a modeled additive prospective method. The Society of Construction Law takes a similar practical view and supports contemporaneous assessment of time impacts rather than leaving everything until project closeout.
In short, TIA is strongest when the project is still moving, the programme is current, and the parties need to make live decisions on time.
Prospective vs Retrospective Delay Analysis
This distinction matters more than many teams realize.
- A prospective analysis looks forward from the date of the programme update being used. It asks what the delay event is expected to do from that point. That is the home territory of TIA.
- A retrospective analysis looks backward after more facts are known. It asks what actually happened and why. That is where methods such as Window Analysis Method or other approaches from What are the Existing Delay Analysis Methods? often become more appropriate.
The commercial point is simple. If the contract requires a live assessment of an event for EOT purposes, TIA may be exactly the right tool during the works. But if the project is already complete and the full delay story is known, a prospective model may no longer be the best fit.
That is also why TIA should not be treated as a one-size-fits-all answer. It solves a timing problem as much as a technical one.
How Time Impact Analysis Works
At its simplest, TIA compares:
- The programme update before the delay impact is inserted.
- The same update after the delay impact is inserted.
The difference between the two shows the modeled time effect of the event. Usually, that process involves:
- selecting the right programme update
- identifying the delaying event clearly
- building a fragnet to represent that event
- linking the fragnet into the programme logic
- recalculating the programme
- reviewing the impact on completion, milestones, and the controlling path
This is where the concept of Float in a Construction Program becomes important. If the event only consumes float, completion may not move at all, meaning that the delay probably do not impact completion dates. On other hand, If it drives the critical/controlling path, the result may support time entitlement.
AACE also links this type of analysis to modeled additive approaches such as:
- MIP 3.6: Modeled / Additive / Single Base
- MIP 3.7: Modeled / Additive / Multiple Base
You do not need to overcomplicate that taxonomy for day-to-day project use. The practical point is that TIA is about testing a delay event against the right programme status, not just adding days and calling it analysis.
What Is a Fragnet in TIA?
A fragnet is a small piece of schedule logic inserted into the programme to model the effect of a delay event. It is not just an extra duration bar added to the schedule. A proper fragnet should show how the event actually affects the work and what additional steps or changed sequence it creates.
Depending on the facts, that may include:
- waiting for revised information
- review and approval periods
- resequenced work
- procurement impacts
- access restrictions
- demolition and rework
- latent conditions
- new testing or inspection activities
A simple way to think about a fragnet is this: it tells the programme story of the delay event.
For example, imagine the principal instructs, through a variation order, the contractor to change the cladding system for part of the facade after the original installation sequence has already been planned. That instruction may not just add one new activity.
In practice, it may require the contractor to stop part of the planned installation, wait for revised design details, review the new drawings, procure different materials, resequence surrounding works, and then restart installation in a different order. A proper fragnet would model that sequence, rather than simply inserting a rough block of extra days.
That is why fragnet quality matters. If it does not reflect the real mechanism of the delay, the TIA result will not be especially persuasive. A weak fragnet can make a genuine delay look unconvincing, while an exaggerated fragnet can make the analysis look artificial. AACE makes an important point here: fragnet modelling is a tool or procedure within the method. It is not a separate delay analysis family by itself.
Step-by-Step Time Impact Analysis Process
Once the principle is understood, the actual process becomes easier to follow. A proper TIA is usually built in stages, and each stage matters because a weak step early on can distort the final result.
1. Define the delay event clearly
Start with the event itself. Identify what happened, when it happened, what work it affected, and why it matters. That sounds obvious, but many weak delay analyses begin with a vague complaint rather than a clearly defined event.
The event may relate to a late instruction, restricted access, delayed approvals, late design information, a latent condition, or a change instructed under a variation request or variation order.
The clearer the event definition is, the easier it becomes to model it properly.
2. Select the correct programme update
The usual starting point is the programme update closest to the event and before the event’s effect is already built into the programme. That matters because TIA is meant to test the effect of the event from the point where the parties were actually standing at the time.
If the update is stale, inaccurate, or already contaminated by the delay being assessed, the output becomes less reliable.
3. Check whether the programme update is credible
Before inserting anything, step back and ask whether the update itself is usable. Does it reflect real progress? Is the logic reasonably sound? Are there artificial constraints or obvious sequencing issues?
This is a practical point that often gets missed. A TIA is only as reliable as the schedule it is built on. If the base programme is distorted, the analysis built on top of it is likely to be distorted as well.
4. Build the fragnet
The fragnet should model the actual delay mechanism. In other words, what did the event force the project team to do differently?
That may involve many issues as previously discussed. The aim is not to create a claim narrative in schedule form. The aim is to show the real impact sequence.
5. Insert the fragnet into the programme
Once the fragnet is built, it is linked into the existing programme logic. This has to be done carefully. If the links are too broad or artificial, the result can overstate delay. If the links are too weak, the result can understate it.
This is one reason TIA often becomes contentious. Small logic choices can materially affect the outcome, and owners and contractor might have different understanding of it.
6. Recalculate and review the result
After the fragnet is inserted, the programme is recalculated. The analyst then reviews what has changed, including:
- completion date
- key milestones
- float consumption
- the critical or controlling path
- any overlap with other delay events
This is also where Concurrent Delay in Construction may come into the picture. TIA can help show the effect of an event, but it does not automatically solve concurrency issues by itself.
7. Assess the net effect
The inserted duration is not the answer. The real question is the net effect of the event on completion or milestone dates after logic and float are taken into account. That is the number that usually matters for EOT purposes.
8. Connect the result back to contract administration
A useful TIA should not sit in isolation as a technical exercise. It should feed into live project administration, including a notice of delay, an early warning notice, an EOT submission, time-related variation assessment, possible prolongation costs, and any relevant time bar clauses.
That is where TIA becomes commercially useful rather than just technically interesting.
Simple TIA Example
A simple example makes the method much easier to understand.
Assume a contractor is building a utility structure. The current accepted programme update shows structural concrete completing on 15 August, followed by steel installation and commissioning, with overall project completion on 30 September.
On 20 July, the principal instructs a design change to the reinforcement layout for part of the structure wall. The contractor cannot proceed with the planned concrete sequence until revised information is issued. Final drawings arrive on 30 July.
A practical TIA might look like this.
Original programme position
- reinforcement fixing: 21 July to 27 July
- formwork and inspection: 28 July to 31 July
- concrete pour: 1 August
- follow-on steel installation starts: 10 August
- completion: 30 September
Delay event and fragnet
- wait for revised reinforcement design: 20 July to 30 July
- review revised drawings and resequence work: 31 July to 2 August
- rework reinforcement installation: 3 August to 8 August
Modeled result
- concrete pour moves from 1 August to 12 August
- follow-on activities move accordingly
- completion moves from 30 September to 9 October
Net modeled effect
- expected delay to completion: 9 days.
The important point is that the 9-day delay does not come from simply adding up the duration of the fragnet. It comes from the movement in the project completion date after the fragnet is inserted into the programme logic and the schedule is re-run.
In this example, the original completion date was 30 September. After the delay event is modelled, the revised completion date becomes 9 October. That shift in the completion date is what produces the 9-day time impact.
This is why Time Impact Analysis is more than simply adding extra days to the programme. The fragnet itself spans a longer period, and the affected concrete sequence shifts by more than 9 days. However, not every day within that inserted sequence necessarily translates into delay to overall project completion. Part of the impact may be absorbed elsewhere in the programme, depending on logic, float availability, sequencing, and the timing of downstream activities.
It is therefore essential to distinguish between three separate concepts:
- the duration of the delay event itself
- the movement of the directly affected activities
- the net movement of project completion
When TIA Is Appropriate (And When It Is Not)
One of the biggest mistakes in delay analysis is treating TIA as the default answer for every problem. It is not. It is a strong method in the right setting, but a poor one in the wrong setting.
TIA is usually appropriate when:
- the project is live or the event is still relatively recent
- a reliable programme update exists near the event date
- the contract requires contemporaneous assessment of time impacts
- the issue is a specific delay event rather than a broad historical delay story
- the parties need an EOT assessment while the works are still progressing
- the event can be modeled credibly through schedule logic
That is why TIA is often used for live issues such as variations, delayed information, access restrictions, approval delays, and employer-risk events.
TIA is usually weaker, or sometimes simply the wrong method, when:
- the project is already complete
- the full delay history is already known
- the relevant update is missing or unreliable
- the schedule logic is too poor to support a meaningful analysis
- the issue is really about reconstructing what actually happened over time
- the main problem is concurrency across a longer historical period
This is the practical dividing line. If the job is still moving and the parties need a forward-looking view of a live event, TIA can be very useful. If the issue is a historical reconstruction after the fact, another method may be more appropriate.
Advantages and Limitations of TIA
TIA is widely used because it does offer real practical advantages.
Advantages
A good TIA can:
- support live decision-making
- help assess EOT entitlement while the works are ongoing
- test whether a variation or delay event is truly completion-critical
- support mitigation discussions before positions harden
- create a structured record of the event’s likely time effect
- improve the quality of later claim or dispute analysis
It is also useful because it links time with wider commercial consequences. If completion is at risk, that may affect prolongation, sectional completion, resource planning, and exposure to liquidated damages.
Limitations
At the same time, TIA has clear limitations:
- it depends heavily on the quality of the programme update
- it can be distorted by poor or biased fragnet modelling
- it becomes less reliable the further it moves from the live event
- it does not resolve concurrency automatically
- it can be misused where actual outcomes are already known
- repeated TIAs on heavily changed projects can become cumbersome
So the value of TIA is not that it is automatically correct. The value is that, when used properly, it gives the parties a disciplined way to assess time impact while decisions still matter.
TIA vs Window Analysis
TIA and the Window Analysis Method are both logic-based approaches, but they are built for different purposes.
TIA is generally prospective. It asks: what is this event expected to do from this point in the programme?
Window analysis is generally retrospective. It asks: how did delay actually develop across different periods of the project?
That difference matters in practice. Typically, we use TIA when the issue is a live event that needs to be assessed during the works. On the other hand, window analysis is preferred when the issue is a historical review of what actually happened over time.
A project may involve both methods at different stages. A contractor might submit a TIA during the project for EOT purposes, while a later dispute expert might rely more heavily on window analysis once the full history is known. That is not inconsistent. It simply reflects the difference between live administration and later forensic review.
TIA vs As-Planned vs As-Built
An as-planned vs as-built analysis is usually simpler and more descriptive. It compares the original plan with what actually happened.
That can be useful at a high level, but it is often too blunt to answer more detailed entitlement questions. It may show that the project finished late, but it does not always show clearly why that happened or how a specific event affected the critical path at the time.
TIA is more useful where the real question is the effect of a particular live event on completion. This is especially true where the project is dealing with:
- shifting critical paths
- float consumption
- resequencing
- overlapping delays
- event-specific EOT entitlement
In practical terms, as-planned vs as-built can describe delay, but TIA is often better at testing a live event’s likely time effect while there is still time to act on it.
What AACE 29R-03 and the SCL Protocol Say
It is useful to know what the main industry references say, but the key is to keep the takeaway practical.
AACE 29R-03 gives the clearest technical structure. It separates prospective methods from retrospective ones and explains that labels in the market are often used loosely. That matters because teams often use “TIA” to describe several slightly different exercises.
For prospective TIA, AACE points back to a few essentials:
- use the unimpacted update before the event
- insert the fragnet with proper logic
- review the controlling path
- check for artificial logic effects
- measure the net schedule effect rather than just the added duration
The SCL Delay and Disruption Protocol is more operational in tone. It supports contemporaneous assessment of delay and EOT issues, rather than waiting until the end of the project to work everything out. It also supports the use of a fragnet or sub-network linked into the programme update closest to the event.
Taken together, those sources point in the same practical direction: TIA is strongest as a live project administration tool, especially when the programme is current and the parties still need to make active decisions on time.
Common Mistakes in Time Impact Analysis
The most common mistakes in TIA are not just technical mistakes. They are often judgment mistakes.
Using the wrong programme update
If the analysis starts from the wrong update, the result may be unreliable from the beginning. A stale update, or one already affected by the event, can distort the answer.
Building an unrealistic fragnet
If the fragnet does not reflect the real delay mechanism, the output will not be persuasive. A fragnet should model what actually changed in the work sequence, not simply collect extra days.
Ignoring float
Not every delaying event moves completion. If float is available, the event may consume float without creating current entitlement to extra time. To further understand who owns the float, read our article on the float in construction projects.
Ignoring concurrency
If another delay was affecting the same controlling path at the same time, that issue still needs to be addressed. TIA does not make concurrency disappear.
Treating TIA as a claim substitute
A schedule model alone is not enough. The analysis still needs to align with notices, records, instructions, and the contract process.
Using TIA too late
If the project is complete and the full delay history is known, a prospective TIA may no longer be the best analytical fit.
Contract and Claims Implications
This is where TIA moves beyond scheduling and becomes commercially important.
For Owners / Clients
For owners, principals, and contract administrators, TIA can be used to test whether a delay event really affects completion or whether it only affects local progress.
That is specially useful when deciding whether an EOT should be granted, whether mitigation needs to be pushed harder, and whether the event creates wider exposure on cost or completion. A good TIA can help an owner:
- assess whether an EOT request is credible
- distinguish completion-critical delay from non-critical disruption
- understand whether a variation affects time as well as cost
- manage exposure to prolongation and liquidated damages
- make earlier decisions before claims harden into disputes
For Contractors
For contractors, TIA can be a practical tool for preserving entitlement while the project is still live. It helps move the discussion beyond general complaint and toward a structured explanation of how the event affects completion.
A good TIA can help a contractor:
- support a timely EOT submission
- explain the time effect of variations, delayed information, or restricted access
- show causation in a more disciplined way
- connect time consequences with prolongation costs
- strengthen the record for later claims if the issue is not resolved early
In both directions, TIA often sits at the center of delay administration, change management, and later dispute positioning. That is exactly why it needs to be handled carefully.
Practical Checklist Before Submitting a TIA
Before relying on a TIA, it helps to ask a few practical questions:
- have you defined the delay event clearly?
- are you using the right programme update?
- is that update credible and properly progressed?
- does the fragnet reflect the real impact sequence?
- have you checked whether float absorbs some or all of the delay?
- have you considered whether another delay was operating at the same time?
- have you measured the net effect on completion or milestones?
- have you connected the analysis back to the notice and EOT process?
- does the contract require any particular timing or format for the submission?
- is TIA actually the right method for this timing context?
If the answer to several of those questions is no, the problem may not just be the quality of the TIA. The problem may be that a different method is needed.
FAQ
What is time impact analysis in construction?
Time impact analysis is a prospective delay analysis method that inserts a modeled delay event into the programme update closest to that event in order to assess the likely effect on completion or milestones.
Why is TIA considered a prospective method?
Because it looks forward from the date of the relevant programme update and asks what the event is expected to do from that point onward.
Is TIA the same as fragnet analysis?
Not exactly. A fragnet is the schedule insert used to model the event. TIA is the broader delay analysis method that uses that fragnet within the programme update.
When is TIA most useful?
It is most useful on live projects where the programme is current and the parties need to make real-time decisions about EOT entitlement or time impact.
When should TIA not be used?
It is often a poor fit where the project is complete, the relevant update is unreliable, or the issue is really about reconstructing what actually happened over time.
Does TIA automatically prove entitlement to an extension of time?
No. It may support the time analysis, but entitlement still depends on the contract, the facts, notice compliance, and any overlapping delay issues.
How does TIA differ from window analysis?
TIA is generally prospective and event-focused. Window analysis is generally retrospective and period-focused.
Sources
- AACE International, Recommended Practice 29R-03 Forensic Schedule Analysis
- Construction Front, What are the Existing Delay Analysis Methods?
- Construction Front, Window Analysis Method
- Construction Front, Concurrent Delay in Construction
- Construction Front, Extension of Time (EOT) Claims
- Construction Front, Notice of Delay
- Construction Front, Float in Construction Program
- Construction Front, Prolongation Costs
- Construction Front, Time Bar Clauses
- Construction Front, Early Warning Notice
- Construction Front, Contract Administration and Construction Claims Explained
- Construction Front, Liquidated Damages in Construction Contracts
- Construction Front, Variation Request
- Construction Front, What Is a Variation Order?
- Construction Front, Latent Conditions in Construction
- Society of Construction Law, Delay and Disruption Protocol (2nd Edition)
Disclaimer: The articles on this blog are for informational and educational purposes only and do not constitute legal or technical advice. While we strive to provide accurate and up-to-date information on construction law, regulations may vary by jurisdiction, and legal interpretations can change over time.
