The daily report is the one document on a project that gets written every single day, and it is simultaneously the document the fewest people read. That contradiction is the problem: a crew fills in a form because the contract demands it, an office files it without looking, and eighteen months later a delay dispute opens the archive — and nobody finds what they need. This is a guide to writing a daily report worth the time it costs.
Key takeaways
- A report written three days after the event is not evidence — contemporaneity is what gives it weight.
- Labour, plant and activities get recorded as numbers and locations, not as "works continuing".
- Weather goes in every day, including clear ones; a partial record proves nothing about the wet day.
- A photograph without a date, a location and a reason is a picture, not evidence.
- A report that takes more than five minutes will not be filled in honestly — it will be copied from yesterday.
Why most daily reports fail
Open the daily report archive of any troubled project and the pattern is the same: dozens of near-identical pages, phrases like "finishing works continuing" and "situation normal", and blank fields on exactly the days when something worth recording happened. The form was completed; the information is missing.
The cause is not laziness. The cause is that the report is designed as a contractual obligation rather than as a tool. The person filling it in gets nothing back from it, and the people who need it — the claims function, the contracts manager, the client — only read it after a problem has already occurred. With no feedback loop, completion drifts down to the minimum that looks acceptable.
- Filled in at the end of the week in one sitting, from memory, so the days blur together and the detail is gone.
- Copied from yesterday with the date changed.
- Records what happened and not what did not happen and why — which is precisely what a claim needs.
- Signed by the supervisor and read by nobody after that, so no mechanism ever catches the gaps.
What the report actually has to record
A useful report answers one question: if somebody who has never visited the site looks at this day two years from now, can they tell who was there, what got done, and what stopped more from getting done? Every field that does not serve that question is padding.
Labour by number, trade and location
Not "45 operatives" but "12 steel fixers — level 3, 8 carpenters — formwork bay 4, 15 general — backfill". A headcount alone cannot show how a shortage in one trade hit one specific activity.
Plant: on site, working, and standing
The distinction between plant present and plant working is the whole point. A crane on site and down for three days with a fault is a cost item and a delay item at once, and logging it as "crane: 1" hides both events.
Activities tied to their items
Link what was executed to a BOQ item or a programme activity. "Slab poured" means nothing; "Block B level 2 slab — item 03-300 — 140 m³" reads straight into the report, the payment application and the programme update.
What stopped, and why
The single most important line in the report, and the one most often left blank. "Cladding to north elevation stopped pending response to RFI 214 — day 4." That line is what builds the claim later.
Visitors and verbal instructions
Who visited and what they asked for on site. The unrecorded verbal instruction is the most common source of dispute on any project, and logging it in the daily report turns it into a documented fact on the day it happened.
Weather: the field that decides extension claims
Most contracts grant an extension of time for exceptionally adverse weather. The word "exceptionally" is the problem: proving it requires comparing what happened against what is normal, and that comparison requires a continuous record rather than a selective one.
A firm that logs the weather only on bad days holds a biased record that cannot support a comparison. A firm that logs every day — including thirty consecutive clear ones — holds a baseline: this is the normal condition, and this is the deviation from it.
| Field | Why it matters |
|---|---|
| Max and min temperature | Specification limits on pouring and hot-weather working are tied to it |
| Rain: occurrence and approximate duration | Two hours in the morning is a different event from a full day |
| Wind speed | Tower cranes stop at a defined limit; that is a justified stoppage and needs a record |
| Ground condition after rain | Unworkable ground disrupts for days after the rain itself has stopped |
| Hours actually lost | The number the claim needs — a description of the weather alone is not enough |
An extension claim is not built on the weather having been bad. It is built on this many working hours being lost on this specific activity on these dates — and on the record having said so from day one.
Photographs: turning memory into evidence
Every site now takes hundreds of photographs a month, and almost none of them carry evidential value. A picture with no known date, no known location and no stated reason for existing is a visual impression, nothing more — and it will not survive a serious discussion.
- Date and time taken from the device rather than typed in — metadata is far harder to challenge.
- Coordinates attached, so the elevation or block is identifiable without interpretation.
- A one-line reason: "reinforcement ready for inspection prior to pour", or "standing water after 24 July rain".
- Attached to that day's report, not living in a separate folder on somebody's phone.
- A scale reference in frame when photographing a defect or a dimension — a tape or a pen gives the viewer a measure.
How to get it filled in, every day
All of the above is theory if the form itself is the obstacle. A site supervisor at the end of a ten-hour day in the sun will not honestly complete four pages — they will copy yesterday. The design of the report is part of the problem, not discipline alone.
The five-minute rule
If completing the report takes more than five minutes on an ordinary day, the form is longer than it should be. The fix is not less information but less typing: labour comes from the attendance record, activities are picked from the project item list, weather is pre-filled. What remains for the supervisor is the human judgement — what stopped, and why.
Filled in on site, not back at the office
A report that requires returning to an office and opening a laptop gets written from memory hours later. A report filled in on a phone at the point of the event gets written at the time. That imposes one technical condition: it has to work with no network, because the place where the record is created rarely has reliable signal.
- Fields pre-populated from data the system already holds.
- Offline capture with automatic sync afterwards — not a "try again later" message.
- A clear daily close: the report is signed off and can only be amended through a visible edit trail.
- A weekly read by the project manager, so the person filling it in knows somebody looks.
From archive to claim
A good claim is not written, it is extracted. A firm with a disciplined daily record needs days to assemble an extension submission; a firm without one needs weeks to reconstruct events from email and memory, and arrives at a weaker result.
Identify the disrupting event and its date
An unanswered RFI, a variation instruction, or rain days. The date comes from the daily report, not from recollection.
Tie it to the affected programme activity
Disruption that does not sit on the critical path usually produces no extension. Linking to the activity is what converts an incident into a time effect.
Quantify the effect in hours or days
From the lost-hours field and the recorded labour counts — numbers you already hold, rather than estimates made after the fact.
Attach the contemporaneous record
The daily reports for the period, the dated photographs, and the correspondence proving notice was given at the time. That is the whole file.
The conclusion is that the daily report is not administrative overhead completed to satisfy a clause. It is the cheapest insurance policy on the project: five minutes a day buys the ability to prove what happened, in a discussion that may be worth a meaningful share of the contract value.
Frequently asked questions
Who should write the daily report?
The site supervisor or site engineer who was actually present through the day. A report written by somebody who was not on site is second-hand narration and its evidential value drops sharply. Best practice is that the person who witnessed the events writes it and the project manager signs it off.
Should we record days when nothing happened?
Yes, and they matter more than they appear to. The continuous record is what proves the exceptional days were genuinely exceptional. A series of reports that stops on quiet days makes the whole record look selective, and that is the first thing challenged.
How long should daily reports be retained?
At least through the project and the defects liability period, then for the limitation period set by the contract or local law — often years after handover. Digital retention makes that requirement effectively free.
What is the difference between the daily report and the monthly progress report?
The daily report is a record of facts: who, what, when, and what was held up. The monthly report is analysis and trend: percentage complete, variance, forecast. The first is a data source, the second is a reading of it. A good monthly report is built from the dailies, not from an office estimate.
Is a WhatsApp group enough to document a site?
No. Group chats produce a chronological message log but not a searchable record linked to contract items, media is auto-deleted after a period, and messages can be deleted by either side. They are fine for immediate coordination and unfit as an evidential archive.
A daily report filled in on site, with no signal
Capture labour, plant, disruption and dated photographs from a phone on site, and let them sync automatically when the network returns — in Arabic and English.