Watermelon status reporting is harder to hide across PMO workstreams when the PMO sets one written colour standard for every workstream, requires evidence behind each colour, and rolls the portfolio up to its worst workstream. When those rules are in place, a red can reach the steering committee early, as a request for help rather than a surprise. Start with the colour definitions and the roll-up rule, because the other steps depend on them.
Why do workstreams report green while they are red?
Workstreams report green while red when telling the truth has become personally expensive. Cultivated Notes describes watermelon reporting as a fear problem, where optimism replaces evidence. Before you change any report, ask each lead the questions below to find out which cause applies.
Ask each workstream lead these questions before you change any report:
- What would have to be true for this workstream to turn red before the next steering meeting?
- When did we last raise a blocker, and what happened to it?
- Which decision is this workstream waiting on, and who owns it?
Each answer points to a cause. PM-Partners lists misleading reporting, over-optimism, poor visibility, weak governance, and unaddressed risk as causes of this pattern. Match each workstream's answers to one of those causes before you set new rules. The matching step is the PMO's own suggestion; the source names the causes but does not explain how to match them to a workstream.
The colours need the same scrutiny. Cultivated Notes points out that a RAG colour is often someone's judgement about reality rather than reality itself, so each colour needs a written test before it can be compared across workstreams.
How do you define green, amber, and red once for every workstream?
Define green, amber, and red once for every workstream by tying each colour to a condition a second person can check, such as a milestone date, an open blocker, or a decision still waiting. PM-Partners recommends defining specific, measurable criteria for all project statuses, so the colour becomes a shared test rather than one lead's opinion.
Work through these steps with the workstream leads. The steps are the PMO's own method; the sources support the measurable criteria and the definition of done.
- Write the colour definitions for all workstreams in one short shared document.
- For each colour, write the condition that must be true, using only what a reviewer can see in the plan or the tracker.
- Define done for each deliverable, so green cannot rest on activity alone. Pragmatic Coders advises defining done precisely.
- Agree that a colour changes only when its condition changes, and that the lead records the date of the change.
Use this template for each workstream:
Workstream: [name]
Green when: [milestone] is on or before [date], and no blocker is older than [agreed limit]
Amber when: [condition the lead and PMO agreed]
Red when: [condition the lead and PMO agreed]
Rule owner: [PMO lead name]
A condition such as "the team feels good" cannot be checked. Rewrite it until a reviewer could confirm it from the plan or the tracker.
What evidence should each status need?
Each status should point to evidence the steering committee can open or check: an accepted deliverable, a test result, a blocker with an owner and a first-raised date, or a decision still waiting. A status with no evidence should show as amber until the evidence arrives, which is the PMO's own rule.
A Medium essay suggests stating which items are blocked and for how long, so the status block below carries that detail. Ask each lead to fill in this block in the status report:
Workstream: [name]
Status: [green, amber, or red]
Evidence: [deliverable accepted on date], or [link to test result]
Open blockers: [blocker], owner [name], first raised [date]
Decision needed: [decision], from [name], by [date]
Accept a green only when its evidence line names something a reviewer can open or check, such as an accepted deliverable or a test result.
If the PMO needs to check the items a block names, Pragmatic Coders advises direct access to the task board and repository. This guide adds a caution the source does not give: confirm contract and security terms before any access is granted, and limit access to the items that support each status.
How do you roll workstreams up without hiding a red one?
Set the portfolio colour on the steering pack equal to the worst workstream colour, and list every amber and red workstream by name above it. PMO judgement: averaging colours lets several green workstreams hide one red. The roll-up rule is the PMO's own recommendation; none of the listed sources sets one.
Write the rule into the steering pack template before the next pack is prepared:
- Write the rule into the template: the portfolio colour equals the worst workstream colour unless the steering committee has agreed a written exception.
- List amber and red workstreams by name, each with a short reason, at the top of the pack.
- Mark any green workstream that depends on an amber or red one as at risk, and name the dependency.
- Keep a short, separate list of blockers that cross workstreams, each with a named owner.
Illustrative example (invented values, shown with placeholders): Workstream [A] reports green because its milestone [M1] is on track. Its only dependency, workstream [B], is red because a decision from [name] is still open. Under the rule, [A] appears as at risk with its dependency named, [B] is listed at the top of the pack with its reason, and the portfolio shows red.
PMO judgement: a common mistake is a green workstream whose work is parked, waiting on another team. Show it as at risk, even when its own tasks are on track.
How do you escalate amber and red to the steering committee?
Escalate every red workstream at the next steering meeting, and escalate an amber when it needs a decision the committee owns or its blocker has no owner after the lead has tried to resolve it. Each escalation names the decision, the person who must make it, and the date it is needed. This escalation rule is the PMO's own.
Use this request when a decision is holding up a workstream:
Subject: Decision needed on [item], [project]
[Name], we need your decision on [decision] by [date]. If it waits, [deliverable] moves from [date] to [date].
The options are [option A] and [option B]. We recommend [option], because [evidence].
Please reply with your choice, or tell us who should decide instead.
Read the request yourself before it goes out. Check that the decision, owner, and date match the evidence in the status block.
How do you run the steering conversation so red counts as information?
Open the steering meeting with the red and amber workstreams, ask each lead what help they need, and record an owner and a date for each action. Cultivated Notes frames red as a request for help rather than an opportunity for blame, so the meeting should treat each red as information to act on.
- Start with the rolled-up view, not the slides from the green workstreams.
- Ask each red and amber lead what help they need from the group.
- Name the lead and the item in the minutes when someone raised an issue early.
- Close each red item with an action, an owner, and a date.
A line that works in the room: "Thank you for raising [item] before [milestone]. What help do you need from this group to move it to amber?"
Catwatchdog suggests narrative-based reports as an alternative to traffic lights. A narrative can explain a colour, but it can also soften one, so keep the colour and the evidence list beside any narrative.
How do you reward an early red without rewarding false alarms?
Reward an early red by naming the flag, its date, and the evidence in the steering pack and the minutes, so raising a problem is recorded as good practice. Judge the flag by whether it was raised early and honestly, not by whether the risk happened.
Cultivated Notes sets the rule plainly: "Treat red as a request for help, never as an opportunity for blame." Catwatchdog names punishing bad news as a root cause of hidden status, so the reward matters as much as the rule. Pragmatic Coders advises making bad news safe to report early. The steps below are the PMO's own ways to do that:
- Name the early flag in the steering pack: the item, the date it was raised, and the evidence behind it.
- Record the thanks in the minutes, with the lead's name and the milestone the flag protected.
- Ask the lead to present the risk and the help needed at the steering meeting, so raising it earns the same airtime as a success.
Rewarding a flag does not mean accepting every flag as correct. Leave that judgement to the steering chair. A flag that turns out wrong, but was raised honestly and early, still earns the thanks. A lead who raises flags with no evidence attached should be reviewed privately with the chair, not in front of the committee.
How do you check that status reports are honest?
Check honesty at each steering cycle by picking several workstreams and comparing each reported colour with its evidence: milestone dates, blocker ages, and decisions still open. Catwatchdog's dual track, which reports delivery status alongside team health, can show strain that a single colour hides.
At each cycle, also check these points. They are the PMO's own checks:
- A blocker that leaves the list needs a recorded resolution. Ask where it went.
- A workstream that has stayed green for a long time while its blockers grow older should be asked about its colour.
- Add a second line beside each delivery colour that covers team capacity, technical debt, and dependencies, as Catwatchdog's dual track describes.
How do you spot gaming of published colours?
Spot gaming by comparing each colour change with its dated evidence, and by checking when ambers and reds appear against milestone dates. None of the listed sources covers gaming, so these checks are the PMO's own suggestion.
Gaming can look like a colour that changes only in the days before the steering pack, or evidence attached to every green and to no amber or red.
- Compare each colour change with the dated evidence behind it. A change with no dated evidence goes back to the lead before the pack is issued.
- Compare when ambers and reds appear with milestone dates. If reds arrive only after a date is missed, ask what signal came earlier and why it was not raised.
- Over successive cycles, put each lead's colour history beside their blockers and decisions. A workstream that stays green while its blockers grow older is a conversation to hold, not a score to correct.
How will you know the new rules are working?
Track a short set of measures at each steering cycle: how many ambers and reds appear before the milestone they affect, how long each blocker has stayed open, and how many colour changes have dated evidence. Compare each measure across cycles against your own first reading. None of the listed sources reports results from these measures.
These are the PMO's own measures. This guide sets no targets for them and claims no improvement figure. Use the first steering cycle that uses the new template as the baseline.
- Early warning: ambers and reds raised before the milestone they affect, compared with reds that appear only after a date is missed.
- Blocker age: how long each open blocker has been open at every steering meeting, and whether the oldest ones are moving.
- Evidence coverage: colour changes that carry a dated evidence line, compared with those that do not.
- Decisions waiting: decisions still open past the date the steering committee needed them.
Read the measures together rather than one at a time. Treat an odd pattern as a question for the lead, not a verdict on the team. Before the next steering pack, write the colour definitions and the roll-up rule into its template, then record the first set of measures.