Project Reporting Clients Actually Read
There is a specific kind of project report that takes two hours to assemble every Friday and is opened by nobody. It lists everything the team did that week, in roughly the order it happened, with a RAG status at the top that has been amber for a month. If this sounds familiar, the problem is not your writing. It is that the report is answering a question the client never asked.
The client is asking one question
Whatever they say in the kick-off about wanting visibility and transparency, a client reading a status report wants to know one thing: are we still going to get what we agreed, on the date we agreed? Everything else is supporting evidence for that answer.
This reframing does more work than any template. A list of completed tasks does not answer the question — it is evidence of effort, which the client already assumed. A burndown chart answers it only for work already scoped. What answers it is a statement about the end date and the confidence behind it.
So lead with the answer. "On track for the 14th" or "the 14th is now the 18th, here is why" belongs in the first line, not in a section labelled Risks on page three. If the answer is bad, putting it first is what buys you the credibility to be believed when the answer is good.
Front-load, then let people stop reading
A good report is designed so that a reader can stop at any point and still have the most important information they were going to get. That means strict inverse-pyramid ordering:
- The date, and whether it moved. One sentence.
- What changed since last time — decisions made, scope added or dropped, risks that materialised.
- What you need from them. Decisions, approvals, access. With deadlines.
- The detail — completed work, upcoming work, the full risk register.
Most reports invert this exactly, opening with completed work and burying the ask on the last page. The ask is the part with a deadline attached; it should never be the part people miss.
Show the timeline, not the task list
A list of tasks tells a client what happened. A timeline tells them what it means. When a client can see that the integration work slipped two days and that the two days pushed the launch milestone, they understand the consequence without you having to explain it — and, importantly, they understand it the same way you do.
This is the single highest-leverage change most teams can make to reporting. Replace the table of completed tickets with a simplified timeline view showing milestones, current position, and anything that moved since the last report. Keep it deliberately coarse: a client does not need every sub-task, they need the shape of the project and the position of the milestones they care about.
If you are not sure how coarse, a useful rule is that the timeline in a client report should have no more than about a dozen bars. If it has forty, it is a working document, not a communication tool. Our guide to reading a Gantt chart is a reasonable thing to send a client once, so that the view you share every week is immediately legible.
Report risks with a number attached
"There is a risk the third-party API may cause delays" is not a risk report. It is a hedge. It gives the reader no way to judge whether to care, and it protects the writer if things go wrong. Clients learn to skip these sections quickly.
A risk becomes useful when it carries an estimated impact and a trigger date: "if the vendor has not confirmed sandbox access by the 20th, launch moves by approximately a week." Now the client can act — they may have a relationship with that vendor, or be willing to accept a reduced scope, or simply want to reset expectations internally before the news gets worse. None of that is available to them from a vague warning.
The same applies to good news. "We are two days ahead" is worth stating, because it tells the client the buffer exists before they ask for something that would consume it.
Keep the cadence, shorten the report
The most common failure mode is not reporting too little, it is reporting too much, too laboriously, until the effort becomes unsustainable and the cadence collapses. A one-page report every week beats a comprehensive report every third week, because the value of a status report decays quickly and predictability is itself a form of reassurance.
If assembling the report takes more than twenty minutes, the problem is upstream — the plan is not current, or the information lives in five places. Fix that rather than budgeting more time for the report. When the plan is maintained continuously, the report is largely a matter of exporting the current state and writing three sentences of interpretation on top.
A minimal template
- Headline: on track / at risk / slipped, with the date.
- Since last report: three to five bullets, changes only — not activity.
- Timeline: a coarse milestone view with anything that moved marked.
- We need from you: decisions and approvals, each with a by-when.
- Risks: each with an estimated impact in days and a trigger date.
- Detail: everything else, below the fold, for the one reader who wants it.
That structure fits on a page, takes twenty minutes when the plan is current, and answers the client's actual question in the first line. It is not sophisticated. It is just organised around the reader rather than around the writer, which is most of what separates a report that gets read from one that does not.
