Slipcurve›Delay forensics

Forensic delay analysis that argues against its own user

Delay analysis methods, each mapped to its AACE Recommended Practice number, a concurrency screen mapped to the SCL Protocol, and an over-claim column that tells you which of your own days will not survive the other side's analyst.

Why a forensic delay analysis must name its method

Two competent analysts can look at the same job and produce delay figures that differ by months, without either of them being dishonest, because they used different methods. AACE International's Recommended Practice 29R-03 exists to make that explicit: it sets out a taxonomy of forensic schedule analysis techniques, each with its own implementation requirements, advantages and limitations, so that an analysis states which of them it is.

An analysis that does not name its method is not an analysis. It is an assertion, and an extension of time claim built on one is an assertion too. So every output here carries its method, its AACE MIP number, the data date, the baseline it is measured against and the sources it read — on the document, not in a footnote.

The delay analysis methods

As-planned versus as-built
Observational. Compares the planned schedule with what actually happened and identifies the delays that pushed completion. The simplest to explain and the easiest to attack, because it observes rather than models.
Impacted as-planned
Modelled, additive. Inserts each delay event as a fragnet into the as-planned network and measures the movement. Prospective in character even when run retrospectively.
Collapsed as-built
Modelled, subtractive. Removes delay events from the as-built network to establish what the completion date would have been but for them.
Time impact analysis (TIA)
Modelled, event by event, in date order, against the schedule as it stood when each event arose. The method most contracts specify by name.
Windows analysis
Contemporaneous period analysis, often called time slice windows analysis. The schedule is examined window by window, and each window's own movement is measured before events are attributed to it.

The three things that make an analysis defensible

1. Overlap is stated, never summed

Delay events that share a path cannot be added. Events individually claiming nineteen days may move completion by ten, because they overlap on the same chain of activities. An analysis that adds them produces a number the other side will dismantle in an afternoon.

The events individually total 19 days but together move completion only 10. The difference is overlap — they share the same path, so they cannot simply be added.

That sentence is generated from the run rather than written by hand — the one above is the sentence the sample project shipped with this product actually produces, with its own numbers in it. The per-event figures and the combined figure both appear, along with the difference and the reason for it.

2. The over-claim column

A window's own movement is the ceiling on what can be claimed inside it. Days claimed past that ceiling belong in a different window, were absorbed by float, or are not recoverable on this method. Either way they are days the other side's analyst will find.

Windows analysis here prints the over-claim explicitly:

20.5 days claimed beyond the movement of the windows those events fall in. A window's own movement is the ceiling on what can be claimed inside it.

This is a tool telling the person running it that part of their claim is not supported. That is the point. A claim that collapses in cross-examination is worse than a smaller claim that holds, and finding out at the hearing is the expensive way to learn it.

As-planned against as-built, examined window by window, with entitlement accumulating Two chains of four bars on one working-day timeline: an as-planned chain finishing at day 60 and an as-built chain finishing at day 78, eighteen working days later. Four contemporaneous windows are marked on the planned timeline. A table gives each window its own movement, the days claimed inside it, the entitlement that survives, and the over-claim. Window movements are 4, 6, 0 and 8 days, totalling 18. Days claimed are 4, 9, 2.5 and 6, totalling 21.5. Entitlement is the lesser of the two in each window — 4, 6, 0 and 6, totalling 16 — and the over-claim is 5.5 days. Two days of movement were claimed by nobody. WINDOW 1 WINDOW 2 WINDOW 3 WINDOW 4 as-planned as-built +18 d 0 20 40 60 working days WINDOW MOVEMENT CLAIMED ENTITLEMENT OVER-CLAIM window 1 4 d 4 d 4 d — window 2 6 d 9 d 6 d 3 d window 3 0 d 2.5 d 0 d 2.5 d window 4 8 d 6 d 6 d — total 18 d 21.5 d 16 d 5.5 d 2 d of movement nobody claimed · 5.5 d claimed past the ceiling of its own window ENTITLEMENT THAT SURVIVES THE WINDOWS 16 d of the 21.5 claimed
Every column foots by construction: entitlement in a window is the lesser of the days claimed and that window's own movement, and what is left over is printed rather than netted away. Window 3 is the row to look at — an event claimed at 2.5 days inside a window that did not move is entitlement of zero, and the analysis says so before the other side does. Two days of movement went unclaimed in the other direction, which is the same honesty pointed the other way.

3. Concurrency, screened separately

Concurrent delay is where most delay disputes are actually decided, and it is where the two leading frameworks diverge most. The concurrency screen here names both parties' events inside one window and is mapped to the Society of Construction Law Delay and Disruption Protocol as well as to AACE 29R-03, because an international dispute may be argued under either.

Responsibility and entitlement are reported per event as separate columns — whether the event moves completion, whether it sits on the retrospective longest path, whose it is, and what that combination means: excusable and compensable, excusable but non-compensable, or non-excusable. An adverse weather event that moves completion zero days is reported as such even when it was claimed at two and a half.

Weather entitlement, from decades of reanalysis at the site itself

Weather claims turn on two questions: what is normal at this site, and was the delay reasonably foreseeable. Contracts typically allocate a baseline number of adverse-weather days per month from historical data for the project location, and extension of time is available only for days beyond that baseline.

The analysis here reduces daily ERA5 reanalysis at the project's own coordinates into per-month lost-day probability across the weather-sensitivity classes, with each threshold citing the standard it comes from rather than being chosen. The span is a control rather than a constant — twenty years by default and up to forty — and the sample size travels with the answer, because a probability computed off three years is not the same claim as one computed off thirty. Every activity in the schedule is classified and pushed into the risk register as a three-point duration impact rather than as a coin-flip event.

Weather is classified per activity from the site's own history and pushed into the risk register as a three-point duration impact; a claim is not corroborated against a daily record here, and the page says so where the verdict would have been.

A claim that collapses under the contractor's own manpower record is worse than no claim.

Adverse weather days observed against the contract allowance, month by month Six monthly bars of adverse weather days observed — 8, 4, 4, 6, 2 and 5 — against a contract allowance drawn as a stepped line at 5, 5, 4, 3, 2 and 2 days. Three months exceed their allowance, by 3 days each, so 9 days in all stand beyond the monthly allowance. Netting the whole season instead gives 29 observed less 21 allowed, which is 8. The allowance is monthly, so the answer is 9. 0 2 4 6 8 days Jan Feb Mar Apr May Jun BEYOND THE MONTHLY ALLOWANCE 9 days 29 observed − 21 allowed = 8 if you net the season. Monthly, the answer is 9. One of the nine is a day the crew worked through the threshold. Reported, not claimed. observed beyond allowance
The allowance is allocated per month, so a light month banks no credit against a heavy one. Netting the season gives 8 days; doing it month by month gives 9, and the 9 is the one the contract supports. Whether an excusable day is also compensable is a contract term the caller states — it is never inferred from the weather.

Compensability is taken as a contract term the caller states, never inferred from the weather itself — because whether an excusable weather day is also compensable is a question the contract answers, not the sky.

What happens when the inputs are not there

A forensic analysis with missing inputs is the single most dangerous document this product could produce, because it looks identical to one with complete inputs. So the refusals are loud and they are on the page, unprompted:

  • Three activities carry no baseline at all — their variance cannot be computed. Named, counted, and excluded from the variance figures rather than treated as zero variance.
  • No project baseline is named. Stated before any as-planned comparison is read.
  • No site coordinates for the weather analysis returns a basis of none with the reason — and the activity list is rendered without zero expected lost days beside it, because zero lost days and no basis to compute lost days are different claims.

Opened with networking switched off, the weather module renders nine separate notices of this kind and not one zero.

What comes out

Every deliverable carries provenance: the data date and where it came from, the baseline it is measured against, the method and its MIP number, every external feed with its licence and retrieval time — and a printed list of what the document cannot state. A workbook has no code path that filters out a section it could not produce: that section gets a cover-index row reading NOT AVAILABLE and a sheet of its own naming the feed and the remedy, carrying no number at all.

A report that ships four tabs instead of five reads as nothing to report, and a reader has no way to tell that apart from we could not look. In a document that may be put in front of a tribunal, that distinction is the whole of its value.

What this does not do

  • It does not decide your claim. It runs named methods over your data and reports what each one produces, including where they disagree. Selecting the method a contract requires, and arguing entitlement, is expert work.
  • Disruption and productivity-loss quantification — measured mile, baseline productivity analysis and the rest of the disruption family — is not implemented. This is delay analysis, not disruption analysis.
  • No document-set discovery or correspondence mining. The contemporaneous record has to be in the product's registers to be reasoned over; there is no ingestion of an email archive.
  • Weather requires network access and coordinates. With neither, the analysis refuses rather than degrading — which is the correct behaviour and is also a hard dependency, stated as one.
  • The free tier of the open weather endpoint is non-commercial only. The product enforces that limit in its own interface rather than trusting anyone to remember it.

Related

  • Scheduling and schedule risk — the prospective counterpart: simulate the risk before it becomes a claim.
  • Cost, contracts and earned value — change events, their pricing basis, and the exposure netted against the change orders raised from them.
  • BIM, IFC and 4-D coordination — where a delay event of this kind starts: a triaged clash promotes carrying its linked activity and is tested against that activity's total float, so a coordination issue that moved a date arrives already tied to the network.