Template
Delay Event Register
Purpose
Log delay events as they arise so cause, effect and evidence are captured contemporaneously — because the claim you can prove is the one whose records you kept at the time.
Who it’s for
Planners and claims teams tracking delay events on a live programme.
When to use it
From the first delay event — maintained every cycle, not reconstructed at the end.
Key areas covered
- Event & date
- Contract mechanism
- Cause & risk party
- Notice & records
- Milestone & critical-path impact
- Status
Related framework Claims & Delay Strategy →
Maintain one row per delay event, updated every cycle. The point is contemporaneous capture — cause, effect and evidence recorded while they are fresh, not assembled after a dispute begins. For each event, record:
- Event reference & date — a unique ID and when the event arose.
- Description — what happened, concisely and factually.
- Contract mechanism — the clause the event is claimed under (variation, instruction, EOT).
- Cause & risk party — Employer-risk or Contractor-risk, on the facts and the contract.
- Notice — whether contractual notice was served, and when.
- Records held — the instruction, RFI, correspondence, progress and site records that evidence it.
- Affected milestone — which contractual milestone is said to be affected.
- Critical-path impact — whether, and in which window, the event affected the driving path.
- Programme model — whether a fragnet has been inserted into the contemporaneous update.
- EOT claimed / assessed — the days claimed and, later, the days assessed.
- Status — open, under assessment, agreed, or rejected — and the resolution.