Construction Delay Analysis Methods Explained: TIA, Windows, As-Planned vs As-Built and More

When a contractor submits a delay claim, the claim itself is only half the document. The other half is the delay analysis behind it, the method used to show which events caused how much delay. Different methods can produce very different answers from the same project records. Owners who can't tell an impacted as-planned from a windows analysis are at a disadvantage before the negotiation starts.

This guide explains the main delay analysis methods in plain terms, what each one needs, where each tends to favour one side, and what owners should ask for when a claim arrives.

What a delay analysis is trying to answer

Every delay analysis tries to answer the same three questions:

1. Was completion delayed, and by how much?
2. Which events caused that delay? Specifically, which events affected the critical path, not just activities with float.
3. Who was responsible for each event under the contract? The owner, the contractor, or neither, as with some weather events.

The answers decide whether the contractor gets more time, whether they get paid for that time, and whether the owner can recover liquidated or actual damages for late completion.

Prospective versus retrospective analysis

A delay can be analyzed at two points in time.

Prospective analysis happens during the project, when the delay event occurs or shortly after. It forecasts the likely effect of the event on completion using the current schedule. This is the basis for most extension-of-time decisions while work is still under way.

Retrospective analysis happens after the fact, often after completion, using what actually happened. This is the basis for most formal claims, arbitrations and litigation.

The Society of Construction Law's Delay and Disruption Protocol (2nd edition, 2017) strongly favours dealing with delays as they happen. Its Core Principle 4 tells parties not to "wait and see" what impact a delay event will have. For analysis after the event, the Protocol says no single method is preferred. The right choice depends on the contract, the circumstances, the records available and proportionality, and the result has to make common sense against what actually happened.

In practice, owners deal with both. Extension requests during the work should be assessed prospectively, using the update current at the time. If those decisions are made promptly and recorded, there's far less left to fight about retrospectively when the project ends. Many of the largest end-of-job claims we see are a backlog of unresolved delay notices that nobody dealt with when they arrived.

The AACE taxonomy in one picture

AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis, is the most widely used classification of delay methods. It sorts them into two families:

• Observational methods look at the schedules and records as they are, without inserting or removing delays. They observe what happened.
• Modeled methods change a schedule model by adding or subtracting delay events to measure their effect. They simulate what would have happened.

Within each family, methods are further split by whether they use one schedule (static) or a series of updates (dynamic), and whether they add or subtract delays.

The four methods owners see most often

1. As-planned versus as-built

The simplest method. Compare the baseline with what actually happened, activity by activity, and identify where and why the project fell behind. AACE classifies it as observational and static.

Strengths: easy to understand and cheap to prepare. It works reasonably well on simple projects where the critical path never changed.

Weaknesses: it struggles when the critical path shifted during the project, which on building projects it almost always does. It can show that an activity finished late without proving that it drove completion.

2. Impacted as-planned

Take the baseline, insert the delay events (usually only the owner's), and see how far completion moves. AACE classifies it as modeled, additive and single base.

Strengths: quick and visually simple.

Weaknesses: it ignores actual progress and the contractor's own delays. If only owner events are inserted, the result is almost guaranteed to show owner-caused delay. Owners should treat an impacted as-planned claim with caution, especially on a long or troubled project.

3. Time impact analysis and windows analysis

A time impact analysis (TIA) inserts a delay event, modelled as a short network of activities called a fragnet, into the schedule update current at the time the event happened. It then measures the change in forecast completion. Windows analysis applies the same idea across a series of periods ("windows"), using each update in turn. AACE groups these with the modeled, additive methods that use multiple base schedules.

Strengths: it reflects the project as it actually stood when each event happened, including progress and earlier delays. It's widely accepted, and it's the natural method for prospective extension requests.

Weaknesses: it's only as good as the updates. If the monthly updates were poor, late or manipulated, the analysis inherits those problems. It's also more expensive to prepare.

4. Collapsed as-built (but-for)

Start with the as-built schedule, remove the delays caused by one party, and see how much earlier the project would have finished "but for" those delays. AACE classifies it as modeled, subtractive and single simulation.

Strengths: it starts from what actually happened and can work where contemporaneous updates are poor or missing.

Weaknesses: building a reliable as-built logic network after the fact is difficult and involves judgment. Small choices about logic can swing the result significantly.

View the data

Method	Needs	Tends to favour	Owner's first question
As-planned vs as-built	Baseline and as-built dates	Neither, but blunt when paths shift	Did the critical path change?
Impacted as-planned	Baseline plus inserted events	The party whose events are inserted	Were contractor delays included?
TIA / windows	Reliable monthly updates	Whoever kept better updates	Which update was each event put in?
Collapsed as-built	Reconstructed as-built logic	Depends on logic choices	How was the as-built logic built?

Why different methods give different answers

It isn't unusual for the contractor's expert and the owner's expert to analyze the same project and reach opposite conclusions. Usually that comes down to three things:

• Which schedule is used. Measuring an event against the original baseline instead of the current update can make a non-critical event look critical, or the reverse.
• Which events are included. An analysis that inserts only owner delays will only ever find owner delays.
• How the as-built logic is built. Reconstructing the logic after the fact involves choices, and each choice can favour one side.

The defence is not to argue the method in the abstract. It's to test the analysis against the contemporaneous records: daily reports, meeting minutes, RFIs, submittal logs and the monthly updates. An analysis that doesn't match what the records say happened on site is weak, whatever method it uses.

Delay is not the same as disruption

A delay pushes an activity or the completion date later. A disruption makes the work less efficient without necessarily moving any dates. A crew forced to work around another trade, a stop-start sequence or repeated resequencing can all cost productivity even when the schedule holds.

The distinction matters because the evidence is different. Delay is proved with schedule analysis. Disruption is usually proved with productivity data, such as labour hours per unit of work in disrupted periods compared with undisrupted ones. Contractors sometimes bundle the two together in one claim. Owners should ask for them to be separated, with each supported by its own evidence, so the same cost isn't counted twice.

What a good delay submission includes

Whatever method is used, a submission that deserves serious consideration has a few things in common:

• A clear description of each delay event, with dates, and the contract clause relied on.
• Proof that notice was given as the contract requires.
• The schedule used for the analysis, in native format, with an explanation of why that schedule was chosen.
• The fragnets or changes made to model each event, so the owner's team can reproduce the result.
• An account of the contractor's own delays in the same period and how they were treated.
• Steps taken to mitigate the delay.

A submission missing several of these isn't necessarily wrong, but it can't be checked. Asking for the missing pieces in writing is usually the owner's best first response.

What owners should do

1. Name the method in your contract. Many owners require extension requests to be supported by a time impact analysis using the current accepted update. That sets the rules before anyone has a claim to win.
2. Insist on timely notice and prospective analysis. Require delay notices and supporting analysis within a set period after each event, as your contract allows. Settle extensions as you go instead of leaving them all for the end.
3. Protect the updates. Monthly updates are the raw material for every credible method. Review them, keep the native files and make sure logic changes are disclosed.
4. Keep your own records. Owner-side daily logs, photos, decision registers and meeting minutes are what you'll use to test a claim. Records created at the time carry far more weight than reconstructions.
5. Get an independent review of any significant claim. Ask which method was used, which schedule it was applied to, which events were included and how contractor delays were treated. The answers usually show where the analysis is weakest.

The bottom line

A delay claim is an argument built on a schedule. The method chosen, the schedules used and the events included can move the answer by weeks. Owners who set the rules in the contract, keep good updates and test claims against the records negotiate from strength. Owners who wait until the claim arrives are reacting to an analysis someone else designed.

Facing a delay claim or want to set up your next contract properly? Book a 30-minute call with Benjamin R. Consulting.

Sources: AACE International, Recommended Practice 29R-03, Forensic Schedule Analysis (2011); Overview of RP 29R-03 taxonomy and method selection; Fenwick Elliott, The SCL Delay and Disruption Protocol: a second edition; Society of Construction Law, Delay and Disruption Protocol, 2nd edition (2017). This article is general information, not legal advice.