Executives do not read status reports to learn what you did this week. They read them to answer three questions: are we going to land this, what has changed, and do you need anything from me? If you want to know how to report project status to executives, start there. Everything on the page should help answer one of those questions, and anything that does not can go in an appendix.
I have written status reports for sponsors and sat on the receiving end of them. The ones that work are short, honest and ask for something. The ones that fail are long, green and vague. This guide gives you a RAG rating that tells the truth and a one-page structure you can use this week.
Why are project status reports important?
A status report is how a sponsor decides whether to step in. If the report is accurate, they can act while a problem is still small and cheap. If it hides the problem, they find out when the only options left are more money, a later date or less scope.
That is not a small risk. In McKinsey and Oxford's study of large IT projects, the average overrun was 45 percent of budget. In my experience, few overruns surprise the team. They surprise the people paying, because the report stayed green too long.
What is RAG in a project status report?
RAG stands for Red, Amber, Green. It is a colour code that summarises how a project, or one part of it, is doing. The trouble is that most teams never write down what each colour means. So green becomes the default, amber feels like an admission, and red is saved for disasters.
Fix this by defining each colour against your baseline for scope, date and budget, and by agreeing the definitions with your sponsor before the first report.
- Green: on track to deliver the agreed scope, date and budget. No help needed.
- Amber: at risk of missing one of them, but the team has a recovery plan it can carry out on its own authority.
- Red: will miss the baseline unless someone above the project makes a decision or provides help.
A RAG that tells the truth
Some teams call the dishonest version watermelon reporting: green on the outside, red on the inside. It usually is not lying. It is optimism, plus a fear that amber will trigger a painful review. Here is the difference in practice.
Status report that hides
- Green for months while milestones quietly move
- Lists activity: meetings held, documents written
- Budget shows spend to date only
- Risks copied from last month, with no new actions
- Ends with no request, so nothing gets decided
Status report that tells
- RAG set against written rules and the baseline
- Shows outcomes: milestones hit or missed, and why
- Budget shows actual, forecast at completion and variance
- Top risks have owners, dates and a trend
- Names the decision needed, by whom and by when
One habit makes a big difference. Let the RAG come from the data where you can: forecast against budget, milestones against baseline, and open high risks. Then the project manager adds judgement on top, rather than starting from a blank colour. If your forecast keeps drifting, our guide on why projects go over budget explains the early signals.
What should a project status report include?
For an executive audience, keep it to one page. Here is the structure I use, in the order a sponsor reads it.
The one-page status report
- Overall RAG and one sentence
The colour plus a single line on why. For example: Amber, because the data load slipped two weeks and the recovery plan is in place.
- Decisions needed
What you need, from whom and by when. Put it near the top, not on page four.
- Milestones
The next three to five milestones, with baseline date, forecast date and a RAG for each.
- Budget
Budget, actual to date, forecast at completion and variance. One line each.
- Top risks and issues
Three to five items, each with an owner, an action and a date. Show whether each is getting better or worse.
- What changed since last time
New scope, approved changes, people joining or leaving. Only what matters to the sponsor.
Leave out the activity list. Executives assume the team is busy. What they cannot see is whether the busyness is turning into progress.
How to present status in the steering meeting
The page is only half the job. How you present it decides whether the meeting produces action. Before you send the report, run through this list.
Before you send it
- The RAG follows the written definitions, not your mood
- Every amber or red has a recovery plan or a request
- The decision you need is on the first half of the page
- Forecast dates and costs are shown next to the baseline
- No surprises: anyone named in a red item has heard it from you first
- It fits on one page
In the meeting, start with the decision, not the history. Give the options, your recommendation, and the cost of waiting. If you are not clear who in the room can decide, read our guide to steering committee roles and decisions.
How ProjectCAPEX helps you report status
In ProjectCAPEX, a status report is built from the live project, not copied from last month. The Status reports tab sets the overall health and period, and brings in the budget summary, milestones, open actions and decisions from the project records. You add the commentary.
- The Status Report Agent drafts a report for the period from live records. You review, edit and finalise it.
- A finalised report can be sent for e-signature, so sign-off is on record.
- Sponsors see every programme on the portfolio status view, grouped by RAG, with the variance, schedule, open high risks and next milestone behind each colour.
To see it with a programme already in flight, open the demo, or start a 14-day free trial and write your next report there.