Delay
Delay: principles and proof
Delay analysis is the disciplined reconstruction or forecast of how identified events affected contractual milestones or completion. It does not begin by choosing software. It begins by defining the question, reading the contract and testing the project record.
A sound analysis shows more than coincidence. Event A happened and completion B was late; that alone proves nothing. The analyst has to identify the work that controlled completion at the relevant time, show how the event affected that work, consider other causes, and explain the amount of delay attributed to each.
The last question in any delay analysis, whether an event falls within a contractual ground for time, money or both, usually belongs to the contract administrator, the tribunal or the lawyers. A delay expert who quietly decides disputed legal responsibility and then colours a programme to match has stopped giving evidence and started making an argument.
- Critical path: calculated and factualThe path a tribunal cares about is the one that actually controlled the work, not the one the software coloured red.
- Float: ownership, use and proofWho owns float, what the contract can do about it, and why the question is really about who reaches the completion date first.
- Concurrent delay: four regions, no universal ruleThe most argued and least agreed concept in the field, handled jurisdiction by jurisdiction.
- The prevention principleA rule that operates through the contract, not a solvent for every notice failure.
- Delay analysis methodsThe eight families, what each assumes and the records each needs.
- Records field guideEverything above is unprovable without this.
The five-part causal test
For each event, build a card that answers five things.
- Cause. The instruction, condition, failure or occurrence, tied to source evidence.
- Contract. The clause, the notice given, and the claimed risk allocation.
- Mechanism. How the event altered access, design, sequence, duration, resources or logic.
- Time effect. The affected activity or path, and the quantified effect on the milestone.
- Alternatives. Contractor delay, weather, supply, pacing, mitigation and every other plausible cause.
Responsibility is not embedded in the schedule. A fragnet can model an instruction, but it cannot decide whether that instruction was a compensable change or whether the notice was valid.
Where the record comes in
Every mechanism on this page turns on evidence: what happened, what was known and when. A record built as the job happens is worth more than any argument assembled afterwards. Construction Metric keeps that record automatically, from the messages, photographs and voice notes a site team already sends.
Built by AI Metric
The analysis on this site is only as fast as the evidence behind it. AI Metric builds bespoke systems for consultancies, contractors and claims teams: document and correspondence triage, event registers assembled from the project record, programme and cost reconciliation, and drafting support that always cites the document it came from. Built for review by your own experts, never to replace their judgement.
General explanation of how contract mechanisms, analysis methods and legal principles generally work. It is not legal or contractual advice, not an opinion on any project, and no standard-form contract wording is reproduced anywhere on this site. Standard forms are routinely amended, so every default described here, including every time period, can be different on your project. Your executed contract, as amended, and the governing law and forum always control. Deadlines may already be running: if an event has occurred, preserve your position and take qualified advice.