Delay analysis methods explained: a complete guide

When a project finishes late, someone has to show which events pushed the completion date, by how much, and who carries the risk for each one. The answer depends heavily on the delay analysis method you choose. This guide walks through every recognised method, what records each one needs, and when each one is the right tool.

Two documents shape how delay analysis is done in North America and beyond. AACE International Recommended Practice 29R-03, Forensic Schedule Analysis, classifies methods by how they work and gives each a method implementation protocol (MIP). The Society of Construction Law (SCL) Delay and Disruption Protocol (2nd edition, 2017) describes six commonly used methods in plainer terms. We reference both below.

How the methods are classified

Before comparing individual methods, it helps to know the four questions AACE uses to sort them:

• Prospective or retrospective? A prospective analysis forecasts the effect of an event while the project is running, usually to support an extension of time request. A retrospective analysis looks back once the delay has happened or the project has finished.
• Observational or modelled? Observational methods compare schedules and records without changing the logic. Modelled methods insert or remove delays in a CPM schedule and let the software calculate the effect.
• Static or dynamic? Static methods compare against one fixed schedule. Dynamic methods use a series of updates, so the critical path can shift over time.
• Additive or subtractive? Additive methods add delay fragnets to a schedule. Subtractive methods remove delays from an as-built schedule.

1. As-planned vs as-built

AACE MIP 3.1 & 3.2Observational · StaticRetrospective

The baseline schedule is compared directly with what actually happened. The analyst identifies the as-built critical path, then measures where and why activities on it started or finished later than planned. MIP 3.1 compares the whole project in one go (gross). MIP 3.2 breaks the comparison into periods.

Best used when: the project is fairly simple, the baseline is reasonable and good as-built records exist, but contemporaneous updates are unreliable.

2. Windows analysis (contemporaneous period analysis)

AACE MIP 3.3 & 3.4Observational · DynamicRetrospective

The project is divided into windows, usually matching the update periods or key milestones. For each window, the analyst compares the update at the start with the update at the end, tracks the critical path, and records how much the forecast completion moved and why. The delay for the whole project is the sum of the windows.

There are two main variants. As-is (MIP 3.3) uses the updates exactly as they were submitted. Split or bifurcated (MIP 3.4) creates an intermediate schedule in each window with progress only, before logic changes, so the analyst can separate delay caused by progress from changes the scheduler made to the logic. The SCL Protocol calls these as-planned vs as-built windows and time slice windows analysis.

Best used when: regular, reasonably accurate schedule updates exist. On most large projects this is the preferred retrospective method.

3. Modified or recreated updates

AACE MIP 3.5Observational · DynamicRetrospective

When contemporaneous updates were never produced, or are too flawed to use, the analyst rebuilds them from daily reports, minutes, photos and other records, then performs a windows analysis on the rebuilt series.

Best used when: a dynamic analysis is needed but the original updates are missing. Expect the opposing side to challenge every reconstruction decision, so document each one.

4. Impacted as-planned

AACE MIP 3.6Modelled · Additive · Single baseProspective or retrospective

Fragnets representing delay events are inserted into the original baseline. The schedule is recalculated, and the movement in the completion date is attributed to those events.

Best used when: the delay occurs early in the project, or the contract requires this approach. Avoid relying on it alone for a completed project.

5. Time impact analysis (TIA)

AACE MIP 3.7Modelled · Additive · Multiple baseProspective or retrospective

A fragnet modelling the delay event is inserted into the most recent accepted schedule update before the event. The schedule is recalculated, and the change in forecast completion is the delay caused by that event. Repeated for each event and update, it becomes a windows TIA.

Best used when: requesting or assessing an extension of time while the project is running. Many contracts and owners specify TIA for this purpose.

6. Collapsed as-built (but-for)

AACE MIP 3.8 & 3.9Modelled · SubtractiveRetrospective

The analyst builds a logic-linked as-built schedule, then removes the delays caused by one party. The resulting “collapsed” completion date shows when the project would have finished but for those delays. MIP 3.8 does this once on the full as-built. MIP 3.9 does it in stages.

Best used when: the baseline or updates are unreliable but detailed as-built records exist.

7. Longest path analysis

SCL ProtocolObservationalRetrospective

The SCL Protocol lists this separately. The analyst traces the as-built longest path backwards from actual completion, then measures delay along that path against the planned durations and dates. It is closely related to the as-planned vs as-built method, with a stronger focus on proving the as-built critical path.

Concurrent delay and pacing

Concurrent delay happens when an employer delay and a contractor delay both affect the critical path over the same period. How it is treated depends on the contract and jurisdiction. Commonly the contractor receives time but not money for the concurrent period. Whichever method you use, the analysis must identify concurrent periods explicitly, or the other side will.

Pacing is when a party deliberately slows non-critical work because the project is already being delayed by someone else. Pacing is not delay in itself, but it needs evidence of a conscious decision made at the time.

How to choose the right method

No method is right for every case. Recommended practice is to choose based on:

• The contract. Some contracts prescribe a method, especially for extension of time requests.
• The records available. A sound baseline, regular updates and good site records open up more options.
• Timing. Prospective requests usually call for TIA. Completed projects usually call for windows analysis or collapsed as-built.
• Value and budget. The cost of the analysis should be proportionate to the amount in dispute.
• The forum. Negotiation, adjudication, arbitration and court each have different expectations for detail and rigour.

Summary of methods