Every delay analysis method answers the same question — how many days did this event add to the project finish? — but they answer it differently, rely on different evidence, and hold up differently under cross-examination. The best method for a given claim is the one your records actually support.
The four main methods
Time Impact Analysis (TIA)
Inserts a delay event into the schedule at the exact point it occurred and measures the forward impact on the finish date. Run prospectively (before the event) or retrospectively.
- Widely accepted by courts and adjudicators
- Contemporaneous when run as-you-go
- Shows exact critical-path impact of each event
- Requires a well-maintained, logic-intact baseline
- Complex on multi-event claims
As-Planned vs As-Built
Overlays what the schedule said would happen against what actually happened, measuring the gap. Simple to explain; less rigorous about causation.
- Easy to present to a non-technical audience
- Requires only the baseline and a good as-built record
- Doesn't account for concurrent delays well
- Can't isolate which party caused each slip
- Challenged on critical-path impact
Window Delay Analysis (WDA)
Divides the project into time windows and analyses the critical path and delay cause within each. Handles concurrent delays more cleanly than simpler methods.
- Handles concurrent and interacting delays
- Shows delay by period — clear for multi-party claims
- Respected by most adjudicators
- Data-intensive — requires contemporaneous updates for each window
- Time-consuming to prepare
Collapsed As-Built
Works backwards from the as-built schedule, removing the delay events to compute what the finish date would have been without them.
- Useful when no contemporaneous TIA was run
- Gives a clear "but for" comparison
- Highly susceptible to challenge — conclusions depend on subjective choices
- Rarely accepted as primary method
Evidence is the real constraint
The method you choose is less important than the evidence you have. A TIA run with a corrupted baseline and no contemporaneous records is weaker than a well-evidenced As-Planned vs As-Built. The practical question isn't "which method is most sophisticated?" — it's "which method can my records actually support?"
Handling concurrent delays
Concurrent delay — where owner-caused and contractor-caused delays overlap — is the most contested area in most claims. The method that handles it best is Window Delay Analysis, because it identifies the dominant delay in each time period. TIA can also handle it, but requires careful event sequencing. As-Planned vs As-Built handles it poorly and is regularly challenged on this basis.
The question isn't just "who caused it?" — it's "who would have controlled the finish date in that specific window even without the other party's delay?"
How AI changes the analysis
The bottleneck in delay analysis has always been data preparation — pulling the as-built record together, verifying progress against claims, sequencing events. OPTEAM eliminates most of that bottleneck by building the contemporaneous record automatically: every field update is timestamped, attributed and tied to the activity it affects. By the time a claim needs analysis, the data is already clean.
- TIA is the gold standard — most accepted, but requires a sound baseline and contemporaneous records.
- Window Delay Analysis handles concurrent delays best; use it on complex multi-party claims.
- As-Planned vs As-Built is simple to present but weak on causation and concurrency.
- Collapsed As-Built should only corroborate another method — not lead a claim.
- The method you choose is less important than the evidence you have to support it.
Build the as-built record as the project runs.
OPTEAM timestamps every update so your delay analysis has contemporaneous evidence — not reconstructed narrative.