Back to Insights

Which delay analysis method should you use? The six SCL options, plainly

Aven-AI InsightsProgramme & Delay7 min read
Project team reviewing architectural drawings and programme documents on a desk.

Citable answer: The SCL Delay and Disruption Protocol (2nd edition, 2017) sets out six retrospective delay analysis methods: impacted as-planned, time impact analysis, time slice windows, as-planned versus as-built windows, retrospective longest path, and collapsed as-built. There is no single correct method — the right choice depends on your records, your programme quality, when you analyse, and what the contract requires.

Delay claims are lost as often on method as on merit. Two competent analysts, given the same project, can reach different completion-delay figures simply because they picked different techniques — and a tribunal that dislikes the method will discount the whole claim. So the question "which method?" is not academic. It decides whether an entitlement stands up. Here is what the six methods are, what each one actually proves, and how the choice is made.

Why there is no longer a "default" method

The first edition of the SCL Protocol (2002) had a clear favourite: time impact analysis, "to be used wherever the circumstances permit." The second edition abandoned that preference. As Fenwick Elliott, Addleshaw Goddard and others noted when the 2nd edition landed, there is now "no longer a preferred delay analysis methodology — instead there are a number of factors which ought to be taken into account when choosing from the 'menu' of various delay methodologies" (Lexology / Fenwick Elliott summary).

That shift matters. It means the method is a reasoned choice you have to justify, not a box you tick. The Protocol lists the six retrospective methods at Section 11; the US equivalent, AACE International's Recommended Practice 29R-03 on Forensic Schedule Analysis, describes nine, classifying each as observational or modelled, static or dynamic (AACE 29R-03 overview). International arbitrations frequently reference both. The practical point for a project team is the same either way: the records you keep during the works decide which methods stay open to you later.

The six methods, and what each one proves

The cleanest way to read the six, following the SCL Protocol, is by two questions: does the method start from the cause (model the delay event and see what it does) or from the effect (look at what actually happened and work back)? And does it rely on the planned programme, the as-built record, or both?

1. Impacted as-planned. You take the baseline programme, insert the delay events as new activities, and let the software recalculate the completion date. It is quick and needs only the baseline plus a view of the events — but it is theoretical. It shows the predicted impact on a plan, not what happened on the ground. HKA's decade-long review of real disputes found it is relied on roughly four times more often by claimants than respondents, precisely because it tends to flatter the party building the model (HKA, A Review of Delay Analysis Methods).

2. Time impact analysis. Also cause-based and modelled, but done on an updated programme at the point each event arises: you impact a live, progressed schedule to measure the event's likely effect on completion. The Protocol recommends it for prospective, contemporaneous assessment while the works proceed. Its weakness is retrospective use — it is effort-heavy and models a predicted effect rather than the actual one. HKA's data shows its retrospective use collapsed after the SCL review committee dropped the preference for it in 2015, falling from around 20% of cases to effectively zero.

3. Time slice windows. An effect-based method: you break the project into windows (usually monthly), take a programme update at each slice, and read the actual critical path as it moved through the job. Done well, it shows where real critical delay was incurred, window by window. It needs reliable, regularly updated programmes — no good updates, no time slice.

4. As-planned versus as-built windows. The workhorse. You compare what was planned against what was actually built, subdivided into periods, and identify the causes of critical delay in each. HKA found it is chosen about half the time, in every region and sector — favoured by tribunals for being fact-based and grounded in the as-built record rather than a model. If your records are good, this is usually the safest choice.

5. Retrospective longest path. You trace the as-built longest path back from actual completion to find the sequence that actually drove the end date, then examine the delays on it. A newer entrant — it was not used at all in HKA's sample before 2016, then appeared once the 2nd edition included it.

6. Collapsed as-built (as-built but-for). You start from the complete as-built programme and remove delay events to see what the completion date would have been without them. It needs a detailed, logic-linked as-built — which is exactly what most projects do not have — so it is used in narrow circumstances.

How the choice is actually made

The Protocol frames the decision around a handful of factors: the terms of the contract (some specify a method), the nature of the causative events, the value and complexity of the dispute, the time and money available for the analysis, and — above all — the records available and their quality. As HKA put it, the choice "depends on many factors, like the nature of the project, contractual requirements, availability and reliability of information."

Two practical rules fall out of that. First, methods split by what they lean on: as-planned versus as-built and time slice need trustworthy, contemporaneous as-built data and programme updates; impacted as-planned and time impact lean on the plan and a logic model. A project with clean monthly updates keeps the fact-based, tribunal-preferred methods open. A project without them is pushed toward the modelled methods that tribunals trust least. Second, timing matters: assess events as they happen, prospectively, and you preserve the contemporaneous record that makes the strongest retrospective methods possible later. The Protocol's core principle is exactly this — deal with delay as the works proceed, not on a "wait and see" basis.

Which is why the real determinant of your delay claim is not the analyst you hire two years later. It is the records your team keeps this month. The old adage attributed to Max Abrahamson holds: a party's best weapon in a delay dispute is "records, records and more records." Walter Lilly & Co Ltd v Mackay [2012] EWHC 1773 (TCC) is the standing reminder — the contractor there succeeded in large part because it kept meticulous contemporaneous records, allowing the Technology and Construction Court to assess entitlement on the facts rather than on assumption (Practical Law case summary).

Where Aven-AI fits

Aven-AI does not run a forensic delay analysis or pick your method for you — that is expert work, and the choice is a legal and commercial judgement. What it does is protect the raw material those methods depend on. It ingests the programme (Primavera P6 or MS Project), reads it against the contract, and watches how the critical path moves as updates come in — so a slip that has become critical is flagged to the right person while it can still be notified, not discovered in a claim two years later. It keeps the contemporaneous trail — what changed, when, and what was known — that decides whether the fact-based methods are even available to you. And when a notice or early-warning obligation is triggered by a programme movement, it drafts the record for a human to check and issue. It flags, it drafts, it warns ahead; every prompt is cited back to the clause and the programme, and nothing is ever sent automatically. The person decides.

Good records do not win a delay claim by themselves. But their absence loses one before an analyst is ever appointed. That is the part worth getting right while the works are live.

This article is general information, not legal advice. It cites its sources so you can verify each point; confirm the current contract wording and the applicable law for your project before relying on any of it.

Related reading

Sources & further reading

  • Society of Construction Law — Delay and Disruption Protocol, 2nd edition (February 2017): full PDF
  • Fenwick Elliott / Lexology — The SCL Delay and Disruption Protocol 2nd Edition: overview
  • HKA (François Michaud) — A statistical review of delay analysis methods used over the last decade: article
  • AACE International — Recommended Practice 29R-03, Forensic Schedule Analysis: sample / table of contents
  • Walter Lilly & Company Ltd v Mackay [2012] EWHC 1773 (TCC): case summary

Ready to put this into practice?

See how Aven-AI flags notice, time-bar, programme and QHSE risks before the window closes.

Request early access