Forensic delay analysis: the methods, what each one needs, and how to choose

What forensic delay analysis is and when you need it

Forensic delay analysis, which AACE International calls forensic schedule analysis, is the study of a project’s schedule records after the fact to establish when the completion date moved, which events moved it, and by how much. The word “forensic” means the work is prepared for a dispute, or for a decision that could become one: an extension of time claim, a prolongation cost claim, a liquidated damages defence, or an owner’s review of a contractor’s delay narrative.

A monthly update asks where the project is and what to do next. A forensic analysis asks why the finish moved between two dates and who carries that delay under the contract. The second question depends on the records the first one produced: a baseline, the sequence of updates as they were issued, and a record of what happened on site.

You need one when:

• Submitting an extension of time claim. Most standard forms require the contractor to show that an excusable event delayed completion, not merely some work. That is a critical path question, answered with a method rather than a narrative.
• Assessing a claim. The contract administrator tests the contractor’s analysis on the same records, often with a different method, to see whether the conclusion survives.
• Defending a programme in a dispute. Tribunals look for a recognised method applied to contemporaneous records with its assumptions stated.

Two reference documents shape practice: AACE International’s Recommended Practice 29R-03, Forensic Schedule Analysis, which defines a taxonomy of methods and a protocol for each, and the Society of Construction Law’s Delay and Disruption Protocol (2nd edition, 2017), which sets out principles for extension of time and compensation and describes six methods. This guide uses the AACE numbering; the Protocol’s method names map onto it.

The AACE 29R-03 taxonomy of methods

RP 29R-03 classifies methods by how they treat the schedule, which is why two analysts can both say “windows analysis” and mean different procedures. Three distinctions do the work.

• Observational or modelled. An observational method reads what the schedules already say and changes nothing. A modelled method inserts or removes delay and reschedules to see what the network does.
• Static or dynamic logic (observational methods). Static compares two schedules as fixed pictures; dynamic follows the logic as it changed through the updates.
• Additive or subtractive (modelled methods). Additive inserts delay into a schedule that did not contain it, usually the baseline or an update. Subtractive removes delay from one that did, usually the as-built.

Each combination is a method implementation protocol (MIP), numbered 3.1 to 3.9, which states the source data the method needs, how to validate it, the steps and the known weaknesses.

“Prospective” and “retrospective” describe the direction of the model, not when the analysis is done. An impacted as-planned run after completion is still prospective: it predicts what the delay would have done to the plan. A collapsed as-built starts from what happened and takes the delay out.

As-planned vs as-built (MIP 3.1)

The simplest method, and the one every other method is checked against. Lay the as-built dates over the as-planned dates and read the start, finish and duration variance on each activity, then read those variances along the as-planned critical path in planned order. Where the finish variance grows from one activity to the next, delay was incurred there; where it merely carries, the activity inherited delay from upstream.

There is no reschedule and so no modelling assumption, which is its strength. Its limits:

• It reads the planned critical path, so it says nothing about activities that became critical later.
• Where planned-critical activities overlap rather than hand off, the growth in variance between them is not delay incurred at that activity.
• If the as-planned carries no criticality, because it was never calculated or an import dropped its float, the method gives the overall finish variance and nothing more.
• It attributes nothing to anyone; the cause comes from the record.

Used alone it supports a straightforward claim with few events. Beside a modelled method it is the sanity check: if a collapsed as-built says the owner caused sixty days and the gross variance on the completion milestone is forty, one of the two needs explaining.

Windows analysis: contemporaneous period analysis (MIP 3.3 and 3.4)

Windows analysis, which the SCL Protocol calls time slice analysis when it follows the issued updates, divides the project into consecutive periods and measures the movement of the completion date in each. The windows are bounded by the updates actually issued: a monthly update cycle gives monthly windows. RP 29R-03 is explicit that the update frequency, not the analyst, sets the window width.

What it needs

A baseline and the contemporaneous updates, each with its data date, progress and logic as issued. An analyst who reconstructs updates from diaries is doing a different method (MIP 3.5) and must say so.

How slippage is attributed

1. Anchor the completion date on one milestone present in every update, so each window measures the same thing.
2. Compare the update at the window’s start with the update at its end. The movement of the anchored date is the window’s delay or recovery.
3. Find the critical path activities that slipped, and separate the ones that caused the slip from the ones pushed by it. Thirty activities each slipping thirty days is usually one cause and twenty-nine carriers.
4. Match the causes to the delay events on record and the party responsible for each.
5. Sum the windows. The chain must reconcile to the overall finish variance; that is the check against loss and double counting.

The MIP 3.4 split

Between two updates, work is progressed and the plan is edited, and both move the finish. MIP 3.4 separates them with a half-step: take the start-of-window update, apply only the end-of-window progress (actual dates, remaining durations, percent complete), reschedule at the end-of-window data date, and read the finish. Start to half-step is the progress impact. Half-step to the end-of-window update is the revision impact: logic, durations, scope, constraints.

The split matters because a revision can hide a delay or manufacture one. A contractor who re-sequences to absorb a late instruction has not avoided the delay; the progress half shows it and the revision half shows the mitigation. A finish that slips because durations were increased, with no progress to justify it, is a revision and not an event.

Root causes and the but-for test

A root’s own slip is a heuristic reading. The stronger test is to restore the root to its start-of-window state, reschedule, and see how far the finish moves back: a but-for reschedule per root. The gap between the two figures is informative in itself, because float and parallel paths absorb slip, and a root that looks large can turn out to have moved the finish by nothing.

The modelled methods: impacted as-planned, time impact analysis and collapsed as-built

The modelled methods all work with fragnets. A fragnet is a small piece of network representing one delay event: how long it was, which activities it acted on, and how it connects to them. There are two ways to connect it, and the choice changes the answer.

• Extend the activity. The event added days to the work itself: a prolongation such as rework or a slow approval. The activity’s duration grows by the event’s days.
• Insert a predecessor. The work could not start until the event ended: a disruption such as late access or a missing drawing. A delay activity of the event’s length is inserted as a finish-to-start predecessor, and the activity’s own duration is left alone.

The same distinction governs removal in a subtractive method: a prolongation is removed by shortening the activity, a disruption by pulling it earlier.

Impacted as-planned (MIP 3.6)

Insert the fragnets into the baseline, reschedule, and read the new finish. Prospective and single-base, it is the quickest to run and the easiest to challenge: it ignores everything that actually happened, including the contractor’s own delays, mitigation and acceleration. Events go in in the order they began, rescheduling after each, so each increment is that event’s impact given the ones before it. The SCL Protocol notes that it takes no account of actual progress and cautions against relying on it retrospectively where update records exist.

Time impact analysis (MIP 3.7)

The method most often used to assess an extension of time as the event occurs, and the one the first edition of the SCL Protocol recommended. For each event, take the update in force when it began, reschedule it unimpacted, insert the fragnet, reschedule again, and read the difference. Measuring each event against its own contemporaneous update is what distinguishes it from the impacted as-planned: the update already carries the progress, the contractor’s own slippage and the float consumed so far.

Two consequences. An undated event has no update in force and cannot be analysed this way; measuring it against the baseline instead silently turns the analysis into an impacted as-planned. And when several events are measured against the same update, each consumes the same float on its own, so the sum of the impacts is an upper bound, not the combined impact.

Collapsed as-built (MIP 3.8)

Start from the as-built, remove the delay events, reschedule, and read how much earlier the project would have finished but for them. It is the only method that starts from what happened, and the hardest to do honestly, for one reason: a record of actual dates is not a network. Completed work sits where its actuals put it, and removing a delay from the middle of a finished project moves nothing downstream unless the as-built is first rebuilt as a schedule that can re-flow: each activity given the duration it actually took, the logic kept, the actual dates released so the critical path method can place the work.

The rebuilt model must reproduce the observed as-built finish before any delay is taken out. If the retained logic does not explain the as-built dates, the but-for figure rests on a network that never existed, and the discrepancy is a finding to report. Events are removed most recent first, so each recovery is that event’s contribution given the ones removed before it, and where a baseline exists an extended activity collapses to its planned duration rather than by the event’s nominal days.

Concurrency, apportionment and float ownership

Concurrent delay, in its ordinary sense, is two or more delays from different causes, each of which would have delayed completion on its own, operating in the same period. Every method surfaces it as a window or a step with more than one independent critical driver. None resolves it, because the resolution is contractual.

The analysis can detect concurrency and say where it arises. It can apportion a window’s delay across its concurrent roots by a stated rule: in proportion to each root’s own slip, in proportion to its verified but-for impact, wholly to the dominant cause, or in equal shares. And it can roll the shares up by party and liability class. It cannot choose the rule. The SCL Protocol’s general position is that a contractor’s concurrent delay should not reduce an extension of time otherwise due, while compensation is recoverable only for cost that can be separated from the cost of the contractor’s own delay. Forms and jurisdictions differ; state the rule applied and show the alternatives.

Float ownership is the related question. The Protocol’s default, absent an express term, is that float belongs to neither party, so an extension of time arises only when an event drives total float on the critical path below zero. A windows analysis anchored on the completion milestone applies that test by construction: an event that consumed float shows as off-critical slip with no finish movement, and is reported as such rather than counted.

The data you need, and the traps

Every method is only as good as its source schedules. RP 29R-03 puts source validation before any analysis, and the DCMA 14-point assessment tests much the same things: a dated schedule, complete logic, statusing consistent with its own data date, no retroactive rewriting of what the previous update recorded. Run those checks on every update before quoting a window bounded by it. A failing update is weak evidence; it does not say who delayed the project.

• Contemporaneous updates saved as snapshots. Windows analysis and time impact analysis need each update as issued, with its logic. A tool that advances the data date in place keeps no history. Save each update as a snapshot when its data date moves, or keep the XER files.
• A delay events register. The modelled methods consume events, not narratives: title, start date, duration, affected activities, fragnet mode, responsible party and liability class. Recording them as the project runs, with the notice reference and the days claimed and agreed, is what makes a later analysis possible without re-identifying every delay.
• Calendars. Activity durations are working days on the activity’s calendar; an event recorded by its start and end dates is a calendar span. A fourteen calendar-day event on a five-day calendar is ten working days. Adding fourteen to the duration inserts nearly three weeks of work for a two-week event and overstates the delay. Convert the span onto the calendar before it touches a duration, and print the unit on every figure: contracts count in calendar days, P6 and MS Project report in working days, and the two disagree across every weekend.
• A stable completion anchor. Measure every window on the same milestone. A tail milestone added in a later revision inflates the movement; the latest finish across all activities drifts to whichever activity ends last.
• Re-coded scope. Two updates that share few activity codes compare different works. A window across a re-baseline is an artefact unless the codes are reconciled first.
• Completed and constrained activities. A modelled delay on an activity that is already complete, or pinned by a mandatory date, moves nothing. Zero days from such a step is not evidence of no impact; it is evidence the model could not transmit the delay, and the report must say so.

Choosing a method, and running these methods in GETSEVEN

The SCL Protocol lists the factors: the contract’s requirements, the timing of the analysis, the records available, the value in dispute and proportionality. In practice the records decide.

Whatever the choice, the report should name the MIP, state the units, print the anchor, list the events excluded and why, and reconcile the per-event or per-window figures to the overall finish variance.

Running these methods in GETSEVEN

The Delay Digger module runs the analysis inside the application that holds the schedule. The windows analysis runs over your own saved updates: the application captures a snapshot each time a project’s data date advances, and snapshots can also be loaded from saved baselines, other projects, crash scenarios and uploaded XER or MSPDI files. The Periods tab slices them by snapshot, by a selected pair, or into weekly, 14-day, monthly or quarterly windows, with the MIP 3.4 progress-versus-revision split, root cause clustering, a per-root but-for reschedule and the four apportionment rules above.

The Methods tab runs the other four, as-planned vs as-built, impacted as-planned, time impact analysis and collapsed as-built, over the same snapshots and the project’s delay events register. The register is database-backed and persists with the project, holding each event’s party, liability class, status, notice, claimed and agreed days and fragnet mode. Calendar-span events are converted to working days on the project calendar before they touch a duration, every modelled reschedule runs through the same engine as the Activities view, and each step reports the activities it could not move and why. A computed method run is held for the session rather than written to the database; the register and the snapshots are what persist. Each revision is graded for update quality with checks drawn from the same tests the DCMA Checks module runs (see the DCMA 14-point guide). Mitigation, acceleration and resource effects are not modelled, and day counts use the project default calendar rather than per-activity calendars.

If you have a project with two or more saved updates, book a session and we will run the period analysis on them live.

Questions