Time Impact Analysis (TIA): Complete Step-by-Step Guide

What Is Time Impact Analysis?

Time Impact Analysis (TIA) is a forensic schedule analysis technique used to demonstrate and quantify the impact of delay events on a construction project's completion date. It is a prospective method — meaning it measures delay impact by inserting a delay event (as a fragnet) into the schedule as it existed at the time the delay occurred, then recalculating the network to determine whether and by how much the project completion date shifted.

TIA is the most widely accepted delay analysis methodology in North American construction. It is recommended by the Association for the Advancement of Cost Engineering (AACE International) in Recommended Practice 29R-03 and is recognized by courts, arbitration panels, and dispute resolution boards as a credible approach to quantifying delay damages.

The core principle is straightforward: if a delay event impacts the critical path, the project completion date moves. If it only impacts a non-critical path with available float, the completion date does not move. TIA demonstrates this relationship quantitatively by comparing the calculated completion date before and after the delay event is inserted into the schedule logic.

When to Use TIA

Time Impact Analysis is appropriate in several scenarios:

Prospective delay claims: When a delay event occurs during project execution and the contractor needs to demonstrate entitlement to a time extension before the project is complete. The TIA shows the anticipated impact on the completion date based on the schedule status at the time of the event.

Concurrent delay assessment: When multiple delay events from different responsible parties overlap in time, TIA helps isolate the individual impact of each event by inserting them separately and measuring the incremental effect on the completion date.

Change order time justification: When a scope change requires additional time, TIA demonstrates exactly how many days the change adds to the critical path by modeling the additional work as a fragnet within the existing schedule logic.

Dispute resolution: When parties disagree about whether a delay impacted the project end date, TIA provides an objective, schedule-based demonstration that courts and arbitrators can evaluate.

Prerequisites for a Valid TIA

A credible Time Impact Analysis requires several foundational elements:

A valid CPM schedule: The analysis must be performed on a schedule that existed at or near the time the delay occurred. The schedule must have reasonable logic, appropriate constraints, and accurate progress updates. A poor-quality schedule produces unreliable TIA results — garbage in, garbage out.

Schedule health verification: Before performing a TIA, validate the schedule using a DCMA 14-point assessment or similar health check. Issues like missing logic, excessive constraints, or unreasonable durations undermine the credibility of any analysis performed on the schedule.

Contemporaneous documentation: The delay event must be supported by project records — RFIs, change orders, daily reports, correspondence, weather records, inspection logs, or other documentation that establishes what happened, when it started, how long it lasted, and which activities it affected.

Clear logic for the fragnet: The delay event must be modeled as activities with logical relationships to the existing schedule. The fragnet must accurately represent the scope, duration, and dependencies of the delay event.

Step-by-Step TIA Methodology

Step 1: Identify the Delay Event

Define the specific event being analyzed. Document what happened, the responsible party, the start date of the delay, and the duration. For example: "Owner-directed design revision to the HVAC system, issued via Change Order #47 on March 15, requiring 28 calendar days of additional engineering before mechanical rough-in could proceed."

Step 2: Select the Appropriate Schedule

Identify the schedule that was current at the time the delay event began. This is typically the most recent accepted schedule update preceding the event. The schedule must reflect actual progress through its data date and must have been accepted by both parties as a reasonable representation of the project status at that time.

Using Float Master, you can open the relevant XER file and immediately verify its data date, progress status, and critical path before beginning the analysis.

Step 3: Verify the Pre-Impact Schedule

Before inserting the delay, verify that the schedule calculates correctly and that the critical path is logical. Run a schedule health assessment to check for issues that could affect the analysis. Confirm the calculated completion date — this becomes your "before" baseline for measuring impact.

Document the critical path and note the total float values on paths near the area where the delay will be inserted. If the affected path already has zero float, any delay to that path will extend the completion date. If the path has positive float, the delay must exceed the available float before it impacts completion.

Step 4: Build the Delay Fragnet

Create activities that represent the delay event. The fragnet should include:

• One or more activities representing the delay duration and any associated work
• Finish-to-Start relationships tying the fragnet to existing activities in the schedule
• Appropriate calendars assigned to the fragnet activities
• Clear activity IDs and names that identify the fragnet as the delay event being analyzed

The relationships between the fragnet and the existing schedule must reflect reality. If the delay prevents mechanical rough-in from starting, tie the fragnet's completion to the start of the mechanical rough-in activity with a Finish-to-Start relationship.

Step 5: Insert the Fragnet and Recalculate

Add the fragnet activities and relationships to the schedule. Recalculate the CPM network with the fragnet in place. The scheduling engine will propagate the delay through the network based on the logic relationships, calculating new early/late dates and float values for all downstream activities.

Step 6: Measure the Impact

Compare the recalculated completion date (with fragnet) to the original completion date (without fragnet). The difference is the time impact of the delay event. If the completion date moved by 28 days, the delay caused 28 days of critical impact. If it moved by only 14 days (because the affected path had 14 days of float), the net critical impact is 14 days.

Float Master's schedule comparison feature makes this measurement straightforward — load the before and after versions and immediately see date shifts on completion milestones and intermediate activities.

Step 7: Document and Present

Prepare a clear presentation of the analysis showing: the pre-impact schedule with its critical path, the delay event description with supporting documentation, the fragnet logic and relationships, the post-impact schedule with the new critical path, and the measured time impact. Include both Gantt chart visuals and tabular data supporting the conclusion.

Common TIA Pitfalls

Using the wrong schedule: The analysis must use the schedule that was current when the delay occurred, not the as-built schedule or a schedule from a later period. Using the wrong schedule produces results that do not reflect the actual critical path at the time of the event.

Ignoring schedule quality: Performing TIA on a schedule with broken logic, excessive constraints, or missing relationships produces unreliable results. Always validate schedule quality first. Float Master's automated DCMA assessment makes this verification quick and objective.

Incorrect fragnet logic: The fragnet must connect to the existing schedule with appropriate relationship types and to the correct activities. Misplaced logic ties can overstate or understate the delay impact. Verify that the fragnet reflects how the delay actually constrained subsequent work.

Ignoring concurrent delays: If multiple delay events occur simultaneously, inserting them all as a single fragnet conflates their individual impacts. Analyze each event separately to determine individual responsibility and combined net effect.

Float ownership disputes: TIA reveals whether a delay consumed float or impacted the critical path. Parties often dispute who "owns" available float. Establish float ownership conventions early in the project through contract language to avoid disputes during analysis.

Tools for Performing TIA

Effective Time Impact Analysis requires tools that can:

• Open and accurately parse the XER schedule files from the relevant project period
• Verify schedule quality through automated health assessments
• Identify the critical path and rank float paths in the pre-impact schedule
• Compare the pre-impact and post-impact schedules to measure date shifts
• Trace driving logic to verify that the delay fragnet connects properly to the network
• Generate clear visual and tabular outputs for presentation

Float Master provides all of these capabilities in a single platform. Its schedule comparison instantly quantifies date impacts, its float path analysis identifies which paths are critical before and after the delay, and its driving logic tracing verifies that fragnet relationships are correctly controlling downstream dates.

TIA vs. Other Delay Analysis Methods

TIA vs. As-Planned vs. As-Built: The as-planned vs. as-built method compares the original plan against what actually happened, but does not isolate individual delay causes. TIA isolates specific events by inserting them into the schedule and measuring their individual impact.

TIA vs. Windows Analysis: Windows analysis divides the project into time periods and analyzes delay within each window. TIA analyzes individual events regardless of time period. Both are accepted methods; TIA is generally preferred when specific events need to be isolated and quantified.

TIA vs. Collapsed As-Built: Collapsed as-built starts with the as-built schedule and removes delays to determine what the completion date would have been without them. TIA works in the opposite direction — starting with the as-planned/updated schedule and adding delays to see their impact. TIA is considered more reliable because it uses schedules that existed at the time rather than retrospective reconstruction.

Conclusion

Time Impact Analysis remains the gold standard for demonstrating construction delay entitlement. Its strength lies in objectivity — it uses the actual CPM schedule from the relevant time period and lets the network calculation engine determine whether a delay event impacts the critical path. When performed on a quality schedule with proper documentation and correctly constructed fragnets, TIA produces results that courts, arbitrators, and opposing parties can evaluate on their merits.

The key requirements are a valid schedule, accurate fragnet logic, and tools that can verify schedule quality, calculate the network, compare versions, and present results clearly. With proper methodology and capable tools, TIA transforms schedule delay disputes from subjective arguments into quantifiable, defensible demonstrations of cause and effect.