A green status report hides a red project when the rating is a judgement nobody has to justify, the amber and red rules were never written down, and reporting red brings scrutiny to the person who reports it. To stop this, write the criteria for each color before work starts, let agreed triggers lower the rating without an argument, and agree with the sponsor how a red is raised and what help it brings.
Why does a green status report hide a red project?
A green status report hides a red project for three reasons: optimism about recovery, a rating with no written criteria, and sponsor pressure to keep a committed plan on track. Each can be changed inside the status process you already run.
This guide groups the causes into three. That grouping is editorial framing drawn from the sources below, not a list any one of them gives.
The first cause is optimism. Pragmatic Coders names optimism bias, fear of blame, and vanity metrics as drivers of watermelon reporting. This guide does not measure how much optimism a team has. It sets a rule that does not depend on how confident the reporter feels.
The second cause is sponsor pressure. Rainman Advisory describes executives who had already committed to a project, sold it to the board, and tied their reputation to it. Hearing that it is in trouble creates a conflict they would rather avoid, so the warning gets discounted. A reporter facing that sponsor has a reason to soften the color.
The third cause is unclear criteria. Portfolio Hub puts it directly: a rating anyone can set by feel becomes a rating that means nothing.
Reporting red also brings scrutiny. Rainman Advisory describes the chain: reporting red sets off audits, reviews, and escalations, someone gets blamed, and people learn to report amber or stay green and hope to recover before anyone notices.
Check your own reports for the signs: the same color across several cycles while the forecast keeps moving, an open blocker with no date beside a green row, or a commitment reworded instead of re-forecast.
What makes a RAG rating objective?
An objective RAG rating is one a second person can recheck from written criteria and current data, without asking the reporter what they meant. Portfolio Hub says to rate against the baseline, not the last report. Write the criteria before work starts, so the color follows from the rules rather than from the mood of the reporting week.
The definitions of each color and the wording of its criteria are in Portfolio Hub's RAG guide, so this guide does not repeat them. The same page rates a project by its worst dimension, so green cost cannot offset red schedule, and it asks for a one-line rationale with every color. The sections below cover what makes a color follow from those rules: triggers, checks, and what happens after a red.
Which triggers should lower the status automatically?
Automatic triggers lower the rating when a measurable condition is met, so nobody has to argue for the change. Useful triggers are a milestone forecast past its baseline, an open blocker with no owner or decision date, and a dependency whose predecessor is late. Agree the thresholds with the sponsor at kickoff and write each beside its color.
A trigger is a condition the status report can check without a debate. Pick a few per project and write each one into the status template beside the color it sets. Projectprofit System gives examples of this kind, including a milestone slipping more than 10% of its duration as an automatic red, and a dependency whose predecessor is not done when its planned start is under five working days away. The essay does not explain where those figures come from, so set your own from the length and risk of each project.
| Trigger | Condition | Color it sets |
|---|---|---|
| Milestone forecast | forecast finish is more than [number] days past baseline | amber, then red after [number] days |
| Open blocker | no owner or decision date for more than [number] working days | amber |
| Dependency | predecessor not done [number] working days before planned start | red |
Illustrative: a milestone forecast moves [number] working days past its baseline, so the milestone row above sets amber. Replace [number] with the threshold agreed for that project.
Treat the status field as the output of the rules, not a box filled in by feel. A judgement that moves a color away from its trigger needs a written reason and a second person's review, and the report should show the change.
At kickoff, ask the sponsor to sign off on the baseline and thresholds, as Projectprofit System recommends. During the project, keep a short log of each trigger that fires, with its date and agreed action. That essay calls this a red logbook.
Editorial judgment: a threshold that moves after it nearly fires needs a second look, so change thresholds only at a scheduled review.
How often should the status check run?
Run the trigger check before each status report is written, and keep an interim measure on any milestone that is far off. Checking only at sponsor meetings lets slippage build up between reports. Start each check-in from the trigger record, not from a new narrative.
Rainman Advisory recommends shorter checkpoints, so that a milestone is never far away with no interim measure. A narrative update cannot replace a measured check. Use these questions with the project lead at each check-in:
- Which trigger is closest to firing, and when will we know?
- What changed since the last report?
- What decision or help would move the rating, and from whom?
Rainman Advisory also suggests asking, "What's the worst thing nobody is telling me?" Ask it one-to-one, and treat the answer as a prompt for evidence, not a verdict.
Who checks a proposed rating against outside evidence?
The PMO checks a proposed rating against a record the reporter does not write, such as finance actuals, the delivery tool's history, or the forecast in earlier reports. Have the project manager propose the rating and the PMO validate or challenge it. Where the record and the report disagree, start the conversation from the record.
Portfolio Hub gives the project manager the proposal and the PMO the challenge. The same page cross-checks colors against CPI, SPI, and milestone slippage, so a green row can be tested against the numbers beside it.
Before a green is accepted, run these checks:
- Compare any reported percentage complete with a count from the delivery tool, such as items closed against items planned.
- Compare the forecast finish with the forecast in the last [number] reports. If the date has moved while the color stayed, the color needs a written reason.
- Log each change to a trigger threshold with the date, the reason, and who approved it.
- Ask which trigger was checked, what the finance or delivery record shows for the same period, and what changed since the last report.
Once a team knows a threshold, it may adjust inputs or wording to stay under it. Check each trigger against the record, not against the reporter's summary, and compare more than one source before a rating changes. This point is editorial judgment, not a finding from the sources.
Check the thresholds on a regular basis. Portfolio Hub offers a rough test: more than about 70% green suggests thresholds may be too loose, and more than about a quarter red suggests they may be too tight. The page does not source either figure, so use the test to prompt a review of the criteria, not as a target.
How do you raise red with the sponsor without losing credibility?
Raise red early, in writing, before the next status report goes out, and name the trigger that fired, the evidence, and the decision you need with its date. Projectprofit System puts the principle as red brings help, not investigation. A red with a clear request gives the sponsor something to act on.
Pragmatic Coders makes a related case from delivery work and says to reward early red. Use this as the first message:
Subject: [project name]: rating moves to red
[Sponsor name],
The [project name] rating moves from [current color] to red in the current status report. The trigger that fired is [trigger, as agreed at kickoff]. The evidence is [link].
What is driving it: [one or two plain sentences of fact].
The decision I need from you is [decision or help needed] by [date]. Without it, [specific effect] is likely by [date].
Our next step is [action], owned by [name], due [date]. I will send you an update by [date], whether or not the rating changes.
[Your name]
Three mistakes weaken credibility:
- The red goes out with no request attached.
- The message names a person instead of the trigger.
- A criterion is changed after it has fired, so the color can stay green.
Each one turns a status change into a dispute about the process.
What happens after a red is reported?
After a red is reported, the PMO confirms the trigger, the decision owner is named with a date, and the team returns with an update on a set date. Portfolio Hub defines red as a status where the project has broken its commitments and needs intervention now.
- Confirm the trigger. The PMO checks the record against the criteria written at kickoff. Once a trigger has fired, the reporter does not change the threshold to clear it.
- Name the decision owner. Write the decision or help the red needs next to one name, [name], and the date it is needed, [date].
- Set the escalation date. If no answer arrives by [date], take the same evidence to the next person in the chain. Do not write a new explanation.
- Review what the team needs. At the next review, ask what help, decision, or resource would move the rating. Projectprofit System puts the principle this way: red brings help, not investigation.
- Keep accountability separate. If a missed commitment needs a review of individual performance, hold that conversation apart from the status review. Mixing the two makes the next red harder to raise.
If the sponsor disputes a trigger that has fired, the criterion written at kickoff decides the color. Take the disagreement to the next review with the trigger and the evidence, and record the outcome.
Where should the decision request for a red item go?
Put a red item's decision request where the sponsor can answer it and the team can follow it up: one named decision, one deadline, and one reply path. Keep the same request in the status report until the sponsor answers, so the open item stays visible.
Unblockd sends asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
Whichever tool you use, check at each status update whether every open request has an answer, a reminder date, or an escalation path.
What if the project has no baseline or no fixed dates?
Take the first plan the sponsor agrees to, or the sprint goal for a team that works in sprints, as the baseline. Record it at kickoff and rate against it. The baseline advice here is editorial judgment, because the sources in this guide do not cover projects without a baseline or agile teams.
Portfolio Hub rates against a baseline, so a project without one needs a substitute before its triggers can work. Use these steps:
- At kickoff, write down the first plan the sponsor agrees to: the milestones and their [date] targets, or the sprint goal the team commits to.
- Date that record and keep it where each status report can link to it.
- Rate each deliverable against that record, not against the last report.
- When the plan changes, record the new plan with the reason and who approved it, so the original baseline stays visible.
For sprint work, measure against the sprint goal and the items the team committed to. Set a trigger on committed items that have not moved for [number] sprints.
What should you do before the next status report?
Start with the one project that has stayed green longest while carrying an open blocker. Write its triggers into the status template, agree them with its sponsor, and check the color against the record before the next status report goes out.
- Check that project's color against its written criteria and the record it is based on.
- Write its triggers into the status template and agree them with its sponsor.
- If a trigger has fired, send the red message above before the next status report goes out.