TIA vs. Window Analysis: When Each Delay Method Wins

The honest answer to “which delay analysis method should I use” depends on two things. When you are asking the question, and how good your schedule updates are. Most of the argument over Time Impact Analysis versus window analysis skips the second one, which is the one that actually decides the claim.

Both methods are legitimate. AACE International recognizes both in Recommended Practice 29R-03, the reference document for forensic schedule analysis. They are not interchangeable. They answer different questions, they are built for different moments in a project’s life, and they fail in different ways when someone competent goes after them.

Here is how to tell them apart, when each one wins, and how each one gets dismantled in a deposition.

What is a Time Impact Analysis (TIA)?

A Time Impact Analysis is a forward-looking, modeled method. You take the schedule update in effect just before a delay event, build a fragnet representing that delay, insert it into the schedule, and reschedule to measure how far the completion date moves. AACE 29R-03 places it among the modeled, additive methods, because you are adding a hypothetical delay into the model rather than observing what happened.

A TIA answers a hypothetical question. Given the plan as it stood at the time, what should this delay have done to the finish date.

It is prospective by design. The classic use is during construction, to price the time impact of a single change order before anyone knows how the rest of the job will unfold. A large share of contracts require a TIA as the format for any time extension request, which is why most owners encounter it long before they ever see a claim.

What is a window analysis?

A window analysis is a backward-looking, observational method. It also goes by contemporaneous period analysis or time-slice analysis. You divide the project into windows, usually defined by the monthly schedule updates or by major milestones, and you track how the critical path actually moved through each window using the contemporaneous updates that were issued at the time. AACE 29R-03 places it in the observational, dynamic family, because you are observing the schedule’s real behavior rather than modeling a hypothetical.

A window analysis answers a factual question. What actually drove the completion date in each period.

It is retrospective by design. You run it after the fact, in a dispute, when you have the as-built record and the trail of updates produced along the way.

When a TIA wins

A TIA is the right tool when:

  • You are evaluating a delay prospectively, during the project, at the moment a change order lands and you need to price its time impact before the outcome is known.
  • The contract requires it as the format for a time extension request, which it frequently does.
  • The delay is a single, well-defined event with a fragnet you can build and defend without contortions.
  • There is no as-built record to observe yet, because the work has not happened. A forward-looking model is the only instrument available before the fact.

In its proper prospective role, a TIA is hard to argue with. The trouble starts when it gets pressed into retrospective service.

When a window analysis wins

A window analysis is the right tool when:

  • The question is retrospective. A dispute is underway and the issue is what actually happened, not what should have.
  • You have reliable contemporaneous updates to build the windows from. This is the load-bearing condition, and we will come back to it.
  • The critical path shifted during construction, which it almost always did. A window analysis captures the shift period by period. A single TIA freezes one moment and assumes the path it found stays put.
  • Concurrency is in play. Because a window analysis shows what was driving the finish in each period, it is the method that actually sorts concurrent delay instead of asserting around it.

When the contemporaneous record is clean, a window analysis is the more defensible method, full stop. It is grounded in what the project did, not in what an analyst modeled it doing.

How each method gets torn apart in deposition

This is the part most explainers skip, and it is the part that decides outcomes.

A TIA gets attacked on four fronts. It is hypothetical, so a retrospective TIA that models a delay and never reconciles against the as-built is the easiest target in forensic scheduling. It stacks badly, because running a series of TIAs and summing them routinely overstates the total, since each fragnet ignores the others and ignores actual progress. The base schedule is a choice, and a base chosen to help the client is a choice the other side will name. And the fragnet itself is built by the analyst, which means it can be built backward from the conclusion. A TIA is only as honest as the person constructing the fragnet, and everyone in the room knows it.

A window analysis gets attacked on its data. If the contemporaneous updates were never statused properly, carried open-ended logic, ran out-of-sequence progress, or hid the real critical path behind constraints, then the windows are built on a CPM model that was never valid to begin with. Window boundaries are also a choice, and boundaries drawn to favor a client invite the same attack as a convenient base schedule. The deepest vulnerability is the simplest. A window analysis depends entirely on data that may not exist. No clean updates, no window analysis. That is the gap that strands owners.

The two methods at a glance

Time Impact AnalysisWindow Analysis
AACE 29R-03 familyModeled, additiveObservational, dynamic
DirectionProspective (forward-looking)Retrospective (backward-looking)
Question answeredWhat should the delay have doneWhat actually drove the finish
Best momentDuring the project, per change orderAfter the fact, in a dispute
RequiresA defensible fragnetReliable contemporaneous updates
Easiest attackIt is hypothetical and analyst-builtThe updates were never valid

The method is downstream of your schedule updates

Here is the point the methodology debate buries. You can run a TIA on almost anything. That is exactly why it is the easier method to attack. A window analysis is impossible without disciplined contemporaneous updates, which is exactly why it is the stronger method when the data exists.

So the variable that decides which method you get to use, and how well it survives scrutiny, is not chosen in litigation. It is the quality of the schedule updates produced during construction, work that happens months or years before anyone says the word claim.

Owners who enforce clean monthly updates get to choose the stronger method later. Owners who accept updates that do not tie out are stuck with whatever the other side’s expert builds, which is usually a TIA shaped to a number.

What this means for an owner before there is a claim

The forensic method is decided during the project, not during the dispute. A few habits keep your options open:

  • Enforce update discipline every month. Statused progress, resolved out-of-sequence work, no open-ended logic, justified constraints. The same schedule hygiene that produces a valid critical path is what makes a window analysis possible later.
  • Read TIA-based time extension requests as arguments, not facts. The fragnet was built by the contractor to reach a conclusion. Review the logic before you grant the time.
  • Preserve the updates. The contemporaneous record is the asset that lets you run the more defensible analysis when it counts. Lose it and you have given up the better method before the fight begins.

Frequently asked questions

What is the difference between a TIA and a window analysis? A TIA is a prospective model. It inserts a hypothetical delay into the schedule and measures the projected impact on the finish. A window analysis is a retrospective observation. It tracks how the critical path actually moved through successive periods using the contemporaneous updates. One asks what should have happened. The other asks what did.

Is a Time Impact Analysis accepted in disputes? Yes, particularly in its prospective role for change order time extensions. Its weight drops sharply when it is used retrospectively and never reconciled against the as-built record, which is its most common forensic weakness.

What is contemporaneous period analysis? It is another name for window analysis, sometimes also called time-slice analysis. The project is divided into windows and the critical path movement is observed within each one using the schedule updates that existed at the time.

Which delay analysis method is most defensible? The one supported by your contemporaneous data. When the monthly updates are clean and valid, a window analysis is generally the more defensible method because it reflects what the project actually did. When the updates are unreliable, you may be left with a TIA by default.

Does AACE 29R-03 recommend one method over the others? No. It describes a range of methods and the conditions each one fits. The method should match the question being asked and the quality of the available schedule data, not the result a party is hoping to reach.