Time Impact Analysis in Construction: Process, Benefits & Best Practices

A time impact analysis adds a modeled delay event to an accepted CPM schedule and measures how far the projected project completion date moves. That movement becomes the basis for a time extension request.

Most guidance stops at the mechanics, which are the easy part. Time impact analysis submissions fail far more often because of the schedule underneath the modeled event than because of the model itself.

That distinction is where this article spends its time.

What Is Time Impact Analysis in Construction?

Time impact analysis (TIA) is a forward-looking method for quantifying the effect of a delay event on the project completion date. AACE International's Recommended Practice 52R-06 defines it as a prospective technique that inserts a modeled event into an unimpacted schedule to determine the potential impact on the longest path.

Four terms carry the method:

• Unimpacted schedule: The last owner-accepted schedule update statused immediately before the delay occurred, containing no reference to the event in question.
• Fragnet: A small set of activities representing the delay, added to a copy of that schedule.
• Impacted schedule: What the critical path method calculation produces once the fragnet is in place.
• Time impact: The movement in the contractual completion date between the two runs.

The output is a number of days measured against the contract date, and it travels with the change order. That number supports a change order request, a time extension, or an internal project management decision about whether to mitigate a potential delay or absorb it. Where the fragnet lands off the longest path, the honest answer is zero days.

How the Time Impact Analysis Process Works

The process runs in five steps.

1. Select the unimpacted schedule: Use the accepted schedule update statused just before the delay event. A later update already carries the impact, which leaves nothing to compare against.
2. Build the fragnet: Model the event with the fewest activities and relationships that still describe it accurately. Complex delays tempt analysts toward detail that reviewers cannot follow.
3. Insert and recalculate: Add the fragnet to a copy of the original schedule and rerun the critical path method calculation.
4. Measure the movement: Compare the projected finish before and after. The delta is the time impact, expressed in work days or calendar days according to contract requirements.
5. Document and submit: Record the schedule files used, the logic added, and the assumptions made, then submit within the window your contract specifies.

Why the Unimpacted Schedule Decides Whether a Time Impact Analysis Survives Review

RP 52R-06 tells analysts which schedule to use. It says nothing about whether that schedule is sound enough to carry an analysis. This is the gap where most time extension requests quietly die.

A fragnet only moves the project completion date if the surrounding logic carries the impact to the critical path. Four defects break that chain:

None of this is exotic. It is the ordinary condition of most schedules in the construction industry. GAO's Schedule Assessment Guide built ten best practices around these traits, and a schedule that fails them cannot credibly measure anything.

The practical consequence: run quality checks on the unimpacted update before modeling the delay, not after the owner rejects the change order. SmartPM grades every schedule uploaded against 35+ quality metrics, including the DCMA 14-point check, and flags open ends, constraints, and negative float automatically. A D-grade schedule turns a time impact analysis into arithmetic performed on a broken model.

See how SmartPM grades schedule quality before you build a claim. Book a demo.

Prospective or Retrospective? Where Impact Analysis Gets Mislabeled

RP 52R-06 covers prospective TIA, performed while work is ongoing. Retrospective work belongs to RP 29R-03, Forensic Schedule Analysis. A prospective TIA forecasts what an event will do so the parties can settle a time extension before the work is complete. A retrospective analysis reconstructs what occurred using as-built data.

Project managers run into trouble when they file a TIA months after the fact and present it as a forecast. Reviewers and claims practitioners notice. Once actual progress exists for the affected activities, the modeled estimate has to answer to the record, and any gap between the two becomes the other party's argument.

The TIA Half-Life: Why Timing Changes the Potential Delay You Can Prove

A time impact analysis loses validity as the gap between the delay event and its approval grows. RP 52R-06 states this directly: the longer that period runs, the less useful and valid the prospective TIA becomes, until at some point a retrospective forensic analysis is the more appropriate tool. The Society of Construction Law's Delay and Disruption Protocol puts the same idea in its core principles: do not wait and see on the impact of delay events.

Read together, those two sources describe a decay curve. Immediately after an event, the work plan is frozen and the model reflects the contractor's actual position. Ninety days later, crews have been redeployed, work has been performed out of sequence, and the impact has been absorbed into actual data rather than estimated. Two identical submissions filed at different times are not equally persuasive.

Timing is a project controls discipline problem more than a methodology problem. The teams that file in-period are the teams whose schedule update cadence makes in-period analysis possible.

What Time Impact Analysis Cannot Tell You

A TIA quantifies the schedule effect of an event. Entitlement is a separate question, and three parts of it sit outside the method entirely.

Concurrency

RP 52R-06 is direct here: requiring an analysis of concurrent delays as a precondition adds forensic complexity to a process meant to be quick. Concurrent delays get untangled later, under a retrospective method that reads the as built schedule rather than a forecast.

Responsibility

Whether an event was owner caused or contractor caused, and whether the result counts among excusable delays or rises to compensable delay, follows from the contract and construction law. A time extension can be granted with no money attached to it.

Cost

RP 52R-06 separates time from cost deliberately, reasoning that quantifying the days first makes the liquidated damages discussion cleaner.

Naming those limits tends to strengthen a submission. Overclaiming invites a line-by-line audit.

Time Impact Analysis vs. Other Schedule Analysis Methods

A deeper breakdown of each approach is available in this guide to CPM schedule delay analysis methods.

Best Practices for Time Impact Analysis in Project Planning

• Grade the schedule before the delay, not after. Quality problems are cheap to fix in a monthly update and expensive to explain in a claim.
• Keep the fragnet small. Design changes, material shortages, and differing site conditions can usually be modeled in a handful of activities.
• Match the contract. Submission windows, day-counting conventions, and required analysis methodology vary by change order clause. Read the spec first.
• File in-period. Treat the submission deadline in the contract as non negotiable.
• Preserve the files. The unimpacted update, the impacted copy, and the assumption log are the analysis. Without them, project managers are asking reviewers to trust a number.

What Automation Changes About Time Impact Analysis

Cost per analysis governs how often project management teams run one. Brandon Howell, Vice President of Scheduling at Layton Construction, oversees 170 active projects in SmartPM. A windows analysis that traditionally took his team an estimated 40 hours of dedicated effort spread over two weeks now runs in two hours, a 98% reduction.

That shift is what makes in-period analysis realistic. When quantifying delays takes an afternoon rather than a fortnight, teams evaluate every change order as it surfaces instead of batching them into an end-of-project reckoning. Each event gets a time extension request while the record still supports one.

The same speed changes what a team can say when challenged. On one of those projects, a consultant calculated that Layton had failed to start 85% of the activities it committed to since the previous schedule update, and Layton's own analysis agreed. Filtering the critical path in SmartPM let Howell show that only two of those activities were on it, and that owner delays accounted for the misses. The statement was accurate and the conclusion drawn from it was wrong.

Automated construction delay analysis software does not replace the analyst's judgment about which events matter. It removes the manual work that keeps most teams from doing the analysis while it still counts.

Quantify delay impacts in hours instead of weeks. Request a demo.

SmartPM analyzes every schedule update against 35+ quality metrics and tracks delay impacts as they happen. See it on your projects. Book a demo.