Status reporting is the art of telling people what they need to know without triggering unnecessary panic or, equally bad, total disengagement. The goal is not to impress stakeholders with how much work is happening - it's to give them enough information to make good decisions and enough confidence to leave you alone.
What executives actually want from a status report
Executives don't want to know what you did this week. They want to know whether the project is on track, and if it's not, what they need to do about it. Every status report should answer exactly three questions: are we on track (Green/Amber/Red), what's the biggest risk or issue right now, and what do you need from me? Everything else is supporting detail that can live below the fold.
A good RAG status has teeth. Green means the PM would bet their reputation that the milestone will be hit. Amber means there's a known risk that could cause a miss unless something changes - and the PM should state what that something is. Red means a milestone is definitely going to be missed without intervention. A project that's been 'Amber' for three months with no escalation isn't Amber - it's Red with a reporting problem.
A common mistake: using status reports to demonstrate how hard the team is working instead of how the project is tracking. 'The team completed 47 tasks this week' tells an executive nothing useful. 'We're on track for the October milestone, but the vendor integration is two weeks behind - we need a decision on whether to allocate internal resources or accept the delay' tells them exactly what they need to know and do.
When and how to escalate (the bit most PMs get wrong)
The #1 rule of escalation: escalate early, escalate often, escalate with a proposed solution. A PM who escalates a problem at the exact moment they discover it is seen as proactive. A PM who escalates the same problem two weeks later is seen as reactive. The difference between the two is not the problem - it's the timing.
When you escalate, always include: what the problem is, what caused it (if known), what impact it will have on scope/schedule/budget, and at least one proposed solution. An escalation without a proposed solution is just complaining in a more formal setting. 'The vendor is two weeks late and I need help' is a cry for help. 'The vendor is two weeks late, I've discussed accelerated delivery but they can't commit, and I need you to authorise switching to a backup vendor' is an escalation.
The exception: very urgent problems that need immediate attention. In that case, escalate first with the facts, then follow up with the proposed solution. But don't make a habit of it. Stakeholders who constantly receive half-baked escalations start treating all escalations as noise, which defeats the purpose.
Summary & next steps
Status reports should answer: are we on track, what's the biggest risk, and what do you need from me. RAG status must have teeth - don't sit on Amber for months. Escalate early with a proposed solution. The most trusted PMs are the ones who surface problems before they become crises, not the ones who deliver perfect news until suddenly they don't.
You've completed Working with Stakeholders. Next up: Risk Management in Practice - because optimism is not a risk mitigation strategy.
Practice this
Status Report
Turn theory into a real deliverable. Generate a status report with the AI tool and adapt it to your own project.
Open the generator