How Schedules Support Delay and Disruption Claims

A delay claim is a claim for additional time — an extension of time (EOT) — on a contract where progress has fallen behind schedule due to events that are the employer's or a third party's responsibility rather than the contractor's. When these claims are made, the schedule stops being just a project management tool and becomes an evidentiary document: the primary technical evidence for how long the delay actually was, what it affected, and whether it falls on the contractual completion date.

Most EOT disputes are lost or settled for less than they're worth not because the delay event didn't occur — it did — but because the schedule evidence isn't good enough to prove the cause, duration, and critical path impact of the delay. This article explains what makes schedule evidence credible and what the accepted methods of delay analysis are.

Why the Baseline Schedule Is the Foundation

Every delay analysis method compares what actually happened against what was supposed to happen. The baseline schedule is the "supposed to happen" reference. If the baseline was submitted but never credibly reflected the contractor's actual plan — if activities were arbitrarily compressed to meet a commercial end date, if logic was missing, if resources were never assigned — then every delay analysis built on that baseline is built on sand.

An owner's legal team or adjudicator will ask: is this baseline a genuine record of the contractor's planned method and sequence, or is it a document that was produced to satisfy a contract clause? If the answer is the latter, the delay analysis derived from it loses credibility. A credible baseline is the single most important investment a contractor can make in protecting their EOT position.

The Three Main Methods of Delay Analysis

1. Impacted As-Planned (Impact Modelling)

This method takes the original baseline schedule and models the delay event into it as a new activity or constraint, then recalculates the schedule to see what impact it has on the completion date. If the unimpacted schedule shows a 10 December completion and the modelled delay pushes it to 18 January, the claimed delay is 39 calendar days.

Impacted as-planned is often used for prospective claims — where you're arguing what a delay event will do before it's fully resolved. It's also commonly used when programme records are poor. Its weakness: it assumes the baseline was achievable and that no other events affected the path. If the project had multiple concurrent delays, impacted as-planned may overstate any single delay's impact.

2. Time Impact Analysis (TIA)

TIA is the most rigorous prospective analysis method. It inserts a fragnet — a small sub-network representing the delay event — into the schedule at the point in time when the delay started, using the schedule as it stood at that point (not the original baseline). The impact is calculated forward from there.

The rigour comes from the use of concurrent updates: you're not using the original baseline to calculate impact, you're using the last approved update before the delay event. This accounts for work already done and any float consumed before the delay, making the analysis more accurate. TIA requires that good schedule update records exist and that updates were regularly submitted, making the discipline of schedule updates far more than an administrative obligation.

3. Windows Analysis (As-Planned vs As-Built Windows)

Windows analysis is a retrospective method used after completion to analyse a project's full delay history. The project period is divided into windows — usually aligned with programme updates — and the critical path is assessed within each window. Delays within each window are attributed to cause (employer risk, contractor risk, concurrent) and their impact on completion is quantified.

This is the method most commonly used in major dispute resolution — arbitration, litigation, or expert determination — because it handles concurrent delays most transparently. The quality of the input data (updates, site records, delay event documentation) directly determines the quality of the analysis output. A project with poor schedule maintenance goes into windows analysis at a significant disadvantage.

What Makes Schedule Evidence Credible in a Dispute

Delay analysis is reviewed by technical experts on both sides and ultimately by tribunals that may not have scheduling backgrounds. The analysis needs to be explainable as well as technically correct. These are the characteristics of credible schedule evidence:

• A baseline that was genuinely planned, not reverse-engineered from the end date
• Regular, consistent programme updates saved and submitted throughout the project
• Contemporaneous records linking delay events to specific schedule activities and actual dates
• A clear methodology statement explaining which analysis method was used and why
• An honest treatment of concurrent delays rather than attribution of all delay to a single cause
• Logic and durations that are defensible — not set to produce a predetermined result

The Practical Implication

The decisions that determine whether a delay claim is recoverable are mostly made during project execution, not after. Did you submit regular schedule updates? Did you notify Owner early when a delay event occurred and reference the critical path impact? Did you maintain contemporaneous records linking specific events to specific schedule activities? Were progress records kept accurately throughout?

Contractors who implement good scheduling discipline throughout execution — not just at the start and end — are in a substantially stronger position when delay issues arise. The value of a properly maintained schedule is most visible at the point where everyone hoped they'd never need it.