How to Write a Project Status Report That Stakeholders Actually Read

The Problem with Most Status Reports

Most project status reports are too long, too late, and too focused on the past. They document what happened last week in exhaustive detail, bury the critical information in paragraph four, and arrive on Friday afternoon when no one has time to read them.

The result is a status report that no one reads — which means the PM is spending time creating a document that provides no value to anyone.

The RAG Status System

The most effective status reports use a RAG (Red, Amber, Green) status indicator at the top. RAG gives stakeholders an immediate, at-a-glance view of project health before reading a single word.

• 🟢 Green — The project is on track. No significant issues or risks.
• 🟡 Amber — The project is at risk. Issues require attention but have not yet caused a confirmed delay.
• 🔴 Red — The project is off track. Confirmed delay, budget overrun, or scope issue requiring immediate attention.

The 3-Line Status Report Format

For most projects, a status report does not need to be long. This format delivers everything a stakeholder needs:

How to Report Bad News

• Report early — stakeholders can help solve problems they know about.
• Be direct about status — a project that is behind should be Amber, not Green with a caveat in paragraph four.
• Come with solutions — present at least one option for resolving the problem.
• Never hide bad news in data — it erodes trust when discovered, and it always is.

Common Status Report Mistakes

• Reporting on the past instead of the present and future.
• Making it too long — if it takes more than 5 minutes to read, stakeholders will stop reading.
• Reporting Green when the project is Amber.
• Not including a clear ask — every status report should drive an action.
• Inconsistent format — stakeholders cannot quickly find information if the format changes every week.