The Delay Notice Was Sent. Where Is the Evidence?
A delay notice is stronger when it is connected to contemporaneous instructions, programme versions, site records, photos and a clear cause-and-effect account of the affected work.
The short answer
A delay notice is stronger when the project can connect it to contemporaneous evidence showing what happened, when it happened, which work was affected and how the event changed the planned sequence. The notice itself records communication; substantiation comes from the chain of instructions, programme versions, daily reports, photos, access records, progress evidence and decisions that explain cause and effect.
The control objective is not to manufacture a claim file after the event. It is to preserve reliable project records as normal operations occur so commercial teams can later assemble an accurate account without reconstructing history from memory.
A project example
A contractor issues a notice stating that late access to a plantroom is delaying installation. Months later, the event becomes commercially significant. The notice exists, but the supporting record is scattered. The planner has several programme updates with no clear explanation of the logic change. Site diaries mention access problems but use different area names. Photos are stored by date without package references. An instruction email sits in one engineer's mailbox, and labour records show hours moved to another zone.
Each record is useful, yet the story is difficult to prove because the project did not connect them when the event was live. The team now spends days recreating a chronology and debating which programme version should be used.
Delay evidence is therefore part of the same programme-to-site control chain. Good operational records support both immediate planning decisions and later commercial substantiation.
Start with the event, not the claim narrative
At the time of disruption, record the event in neutral operational terms. What changed? When was it first known? Which location, package or activity was affected? What instruction, condition or dependency is involved? Who owns the next action? Avoid forcing the site team to decide entitlement language that may require later contractual analysis.
A stable event identity can then connect different records without demanding that every system use the same document. The instruction, notice, daily report, photograph and programme note can each retain its purpose while sharing the event reference.
This creates a chronology that is easier to verify and reduces the risk of retrospective narrative replacing contemporaneous fact.
Preserve programme versions and assumptions
Delay analysis depends heavily on programme context. The project should retain controlled programme versions, update dates, logic changes, progress status dates and relevant planning assumptions. Overwriting a working schedule may make current planning easier but weakens the historical record.
When an event affects near-term work, record which activities or milestones were considered exposed and what mitigation was attempted. If the team resequences work, explain why. A later programme update should not make it appear that the disrupted sequence never existed.
The same discipline improves day-to-day control. Management can distinguish genuine recovery from a revised plan that simply moved the target.
Make daily records specific enough to connect
A useful daily report identifies location, work package, crew or subcontractor, significant progress, constraints, instructions and unusual conditions. Generic entries such as “access issue” or “waiting for information” are difficult to relate to a particular event later.
Specificity does not require long narratives. “Level 8 east plantroom unavailable 08:00–13:30; duct crew redeployed to Level 7; access released after client inspection” is far more useful than a paragraph of general commentary. Where possible, connect the entry to the relevant event or instruction.
Consistency of location and package naming also matters. Stable project structures make separate records easier to reconcile.
Use photos as evidence with context
Photos can be powerful contemporaneous evidence, but a folder of images is not automatically a usable record. Important photos should have date, location, subject and, where relevant, the event or work package they support. Preserve original files and avoid relying solely on screenshots embedded in presentations.
A photo should complement, not replace, the written record. It can show blocked access, incomplete predecessor work or site conditions, but it may not show why the condition occurred or which activity it affected.
The strongest evidence chain uses several independent records that agree on the same event and timing.
Connect instructions and notices to operational consequence
An instruction may be commercially important even before its final valuation is known. Link it to the affected package and programme activity so the project can record operational consequence while facts are fresh. The planning team can then assess sequence and mitigation, while commercial teams preserve the communication and entitlement process.
This also prevents a common gap: the notice says one thing, the programme report says another, and the site diary never names the event. Shared event references help each discipline maintain its own record without creating competing stories.
A project-centric ERP such as Saturn can help maintain common project, package, cost and operational context around those records. It does not determine contractual entitlement or replace professional delay analysis; it supports traceability between the underlying project facts.
Record mitigation and response, not only impact
A credible event record should show what the project did in response. Did the team resequence work, move labour, accelerate another area, request alternative access or change a delivery? When was the mitigation decision made, and what was the result?
Mitigation records matter operationally because they improve planning. They also prevent the event history from becoming one-sided. The project can explain both the disruption and the actions taken to reduce its consequence.
For resource changes, the linked record may include why shared plant priority was reallocated or why labour was moved to another workface. This creates a more complete cause-and-effect chain.
Close the factual record while memories are fresh
When the immediate disruption ends, close the operational event even if the commercial assessment remains open. Confirm the actual dates, affected locations, work undertaken, mitigation, outstanding consequences and the documents that support the chronology. This prevents a temporary site issue from remaining indefinitely as an ambiguous open item.
Factual closeout is especially useful when personnel change. Months later, a new commercial manager or planner should be able to understand the event from the controlled record rather than locate the original supervisor and reconstruct the sequence from memory. The commercial position may continue to develop, but the underlying facts should become more stable, not less.
Five practical controls
1. Create a stable event reference when a material disruption arises. Keep the initial record factual and neutral.
2. Preserve controlled programme versions. Do not let current planning overwrite the historical logic needed to understand change.
3. Use consistent package and location references in daily records. Small discipline now saves large reconstruction effort later.
4. Attach context to important photos and instructions. Date, location and affected work are essential.
5. Record mitigation decisions and outcomes. The project history should show response as well as disruption.
The controls should fit normal project operations. If evidence capture feels like a separate claims exercise, teams are less likely to maintain it consistently.
What management should measure
Useful indicators include:
- material delay events without a linked programme activity or location;
- notices without supporting contemporaneous records;
- programme updates that move milestones without a recorded reason;
- daily reports using unstructured or inconsistent location names;
- significant instructions not yet assessed for operational impact;
- delay events with no recorded mitigation action or owner;
- age of open events awaiting factual closeout.
These measures do not decide entitlement. They reveal whether the project is preserving enough evidence to manage and later explain its own history.
Frequently asked questions
Is sending a delay notice enough to protect the record?
No. The notice is an important communication, but substantiation usually depends on the underlying facts and contract requirements. Preserve contemporaneous records that show the event, affected work, timing, programme context and response.
Should site teams write claims language in daily reports?
Usually the safer operational approach is to record accurate facts, locations, times, conditions and actions. Commercial or legal interpretation can be developed by the appropriate professionals. Factual records are more durable when the later contractual position changes.
Are photos sufficient evidence of delay?
Photos can support the record, but they rarely establish full cause and effect alone. Combine them with programme, instruction, access, progress and daily-report evidence that explains what the image means for the affected work.
How long should programme versions be kept?
Retention depends on contract, legal and company requirements. From a project-control perspective, controlled historical versions should be preserved so key decisions and changes can be reconstructed. Follow the organisation's formal retention policy for duration.