The daily progress report nobody reads

Every project has a daily progress report. On most projects it is a form filled in at the end of the day by a site engineer who has been on his feet since seven, describing things he knows and nobody has asked about.

It is filed. It is very rarely read. And when a dispute arises two years later it becomes the most important document on the project, at which point everybody discovers what was actually in it.

The three purposes, which conflict#

A DPR is asked to do three jobs, and they pull in different directions.

Management information. What happened today, so somebody can decide what to do tomorrow. Wants to be short, current and comparative.

A contemporaneous record. Evidence of what occurred, for claims, disputes, insurance and delay analysis. Wants to be complete, specific and dated, and its value increases with detail.

Compliance. A form somebody requires. Wants to be filled in.

Design for the first and it is useless in a dispute. Design for the second and nobody will complete it daily for two years. Design for the third and you get a form that satisfies nobody and is completed by copying yesterday's.

Most DPRs are the third, because the third is what survives when the other two have no advocate.

Why the third one wins#

The person writing it gets nothing from writing it.

That is the whole mechanism. The site engineer already knows what happened today. The report costs them twenty minutes at the end of a long day and returns them nothing at all. No decision comes back, no question is answered, nobody comments on it. The only feedback they ever receive is when it is missing.

Under those conditions a rational person minimises effort, and the report becomes a slightly modified copy of the previous one. This is not dishonesty. It is what any incentive structure of that shape produces, and it will not be fixed by insisting harder.

The two things that change the outcome#

Make it shorter than it is worth arguing about. Most DPR forms ask for things that could be derived from other records — material received, attendance, plant hours, weather. If those exist elsewhere in the system, they should be pulled in, not typed again. Re-typing what a machine already knew is the most reliable way to teach somebody a form is not serious.

Give something back. A report that produces an answer, a decision, or a visible acknowledgement is a report people complete. One that disappears is not. This is the single highest-leverage change available and it costs nothing technical — somebody senior reading it and replying two sentences, most days, is enough.

The fields that matter in a dispute#

If the second purpose is real — and on any project of size it is — a small number of fields carry almost all the evidential value, and they are not the ones forms usually emphasise.

• What was actually done, located. Not "continued blockwork" but which area, which level, which grid. Unlocated work cannot be tied to a delay later.
• Who was on site, by trade and number, and whose people they were.
• What stopped, and why, and for how long. The single most valuable line in any progress record. Waiting for a drawing, waiting for material, waiting for an inspection, rain. Delay claims are built entirely from these and they are the first thing omitted when somebody is in a hurry.
• Instructions received, and from whom. Verbal instructions become disputes about whether they were given.
• Weather, recorded honestly rather than as a category.
• Plant on site and whether it was working.

Notice that three of those six are about things not happening. A progress report that can only record progress cannot record the reason there was none, which is exactly the information anybody will want. The wider question of what belongs in writing and what should stay out of it is what a site engineer should record.

Photographs are the report, if you let them#

The most complete daily record on most sites is already being produced and is not being kept: the photographs people take.

They are taken constantly, they are located, they are timestamped, and they show what a paragraph cannot. The reason they are not the record is that they are unlabelled, live in a chat, and nothing indexes them.

That is a solvable problem and a much smaller one than getting people to write more. Our own experience is that the photographs were already arriving in volume — over a thousand of them — and had never become anything, because the system was looking for a typed caption and site photographs usually have no caption. The picture already says everything, so nobody types.

The general principle is in a site photograph is a record, if anything reads it.

Ask, do not require#

There is a version of daily reporting that works far better than a form, and it is a question.

Once a day, to the people with unfinished work, in the medium they already use, a short list of what is outstanding — with a small number of honest answers available. Done. Moved to tomorrow. Moved to a date. Stuck, and here is why.

Four answers, each running the same action the application itself would run. It takes ten seconds rather than twenty minutes, it produces structured data rather than prose, and the "stuck, and here is why" answer collects the single most valuable field in progress reporting without anybody having to think of it as reporting.

We built ours as an evening list on WhatsApp, capped at a handful of items, respecting leave. The cap matters: a list of thirty things is not a question, it is an accusation, and people stop answering.

Do not use it as a performance record#

The fastest way to destroy the honesty of a daily report is to use it to judge the person writing it.

The moment "waiting for material, four hours" becomes evidence in somebody's appraisal, that line stops appearing. What replaces it is a report full of activity and empty of obstruction, which is precisely the report with no evidential value. The same pressure inflates the percentage at the top of a weekly report — reported progress and real progress.

If you want to know where time actually goes, the reporting has to be safe. The same logic applies to escalation, which is why we built ours to surface slipping work without anybody having to name a colleague — escalation without shame.

The short version#

A DPR fails because writing it returns nothing to the person writing it.

Shorten it to what only they know, derive the rest, reply to it so it is visibly read, and capture the photographs that are already being taken.

And make sure it can record the absence of progress, because that is the part somebody will need.