Time Impact Analysis, Step by Step

A time impact analysis (TIA) answers one question: if this event had been in the schedule, when would the project finish? You take the most recent accepted update, insert a small network of activities that models the event, recalculate, and compare the finish date before and after. This post walks through the steps, works a small example by hand, and covers the places TIAs usually fall apart in review.

This is general information about scheduling practice, not legal advice. Contracts vary on how time extensions are requested and evaluated, so read yours and talk to counsel when real money is involved.

What a TIA is, and what it isn't

A TIA is a prospective analysis. It is meant to be done close to the time of the event, using the schedule as it stood just before the event happened. AACE International covers the method in Recommended Practice 52R-06, and many specifications require something like it for any request for a time extension.

It is not a forensic reconstruction after the fact. Using a TIA to look back over two years of a job is a different exercise with different risks, covered in As-Planned, As-Built, and Windows: Forensic Schedule Analysis Methods. It also isn't a judgment on whether the delay is excusable or compensable. A TIA measures time. Entitlement is a separate question; see Excusable, Compensable, and Concurrent Delay.

The steps

1. Identify the event and its date: the owner directive, the differing site condition, the late RFI response.
2. Select the last accepted schedule update with a data date before the event started.
3. Confirm that update is clean: progress is current, no open ends that matter, no constraints hiding the critical path.
4. Build the fragnet, the small set of activities and logic that represents the event.
5. Insert the fragnet into a copy of the update and tie it to the existing work it affects.
6. Recalculate and compare the forecast finish (and any contract milestones) with and without the fragnet.
7. Write it up: what you inserted, why each duration and tie is what it is, and what changed.

The fragnet is where most of the effort and most of the arguments live. There's a whole post on it: Fragnets: What They Are and How to Write One.

Step 2 matters more than people think

The update you pick sets the starting conditions. If you use an update from three months before the event, you are measuring the event against a plan that had already moved. If you use one from after the event, the delay may already be baked into the progress, and you'll double count or undercount.

The usual rule is the last update with a data date before the event began. If the event started on March 18 and you have accepted updates with data dates of February 28 and March 31, use February 28. Some teams status the February update forward to the event date first, which is reasonable if the contract allows it and you document it.

A worked example

Here is a stripped-down update on a small building. The data date is day 0. Durations are remaining working days. The convention is 0-based: the first activity starts at ES = 0, EF = ES + duration, and a successor's ES equals its predecessor's EF for finish-to-start with no lag.

Forward and backward pass:

ID  Dur  ES  EF  LS  LF  TF
A    6    0   6   0   6   0
B   15    6  21   6  21   0
C    8    6  14  13  21   7
D   10   21  31  29  39   8
E   18   21  39  21  39   0
F   12   39  51  39  51   0

Project finish is day 51. The critical path is A, B, E, F. Slab on grade has 7 days of total float, and all 7 are free float too, since E's ES of 21 minus C's EF of 14 is 7. Roofing has 8.

The event

On day 0, the owner issues a directive adding underslab conduit for new equipment. The slab drawings have to be revised and reissued before the conduit can go in, and the slab can't be poured until the conduit is in. The fragnet:

Insert it, so C now has H as its predecessor in addition to A, and recalculate:

ID  Dur  ES  EF
G    9    0   9
H    4    9  13   (ES = max(EF of A = 6, EF of G = 9))
C    8   13  21
E   18   21  39   (ES = max(EF of B = 21, EF of C = 21))
F   12   39  51

The finish doesn't move. The slab now starts 7 days later than before, which is exactly its float. The slab is now critical, with zero float, but the project still finishes on day 51. The time impact is zero days.

That is a legitimate result, and it's worth saying plainly in the write-up. The event consumed float. Whether consuming float entitles anyone to anything depends on the contract's float language, which is its own topic: Who Owns the Float?.

Same event, longer redesign

Now suppose the redesign takes 14 days instead of 9.

ID  Dur  ES  EF
G   14    0  14
H    4   14  18
C    8   18  26
E   18   26  44   (ES = max(21, 26))
F   12   44  56

The finish moves from 51 to 56: a 5-day impact. You can check it without the full pass. The slab now starts at 18 instead of 6, so 12 days later. It had 7 days of float. 12 minus 7 is 5.

That quick check is worth doing on every TIA. If the recalculated delay doesn't roughly match "how late the impacted activity got, minus its float," something else in the network moved, and you need to know what before anyone else finds it.

Ties and durations are the whole argument

Reviewers rarely dispute the arithmetic. They dispute the inputs.

• Durations. Where did 14 days for the redesign come from? A letter from the architect giving a reissue date is better than an estimate. An estimate with a basis is better than a number.
• Start tie. Does G start at the data date, or at the date the directive was actually received? If those differ, use the real date and document it.
• Finish ties. Is H really a predecessor of the whole slab, or only of one pour? If the slab is poured in three placements and only the east placement has new conduit, tying H to the whole slab overstates the delay. Split the slab activity, or tie to the affected placement only.
• Mitigation. If the contractor could reasonably have resequenced the pours to keep working, a reviewer will ask why the fragnet doesn't show it.

Common ways a TIA fails review

• The fragnet is tied into a schedule that already has a constraint holding the finish date, so recalculation shows no movement no matter what you insert.
• The update used has stale progress, so activities that were actually complete are still driving.
• The fragnet includes contractor-caused work mixed in with owner-caused work, which muddies the result.
• Activity durations in the fragnet are padded, or include float of their own.
• The comparison is made against the original baseline instead of the update, which mixes the event's impact with every other slip since the baseline.
• Several events are analyzed separately against the same update, and the impacts are added together. Events that overlap in time can share critical path days, and the sum overstates the delay. Insert them together, or in chronological order, one after another.

That last one is the most common. If two owner changes both push the same slab, running them separately might show 5 days each, while inserting both shows 6 total. The combined run is the honest number.

Writing it up

Keep the narrative short and checkable. A reviewer should be able to rebuild your result from the document.

• The event, with dates and the source documents (directive, RFI, letter).
• The update used, its data date, and why that one.
• A table of fragnet activities with durations, logic, and the basis for each duration.
• Before and after forecast dates for project completion and each affected contract milestone.
• The critical path before and after, in a sentence each.
• Any mitigation considered, and why it was or wasn't modeled.
• The native schedule files, both versions.

If your tool lets you run the fragnet as a what-if copy without touching the live update, do that. In schedule.construction, what-if scenarios stay separate from the live schedule, and Claim Digger compares the scenario against the update activity by activity, which is roughly the table a reviewer will want to see.

Key takeaways

• A TIA inserts a fragnet into the last accepted update before the event and measures the change in forecast finish.
• Zero days of impact is a real and common result when the event only consumes float.
• Sanity-check every result: delay should roughly equal how late the impacted activity got minus its float.
• Analyze overlapping events together, not separately and summed.
• The inputs, especially durations and ties, are what get challenged. Document the basis for each one.