What should a delay record include?

When an activity starts late on site, the delay itself is rarely the problem — the argument about it months later is. Whether it's a claim for an extension of time, a loss and expense claim, or just a main contractor asking why the programme slipped, the side with the better record usually wins. Memory doesn't count. Records do.

It's worth knowing that in a dispute, not all delays are treated equally. Contracts broadly distinguish between delays caused by the client or their team, delays caused by the contractor, neutral events like weather, and concurrent delays where more than one thing goes wrong at once. Which category a delay falls into decides whether you're entitled to time, money, both, or neither. But here's the thing: classification is an argument for later, made by commercial people and sometimes lawyers. What decides whether that argument can be won is whether anyone kept a proper record on the day. Whatever category your delay ends up in, the record is what proves it.

A delay record that stands up needs to answer four questions: what was delayed, when, why, and who it affected.

1. The activity and its programmed dates. Name the activity exactly as it appears on the programme, with its planned start and finish. A delay only exists relative to what was planned — without the baseline, you're just describing a slow day.

2. The dates that actually happened. The date the delay was identified, and later, the date the activity actually started. The gap between programmed and actual start is your delay duration — in days, stated plainly.

3. The reason, recorded at the time. Materials not delivered, access not available, prior trade incomplete, design information missing — whatever it is, write it down on the day. A reason recorded contemporaneously carries weight; a reason reconstructed three months later in an email chain does not.

4. Who caused it and who it affected. The contractor responsible for the delay, and the trade or contractor whose work was held up. Delays cascade — the record should show the first domino and the ones behind it.

Then the evidence that makes it undeniable: photographs with time and location. A photo of the delayed state, and ideally one when the activity finally starts. If those photos carry a GPS location and timestamp, the record stops being your word and becomes fact.

Finally, keep the records together. A delay register — every delay on the project in one place, in date order — is worth far more than the same information scattered across diary pages, emails, and photo folders nobody can search.

Most site managers know all this. The reason delay records are still thin on most jobs is time: on a busy site, stopping to write it all down loses to the next fire that needs fighting. That's the problem Site Pal was built for — upload your programme, and when an activity doesn't start on time, it's flagged automatically; log the reason and a photo in seconds, and the delay record — dates, duration, responsibility, GPS-stamped photos — is built for you as a PDF.