Definitive Guide

Time Impact Analysis: The Definitive Guide

Time Impact Analysis (TIA) is the gold standard for forensic delay analysis in construction. This guide covers every aspect of TIA methodology — from fragnet construction to window definition, prospective vs retrospective approaches, concurrent delay identification, and common pitfalls to avoid.

By Constroma Team·35 min read

What Is Time Impact Analysis?

Time Impact Analysis (TIA) is a forensic schedule analysis method classified by AACE International as a “modelled, additive” technique. It evaluates the schedule impact of each delay event by inserting a fragnet (fragment network) into the CPM schedule at the point in time when the delay occurred, then recalculating the schedule to measure the change in the project completion date.

TIA is widely considered the most rigorous single-event analysis method. When performed within analysis windows (the MIP 3.7 methodology), it becomes the most defensible approach available for construction delay disputes.

The TIA Process Step by Step

Step 1: Establish the Base Schedule

Select the appropriate base schedule — the schedule that represents the project plan at the time the delay event occurred. For prospective TIA, this is the current schedule at the time of the delay. For retrospective TIA, this is the schedule update immediately preceding the delay event.

The base schedule must have clean CPM logic: no open-ended activities, no negative float (unless intentional), and calendars that reflect actual working patterns.

Step 2: Record the Pre-Delay Completion Date

Run CPM on the base schedule and record the project completion date (or milestone dates). This is your “before” measurement — the completion date before the delay event is introduced.

Step 3: Construct the Delay Fragnet

A fragnet is a set of activities and relationships that model the delay event. Construction rules:

Model the event, not the outcome:The fragnet should represent what actually happened (e.g., “Redesign structural foundations — 15 days”), not the desired result (e.g., “15-day delay to foundations”).

Choose appropriate tie-in points: Connect the fragnet to the schedule activities that were actually affected. Use the correct relationship types (FS, SS, FF, SF) with appropriate lag values.

Use realistic durations: Base durations on contemporaneous records — daily reports, correspondence, and actual progress data.

Assign correct calendars: Ensure fragnet activities use calendars that match the actual working pattern during the delay period.

Step 4: Insert and Recalculate

Insert the fragnet into the base schedule with the appropriate logical ties. Run CPM forward and backward pass calculations. The engine determines the new critical path and completion date.

Step 5: Measure the Impact

The delay impact is the difference between the completion date after fragnet insertion and the completion date before. If the completion date did not change, the delay event consumed float but did not impact the critical path.

Step 6: Repeat for All Events

Process all delay events chronologically. Each event is inserted into the schedule that already includes all prior events, building up the cumulative delay picture.

Prospective vs Retrospective TIA

Prospective TIA is performed at the time of the delay, looking forward. It uses the current schedule to predict the impact on the completion date. This approach is useful for real-time project management but may not account for future events that change the critical path.

Retrospective TIA is performed after the fact using historical schedule data. It is more common in dispute resolution because it uses actual data rather than projections. When combined with the windows approach (MIP 3.7), retrospective TIA provides the most complete and defensible analysis.

Identifying Concurrent Delay

TIA naturally identifies concurrent delay when multiple fragnets inserted within the same time period both affect the critical path. If two delay events — one caused by the employer and one by the contractor — both independently extend the completion date during the same window, the delays are concurrent.

Common Errors to Avoid

Wrong base schedule: Using a schedule that was not current at the time of the delay event, distorting the analysis context.

Outcome-driven fragnets: Creating fragnets designed to produce a specific result rather than modeling the actual event.

Incorrect tie-in points: Connecting fragnets to the wrong activities, creating artificial critical path impacts.

Ignoring calendars: Not assigning appropriate calendars to fragnet activities, leading to incorrect duration calculations.

Non-chronological processing: Inserting delay events out of order, which can produce different results than chronological processing.

Automate Your TIA with Constroma

Build fragnets, define windows, and run TIA automatically.

Start Free Trial

Frequently Asked Questions

What is the difference between prospective and retrospective TIA?
Prospective TIA is performed at the time of the delay event, using the current schedule to predict the impact on completion. Retrospective TIA is performed after the fact, using actual schedule data to determine the historical impact. Retrospective TIA (especially within analysis windows — MIP 3.7) is considered more rigorous because it uses real data rather than projections.
How do I construct a delay fragnet?
A fragnet should model the actual delay event, not the desired result. Start by identifying the activities affected by the delay. Create new activities representing the delay work or waiting period. Add relationships connecting fragnet activities to the existing schedule at the points where the delay actually occurred. Use realistic durations based on contemporaneous records.
What if a delay event does not affect the critical path?
If inserting a delay fragnet does not change the project completion date, the delay consumed float but did not impact the critical path. The delay is still documented and may become relevant if subsequent delays shift the critical path to the affected activities. Float consumption should be tracked as it affects the scheduling flexibility for future events.
How do you define analysis windows for MIP 3.7?
Analysis windows are typically aligned with schedule update periods — each window spans from one schedule update to the next. If schedule updates are monthly, windows are monthly. Some analysts use delay event dates as window boundaries. The key requirement is that each window is short enough to capture the schedule context at the time each delay occurred.
What are common errors in TIA?
Common errors include: using the wrong base schedule (not the one current at the time of the delay), creating fragnets that model desired outcomes rather than actual events, choosing inappropriate tie-in points, not accounting for calendar differences between fragnet and schedule activities, and failing to process delay events in chronological order.

Related Guides

The Complete Guide to Forensic Schedule Analysis

Overview of all forensic scheduling methods and standards.

Delay Analysis Methods Compared

Side-by-side comparison of TIA, Windows Analysis, and other methods.