The PMO status report that doesn't lie — defensible RAG, RAID, and gates
The short answer
A PMO status report loses credibility the moment its RAG colour is an opinion. To make it defensible: write the RAG definitions down so green means the same thing to everyone — green is on track with no unmanaged risk; amber is a risk or issue that is live and being actively managed within the PM's authority; red is a decision or intervention needed above the PM's level (red is a request, not a confession). Give every RAID item an owner and a next action, not just a description. Make stage gates pre-agreed pass criteria set before the gate, not a date you defend on the day. And let the quantitative status assemble from the trackers — initiative counts, budget burn versus progress, RAID counts — rather than being hand-narrated, so the numbers can't drift to flatter. A status nobody can argue with is one where every colour has a written trigger and every red has a named decision attached.
Six moves to a status report nobody can argue with
- 01
Define RAG before you use it
Write the trigger for each colour and get the steering committee to agree it once. Green: on track, no unmanaged risk. Amber: a risk or issue is live and being actively managed within your authority. Red: a decision or intervention is needed above your level. Without written triggers, green is just optimism and red is a surprise — the 'watermelon' status that is green outside until it is suddenly red inside.
- 02
Make RAID owned, not just listed
A RAID log — Risks, Assumptions, Issues, Dependencies — is a graveyard if every row is a description and a shrug. Every item gets a single named owner and a next action with a date. The test: can you point at any row and say who is doing what by when? If not, it is a museum of problems, not a management tool.
- 03
Make gates pre-agreed pass criteria, not date theatre
A stage gate is only meaningful if the pass criteria were written down before the gate. 'We're at the gate, are we good?' is theatre. 'Here are the five criteria we agreed; four are met, one is conditional with a named owner and a date' is a decision. Set the criteria at the start of the stage, not on the day you face the gate.
- 04
Let the status assemble from the trackers
The quantitative half of the report — initiatives by status, budget versus spent, milestone and RAID counts — should pull from the trackers automatically, not be retyped on a Sunday night. Numbers that are hand-narrated drift to flatter the programme. Numbers that assemble from the source can't. The narrative is your job; the numbers are the trackers' job.
- 05
Report budget burn against progress, not in isolation
Budget spent means nothing on its own. A wave that has burned 60% of its budget but delivered 30% of its scope is in trouble months before the value number shows it. Always show burn next to progress — it is the earliest honest warning a PMO has.
- 06
Escalate the decision, don't narrate the colour
A red exists to get a decision made. The steering forum is there to clear the escalations only it can clear — not to watch a colour change shade. If a status meeting produced no decision, it was a status email with chairs. Every red should arrive with the specific decision it needs and the options.
A status report loses the room the moment its colour is an opinion
I have run transformation PMOs, and I have watched more than one lose the steering committee’s trust in a single meeting — not because the programme was failing, but because the status report could not be defended. The colour was green last week and red this week, and nobody could say what changed, because nobody had written down what green meant in the first place.
A defensible PMO status is built on four disciplines. None of them is clever. All of them are the difference between a report people act on and a report people argue with.
1. RAG with written triggers
The most common failure in programme reporting is the watermelon: green on the outside, red on the inside, right up until it can’t be hidden. It happens because nobody wrote down what the colours mean, so green drifts into “we haven’t admitted it’s amber yet.”
Fix it with three written definitions, agreed by the steering committee once:
- Green — on track; no unmanaged risk.
- Amber — a risk or issue is live and being actively managed within the PM’s authority.
- Red — a decision or intervention is needed above the PM’s level. Red is a request, not a confession.
Now the colour is a fact, not a mood. Two people looking at the same programme reach the same colour.
2. RAID that’s owned, not listed
A RAID log — Risks, Assumptions, Issues, Dependencies — becomes a graveyard the moment its rows are descriptions instead of actions. Every item needs one named owner and a next action with a date. The test is simple: point at any row and say who is doing what, by when. If you can’t, it’s a museum of problems.
3. Gates that are pre-agreed criteria
A stage gate only means something if the pass criteria were set before the stage, not defended on the day. “We’re at the gate, are we good?” is theatre. “Here are the five criteria we agreed; four are met, the fifth is conditional with an owner and a date” is a decision. Conditional passes are fine — undefined passes are not.
4. Numbers that assemble themselves
The quantitative half of the report should pull from the trackers automatically — initiatives by status, budget burn versus progress, milestone and RAID counts. Hand-narrated numbers drift to flatter the programme; assembled numbers can’t. And always show budget burn next to progress: a wave that has spent 60% to deliver 30% is in trouble long before the value number admits it.
The role behind the report
If you run a PMO, your credibility is the report. Make every colour defensible, every RAID row owned, every gate pre-agreed, and every red a decision waiting to be made — and the steering committee starts deciding instead of debating. That is the whole job.
Part of The Job, Decoded — the operator’s series on what enterprise-operations roles actually are. This is the PMO / programme manager, decoded.
Frequently asked
What makes a RAG status defensible?
Written definitions everyone agreed on in advance. The colour stops being an opinion and becomes a fact about whether stated criteria are met. Green means on track with no unmanaged risk; amber means a risk is live and being managed within the PM's authority; red means a decision is needed above the PM's level. When the triggers are written and agreed, two people looking at the same programme reach the same colour — which is the entire point of a status report.
Why do PMOs lose credibility?
Three ways, all avoidable: the 'watermelon' status that stays green until it turns red overnight (no written RAG triggers); a RAID log that only describes problems instead of assigning owners and actions; and a steering forum that reviews colour instead of making decisions. The fix is the same in each case — make the thing defensible: written criteria, named owners, decisions attached to every red.
What's the difference between a risk and an issue in a RAID log?
A risk is something that might happen and would hurt the programme if it did — it gets a likelihood, an impact, and a mitigation owner. An issue is something that has already happened and needs resolving now — it gets an owner and a resolution action with a date. Conflating them is common and costly: risks get managed too late because they were logged as someday-issues, and issues get under-prioritised because they were filed as theoretical risks.
How often should a PMO report status?
Match the cadence to the decision rhythm, not the calendar. A weekly operating rhythm for the delivery teams, a fortnightly or monthly steering report for the decisions only steering can make. The trap is reporting frequently but deciding nothing — a beautifully produced weekly deck that never forces a choice is expensive theatre. Report as often as there are decisions to make, and no more.
The done-for-you version: a 9-tab Excel workbook — programme plan, initiative tracker, milestone gates, a RAID log, a status report that auto-summarises from the trackers, and benefits realization — plus a 15-page operating handbook with the defensible-RAG rubric, the conditional-pass discipline, and a worked turnaround.
Get the Transformation Delivery & PMO Pack — $79 →Written by Petko Petkov — 15 years inside enterprise IT operations. Vihren Labs publishes operator-grade templates and playbooks for the enterprise IT stack.