↓ Download as PDF

If your internal customers keep asking you for status, you do not have a workload problem. You have a visibility problem. Every “quick question” is a report that did not exist, arrived late, or was not trusted — and every answer you give verbally trains people to ask you verbally next time. You are running a help desk you never agreed to staff.

The instinct is to fix the artefact: a cleaner template, a nicer layout, more detail. It never works, because the font was never the problem. The failure modes of a status report are cadence, trust, and actionable data. Fix those and something quietly changes: the questions stop arriving.

Five principles follow. They are the difference between a report people rely on and a spreadsheet people ignore on their way to phoning you anyway.

1.  Never miss a week

The value of a status report is not in any single edition. It is in becoming infrastructure — something people rely on being there. That only happens with monotony: same day, same time, same structure, every week, including the boring ones. “No change” is information. Silence is a question generator, and one skipped week and the pings resume. Ask any dog trainer.

Freeze the format so a reader finds their project in ten seconds; batch improvements into a deliberate version two rather than drip-feeding changes that make people re-learn the layout every week. And push it — email, with the exceptions inline. A shared folder is where reports go to be ignored; nobody goes looking for a file, and you know this. One quiet move that pays for itself: put your own management on the distribution from day one. A report with clean escalation logic reads as someone already operating a level up. That is not an accident.

2.  Nobody reads two hundred rows

The two-hundred-row purchase-order dump contains everything and communicates nothing — so they ask you anyway, and now you are producing the report and answering the questions. Congratulations.

The first thing a reader sees should be exceptions only: what changed, and what is at risk. The full detail lives in an appendix tab or a system view, for the drill-down crowd who genuinely want it. Cite your source and the time you pulled the data — they may have something fresher, and you do not want them thinking the picture went backwards. And watch the length: if the exception section runs past one screen, either the business has a real problem or your risk threshold is set wrong. Find out which. Both are worth knowing.

3.  “Delayed” is not an answer

The word “delayed” guarantees a follow-up question, which defeats the entire purpose of writing the report. Every exception line has to carry enough that nobody needs to call about it.

Name the person who has the ball, so a reader can go straight to the source. This pre-empts the “so what do you need from me” call — and that call was never free. The bonus is a dated escalation trail: when a delay becomes a project issue, the record shows you flagged it on time, in writing. Reactive people answer questions. Operators hold others accountable.

And if you cannot populate those four fields, the report was never your real problem — your supplier communication cadence is. Fix that upstream first, and publish second.

4.  Make the prediction anyway

Backward-looking reports document failure. Forward-looking reports prevent questions. Nobody can book a flight off “factory acceptance test expected soon.”

So publish a rolling six-to-eight-week lookahead, with dates and a confidence level against each:

Flag the risks before they become delays — “supplier missed an intermediate milestone” reaches the reader three weeks earlier than “shipment slipped,” which is three weeks of options they would otherwise not have had. It is your judgment they actually want. Share your thinking — “recovery will be complete by the first of June” — or they will call you to hear it.

5.  Build one you can sustain

Launching a report you cannot sustain is worse than not launching one. Three hours of Monday-morning spreadsheet archaeology and the report is dead within two months. Miss a week and people go back to asking you — that is the bad case. The worse case is a single publicly wrong date, because then trust is gone and they go back to asking you verbally, which is where you started. A stale report is more damaging than no report. At least silence is honest.

The way it survives is division of labour: the system pulls the status, and you add the judgment — the reasons, the confidence, the flags. Total production time under an hour. If it is more than that, the data source has become the project, and that is the thing to fix — fix the data, or scope the report down to what you can honestly populate, or make it someone’s job to prepare the data so that all you add is the judgment. What you must not do is build the perfect report once and watch it die.

---

A report that arrives on time, shows only what matters, and says what happens next does not answer questions. It makes them unnecessary. The questions stop, the escalations are dated and in writing, and you become the person holding others accountable rather than the one being chased.

None of which is a document you write once. It is an operating rhythm — a cadence, a format, a data source and a distribution list — that has to be stood up and then kept running every week without you becoming its single point of failure. Designing that so it survives contact with a Monday, and handing it to managers who run it after I have gone, is the work.

That is the work I do.