Most construction claims fail the analysis stage before they fail the legal stage.
The pattern is consistent. A delay happens. The owner or contractor decides to pursue a claim. An expert is hired. The expert picks a delay analysis method usually whichever one the firm prefers and runs it. Six months later, in deposition or arbitration, opposing counsel asks why that method was chosen for these specific facts. The answer is rarely good.
This is the part of CPM scheduling for construction claims that doesn’t get written about much. The methodology choice. AACE International’s Recommended Practice 29R-03 describes nine forensic schedule analysis methods. The two that show up most often on real claims are Time Impact Analysis (TIA) and Windows Analysis. They produce different answers on the same facts. Choosing the wrong one for the conditions of your project is how a defensible claim becomes a losing one.
What follows is the practical version of that choice. When TIA actually wins. When Windows wins. And how to tell which one you’re sitting on before you commit to either.
The two methods, briefly
Most readers of this article already know what these methods are. For the ones who don’t, the short version:
Time Impact Analysis (TIA) is a prospective or contemporaneous method. It inserts a delay event (a “fragnet”) into a current schedule update at the point in time when the delay occurred, then reruns the CPM calculation to measure the impact on the project completion date. It answers the question: what would the schedule have shown about this delay if we had analyzed it the day it happened?
Windows Analysis (sometimes called Contemporaneous Period Analysis) is a retrospective method. It divides the project into time periods (windows) and analyzes the critical path within each window separately. It compares the schedule at the start of each window to the schedule at the end, identifies what drove the critical path during that window, and assigns delay responsibility based on which events controlled the path during that period.
Both are CPM-based. Both rely on the schedule’s logic and updates. Both can be defensible when applied correctly. They differ in what conditions they handle well and that’s where most claims go wrong.
When TIA wins
TIA is the right method when three conditions are met:
1. The delay event is discrete and identifiable. A specific change order. A specific weather event with documented duration. A specific RFI response that took a specific number of days. TIA works when you can point at the event and say this thing, on this date, with this duration, caused this impact. The fragnet logic depends on it.
2. The schedule was being updated contemporaneously. TIA models what the schedule would have shown at the time of the delay. If the schedule wasn’t being updated regularly, or if the updates that exist are unreliable, the foundation for TIA isn’t there. We see this disqualify TIA on roughly a third of the claims we’re asked to review the schedule updates are too thin or too irregular to support the method.
3. There aren’t multiple concurrent delays competing for the same critical path. TIA struggles when several events are pressing on the schedule at once. The method can be extended to handle concurrency, but the moment you’re modeling three or four overlapping events, the analysis becomes opaque to non-experts. Which matters, because the audience for a delay analysis is usually a judge, an arbitrator, or an opposing-side expert who’s looking for ways to attack the model.
When these conditions hold, TIA is the cleaner method. It’s prospective in its logic, which courts and arbitration panels generally view favorably. It produces a clear cause-and-effect narrative. And it lends itself to expert testimony because the analyst can walk through the fragnet, the impact, and the result step by step.
When Windows wins
Windows Analysis is the right method when the conditions for TIA aren’t met. Specifically:
1. The project had multiple, overlapping delay events. Most large capital projects do. A submittal delay, a procurement delay, a weather event, and a design change can all be active in the same 60-day period. Windows Analysis handles this naturally because it’s not trying to isolate individual events it’s looking at what drove the critical path during each window and apportioning responsibility accordingly.
2. The schedule updates are imperfect but exist. Windows is more forgiving than TIA on data quality. It doesn’t require the same level of contemporaneous schedule integrity because it’s comparing schedule states across periods rather than inserting events into a specific update. This matters on real projects, where schedule updates almost always have gaps.
3. The dispute is about overall project completion rather than a specific event. When the question is “who’s responsible for the project finishing nine months late?” rather than “how much delay did this specific RFI cause?”, Windows is the more defensible method. It traces the critical path through the project’s actual history rather than modeling a hypothetical.
The trade-off is that Windows is harder to explain to non-experts. The analysis produces a series of windows, each with its own critical path determination, and the narrative is necessarily more complex. Expert testimony on Windows analyses takes longer and requires more careful preparation.
How to tell which one you’re sitting on
The choice usually becomes clear from three diagnostic questions.
Was there a single dominant delay event, or were there several? If there’s a clear primary event with discrete impact, TIA is on the table. If the delay was the cumulative result of multiple causes, Windows is probably the move.
What’s the schedule update record like? Pull the .xer files (or whatever format the project used) and look at the update history. Monthly updates with reasonable progress capture? Either method is viable. Sporadic updates, missing months, evidence of re-baselining without documentation? Windows handles imperfect data better; TIA may not be defensible on this record.
Who’s the audience for the analysis? A federal contracting officer reviewing a request for equitable adjustment will read a TIA more easily than a Windows analysis. A judge in commercial litigation, with expert witnesses on both sides, can handle Windows when the case warrants it. The audience matters because the analysis has to land with someone, and complexity that isn’t necessary is complexity that costs you.
This is where having the analysis done by a project controls team that’s seen both methods in real disputes earns its keep. The choice isn’t theoretical. It’s based on the specific facts of the project, the specific quality of the schedule data, and the specific audience the analysis will face.
The most common mistake
The most common mistake we see isn’t choosing the wrong method. It’s choosing a method without analyzing whether the schedule supports it.
A claim arrives at our desk for review. The methodology is documented. The analyst’s logic is laid out. The fragnets or windows are constructed. But nobody has stress-tested the underlying schedule against the methodology requirements. The TIA assumes contemporaneous updates that don’t exist. The Windows analysis assumes baseline integrity that fell apart in month four. The methodology was applied correctly to a schedule that couldn’t support it.
When opposing counsel finds this and they will the entire analysis collapses. Not because the methodology was wrong, but because the schedule wasn’t ready to be analyzed by that methodology.
The fix is to do the schedule readiness assessment first, before committing to a method. Three questions:
Does the baseline schedule exist and is it the one referenced in the contract? If multiple baselines were adopted informally, which one are we calling “the” baseline?
Are the schedule updates contemporaneous, complete, and consistent with the work that actually happened? Spot-check three random updates against project documentation.
Are the constraints, logic, and durations defensible? A schedule loaded with date constraints overriding logic can support neither TIA nor Windows defensibly.
If the answers are clean, you have method choice. If they’re not, the work isn’t picking a method it’s reconstructing the schedule first, then choosing.
What this means for owners
CPM scheduling for construction claims is not a planning exercise. It’s evidence preparation. The schedule that gets built during construction is the schedule that becomes evidence two years later when a delay turns into a claim. Most projects don’t think about this until it’s too late.
The owner’s leverage point is upstream. Setting expectations on the project execution plan that the schedule will be maintained to a forensic standard from day one. Requiring monthly logic checks. Requiring documented baseline change procedures. Requiring schedule narratives. None of this is exotic. It’s just the standard that, if applied early, makes either TIA or Windows viable later.
Without it, the methodology choice becomes a damage-control exercise. Which one of these methods can our schedule even support? That’s the wrong question to be asking when a claim is on the table.
The right question “which method best fits the facts of this dispute?” is only available to projects that prepared the schedule for it.
This is the discipline that Stelic’s dispute resolution practice brings to claims work, both as the analysis team and as advisors to owners who want to position themselves before a claim materializes. On capital projects in the DC-Baltimore corridor and across the Mid-Atlantic, the difference between a defensible claim and a losing one is usually decided long before the analysis starts.
Frequently Asked Questions
When should I use Time Impact Analysis instead of Windows Analysis on a construction claim? TIA fits when the delay is a discrete event with a specific cause and date, the schedule was being updated contemporaneously throughout the project, and there aren’t multiple concurrent delays muddying the critical path. If those conditions don’t all hold, Windows Analysis is usually the more defensible choice.
Can a CPM schedule be analyzed if it wasn’t updated regularly during construction? Sometimes. Windows Analysis handles imperfect data better than TIA, but both methods become harder to defend when the update record has significant gaps. If the schedule wasn’t maintained to a reasonable standard, the first step in a claim is usually a schedule reconstruction which is expensive and reduces the strength of the analysis. Maintaining contemporaneous updates is the cheapest insurance owners can buy on this.
What’s the difference between a baseline schedule and an as-built schedule in a claim? The baseline is the schedule adopted at the start of the project, usually contractually. The as-built is the schedule showing what actually happened. Delay analysis methods compare these two TIA does it by inserting events into the baseline, Windows does it by looking at what controlled the critical path during specific time periods. Both methods require that the baseline and as-built are clearly defined and defensible.
Does the choice of analysis method affect how much delay a claim recovers? Yes, sometimes significantly. The same set of facts can produce different delay durations under different methods, particularly when there are concurrent delays or when float allocation is contested. This is part of why methodology choice gets argued so hard in disputes and why picking the right one for the specific facts matters.
Are TIA and Windows the only delay analysis methods used in construction claims? No. AACE International’s Recommended Practice 29R-03 describes nine forensic schedule analysis methods. TIA and Windows are the two most common in practice. Others including As-Planned vs. As-Built and Collapsed As-Built show up in specific situations, usually when the schedule data doesn’t support TIA or Windows.