Time Impact Analysis (TIA): How It Works, Step by Step

What Is a Time Impact Analysis?

A Time Impact Analysis (TIA) is a prospective or retrospective schedule delay analysis method used to quantify the effect of a specific delay event on a project's completion date. It is widely accepted in construction claims and forensic delay analysis because it isolates the impact of a single delay by inserting a modelled fragment (fragnet) into the baseline or updated schedule. The difference between the schedule’s completion date before and after insertion represents the delay attributable to that event.

TIAs are commonly required under contract specifications (e.g., AIA, EJCDC, FIDIC) and are often the preferred method for evaluating compensable or excusable delays. Because the analysis is event-driven and logic-based, it provides a transparent, reproducible result that can be defended in dispute resolution.

Fragnets: Inserting the Delay Event

The core of a TIA is the fragnet – a small network of activities that models the delay event. A fragnet typically includes:

• Start milestone – when the event begins
• Duration activities – the work or idle time caused by the event
• End milestone – when the event ends
• Logic ties – relationships connecting the fragnet to the existing schedule (e.g., FS, SS, FF)

To insert the fragnet, you need to identify the affected activities in the schedule and attach the fragnet with appropriate logic. For example, if a design change delays the start of concrete pours, the fragnet’s finish milestone would be predecessor to the concrete pour activity. After insertion, the schedule is recalculated, and the new completion date is compared to the original. The delta is the time impact.

When building fragnets, ensure durations are realistic and logic is correct. A common mistake is using overly long durations or missing relationships, which can exaggerate or understate the delay. Always tie the fragnet to the driving path.

Prospective vs. Retrospective TIA

TIAs can be performed at different points in time:

Prospective TIA

Performed before or during the delay event. The analyst uses the current update schedule, inserts the fragnet representing the anticipated delay, and predicts the impact. This is often used for change order impact assessments or time extension requests. Prospective TIAs are proactive and help in negotiating adjustments early.

Retrospective TIA

Performed after the delay event has occurred. The analyst uses the schedule update that was current just before the event, inserts the fragnet with as-built durations, and calculates the delay. This is common in claims and disputes. Retrospective TIAs require careful selection of the “but-for” schedule – the schedule representing the state of the project had the delay not occurred.

Both approaches rely on the same mechanics, but the choice of schedule snapshot and fragnet data differs. For retrospective analysis, you need accurate as-built data and a reliable contemporaneous schedule update.

Step-by-Step TIA Process

1. Identify the delay event – Gather all documentation (RFIs, change orders, weather logs, etc.) and define the event’s start, end, and affected activities.
2. Select the schedule snapshot – For prospective: current update. For retrospective: the last update before the event.
3. Create the fragnet – Build a small network with milestones and durations. Ensure logic ties to the existing schedule are correct.
4. Insert the fragnet – Add the fragnet activities to the schedule and link them to the affected activities. Recalculate the schedule.
5. Record the completion date – Note the new project completion date after insertion.
6. Calculate the delay – Subtract the original completion date (from the snapshot) from the new completion date. This is the time impact.
7. Validate the result – Check that the delay is on the critical path. If not, the fragnet may need adjustment. Also verify that the fragnet’s logic does not create unintended float.

For a robust analysis, run a DCMA 14-point check on your schedule to ensure it’s healthy before inserting fragnets. You can run these checks free in the browser with Project Assure, which also provides EVM/S-curves and baseline-vs-update comparisons – all locally, no upload required.

Common Challenges and Pitfalls

• Incorrect logic ties – If fragnet links are missing or wrong, the delay may not propagate correctly. Always tie to the driving path.
• Using non-driving fragnets – If the fragnet does not affect the critical path, the TIA will show zero delay even if the event caused real impact. Ensure the fragnet is inserted on the longest path.
• Ignoring concurrent delays – TIAs isolate one event. If multiple delays overlap, you must analyse each separately or use a more complex method (e.g., impacted as-planned).
• Over-reliance on default durations – Fragnet durations should be based on actual or expected productivity, not generic estimates.
• Failure to update the schedule regularly – A TIA is only as good as the schedule it uses. Outdated schedules produce unreliable results.

When to Use TIA vs. Other Methods

TIA is best for discrete, well-documented delay events. For global delays or when the schedule has many updates, a collapsed as-built or windows analysis may be more appropriate. However, TIA remains the gold standard for change order impact assessments and is often required by contract.

To ensure your TIA holds up in court or arbitration, maintain a clear audit trail: document the fragnet logic, source data, and schedule snapshots. Use schedule analysis tools to verify your results. For a quick check of your XER file, try Project Assure – it runs DCMA, GAO, and NASA checks instantly in your browser.