Project status report: one page that survives being skimmed

A project status report tells the people funding or depending on a project where it stands. It is read quickly, usually by someone with several other projects to think about, and the only questions they actually have are: is this on track, what changed, and does anything need me. A report that does not answer those three in the first paragraph will not be read further, however complete the rest is.

The chronic failure is reporting activity. A list of what the team did last week feels like accountability and tells the reader nothing about whether the project will land. Report position and change, not effort.

What belongs in the report

• Project, period, author and date — unambiguous, at the top.
• Overall status in one word, against a scale everyone agreed in advance: on track, at risk, off track.
• What changed since the last report. If nothing changed, say so — that is itself information, and often bad news.
• Progress against plan: what was due, what completed, what slipped and by how long.
• What is planned for the next period, at the level of deliverables rather than tasks.
• Risks and issues that need a decision, separated from the ones you are managing. The reader only needs the first list.
• Budget position: spent, committed, remaining, forecast at completion.
• Decisions requested, with a date by which each is needed. This is the section that makes the report worth sending.
• Key dates ahead, so nobody is surprised by a milestone.

Agree what the status colours mean before the first report, in writing. Without a definition, "at risk" means whatever the author's temperament suggests, and the same project is reported green by one manager and amber by another. Tie them to something checkable — for instance, at risk when a milestone will slip beyond a defined tolerance without intervention.

Writing it in fifteen minutes

1. Fix the template and never redesign it. Comparability across weeks is most of the value.
2. Write the status word and the change sentence first — if those two are right, the rest is supporting detail.
3. Pull the progress figures from wherever the work actually lives rather than from memory.
4. Separate risks needing a decision from risks being managed. Mixing them makes the reader triage on your behalf and they will not.
5. State the decisions requested with dates. A report with no ask is a broadcast, and broadcasts get skimmed.
6. Keep it to one page. If the detail matters, attach it rather than embedding it.
7. Send on the same day and time every period. Predictable reports get read; irregular ones get filed.
8. Do not soften a slip. The cost of reporting amber early is a conversation; the cost of reporting it late is the project.

The reporting rhythm

Weekly reports suit projects measured in weeks; monthly suits anything longer. What breaks the rhythm is reporting too often on slow-moving work, which produces reports that say nothing and train the reader to ignore them. The other failure is escalating only at the point of crisis: a project that reports green for eight weeks and then red has not deteriorated suddenly — it has been reported wrongly, and the reader learns to distrust every subsequent green.

In Ettex, the report lives in Ettex Docs — templates so every period starts from the same structure, version history so last month's report as sent is recoverable, threaded comments if a stakeholder queries a figure, and a share link so the report is a link rather than an attachment nobody can find. The underlying work sits in Ettex Board with columns, assignees, due dates and a log of every move, the numbers and the budget position come from Ettex Sheets, milestone dates from Ettex Calendar, and the risks referenced in the report belong in a register in Ettex Records.

Said plainly: Ettex has no project reporting. Nothing here generates a status report from your board, calculates percentage complete, produces burndown charts, or tracks earned value. You write the report and pull the numbers yourself. Fifteen minutes a week is a reasonable trade for a small project; portfolio-level reporting across many projects wants a PM tool that rolls up automatically. It reports against what was agreed, so it is only as useful as the project charter it refers back to.

Charts describe a plan; something has to record what actually happened. Project tracking software keeps tasks, owners, dates and progress in one place so the status report is produced from data rather than from recollection.

A status report that lists everything red treats all delays as equal. The critical path separates the slippage that moves the finish date from the slippage that costs nothing, and only the first kind belongs at the top of the page.

Why status reports get ignored

• Activity lists instead of position and change.
• Status colours with no agreed definition, so they carry no information.
• Risks needing a decision buried among risks being managed.
• No decisions requested, making the report a broadcast.
• Length — three pages of detail that hide the one sentence that mattered.
• A format that changes each period, destroying comparability.
• Sent irregularly, so nobody builds a habit of reading it.
• Optimism until the deadline, which destroys trust in every earlier report.

Two documents bracket the report. A project charter says what was agreed at the start, which is what status is measured against, and an issue log holds the problems the report should be summarising rather than restating in full.

A project status report answers three questions: on track, what changed, what do you need from me. Fix the template, define the colours in advance, ask for decisions with dates — and report amber the week you first believe it.