RAG status is a rating that marks a project red, amber, or green to show its health at a glance. Green means it is on track and needs nothing from you. Amber means it is at risk and needs attention or a decision. Red means it has broken its commitments and needs intervention now. That is the whole convention, and it is the single most common way PMOs summarize a portfolio for executives who will never read the detail.
It is also the most abused. A rating that anyone can set by feel becomes a rating that means nothing, which is how organizations end up with portfolios that are 90% green and still miss every date.
Key takeaways
- RAG stands for red, amber, green. It is a traffic-light rating of project health, not a measure of progress.
- The rating is only useful if the criteria are written down and objective. "Amber if the forecast finish slips more than two weeks" is a criterion. "Amber if the PM is worried" is not.
- Rate against commitments, not against effort. A team working heroically to recover a slipped date is still red.
- Watch for watermelon projects: green on the outside, red on the inside. They are the direct product of a culture where reporting red is punished.
What does RAG stand for in project management?
RAG stands for red, amber, green. It borrows the traffic-light metaphor to compress a project's health into one color that an executive can scan in a second. The term is standard in UK and European project management and increasingly common in US PMOs, where you will also hear the same thing called a traffic-light status or a health indicator.
RAG status colors and what each one means
The colors are only worth something if everyone agrees what triggers them and what each one obliges the organization to do. This is the definition set I would put in a reporting standard.
| Color | What it means | Typical trigger | What it obliges |
|---|---|---|---|
| Green | On track against scope, schedule, and budget. Issues exist but the project manager can handle them. | Forecast finish and forecast cost are within tolerance. | Nothing. Note it and move on. |
| Amber | At risk. A commitment will be missed unless something changes, but there is a credible recovery plan. | Tolerance breached, or a live issue with no owner or no date. | A named action, an owner, and a date. Reviewed next cycle. |
| Red | Off track. A baseline commitment will be missed and the project cannot recover on its own. | Forecast breach beyond recovery, or a blocked dependency, or funding gone. | An escalation and a decision: more money, less scope, later date, or stop. |
Swipe to see more →
Some organizations add blue for complete and grey for not started. Some split amber into amber and amber-red. Resist that. Every extra color is one more thing to argue about, and the argument is never the point.
How do you set RAG status criteria?
Write thresholds against the things the project committed to, then apply the worst score across all dimensions as the overall rating. A project that is green on cost and red on schedule is red overall. Rolling those into a comfortable amber is how bad news gets laundered.
A workable criteria set looks like this. The tolerances are illustrative, set your own to fit your risk appetite.
| Dimension | Green | Amber | Red |
|---|---|---|---|
| Schedule | Forecast finish within 2 weeks of baseline | 2 to 6 weeks late, recovery plan exists | More than 6 weeks late, or no credible recovery |
| Cost | Forecast within 5% of budget | 5% to 10% over, mitigation identified | More than 10% over, or funding not secured |
| Scope | Agreed scope intact | Change request pending approval | Scope cut or contested with no decision |
| Resources | Team in place | A key role vacant with a start date | A key role vacant with no candidate |
| Risk | No high risks without mitigation | A high risk with an owner and a plan | A high risk realized, or a blocked dependency |
Swipe to see more →
Two rules make this stick. First, rate against the baseline, not against the last report, or a project can slip two weeks every month and stay green forever. Second, the rating describes the project, not the team. A team doing outstanding work on a project that has lost its funding is still red.
RAG status examples
What separates a useful status report from decoration is the one-line rationale next to the color. Three illustrative examples, written the way I would want to receive them:
| Project | Status | Rationale (this is the part that matters) |
|---|---|---|
| CRM migration | Red | Data migration testing found 12% record mismatch. Go-live of Sept 30 is not achievable. Options paper for the steering committee: delay 6 weeks or cut the historical data load. |
| Warehouse automation | Amber | Integration engineer resigned, replacement starts Aug 18. Two weeks of float absorbed, none left. Green again if the start date holds. |
| Payroll upgrade | Green | On baseline for cost and date. Vendor patch slipped a week, absorbed in float. No decision needed. |
Swipe to see more →
Notice that each rationale names the breach, the impact, and the ask. A status line that reads "amber, some challenges with resourcing" tells an executive nothing and wastes the meeting.
How do you calibrate RAG thresholds to your own portfolio?
Scale the thresholds to project duration and to how much data you actually have. A fixed "six weeks late is red" rule punishes a three month project and lets a three year program slip a quarter while still reporting amber. Express schedule tolerance as a share of remaining duration, then check the resulting distribution against your own history.
Here is the same schedule dimension from the criteria table above, rewritten so it scales. The percentages are a starting band to argue with, not a standard.
| Project length | Green | Amber | Red | Why it differs |
|---|---|---|---|---|
| Under 3 months | Within 3 days of baseline | 4 to 10 days late | More than 10 days late | There is no float to absorb a two week slip. By the time it shows, the project is over. |
| 3 to 9 months | Within 2 weeks | 2 to 5 weeks | More than 5 weeks | The common case, and where most published thresholds are silently aimed. |
| 9 to 18 months | Within 4 weeks | 4 to 10 weeks | More than 10 weeks | Longer projects genuinely recover from slips, so tight bands produce noise rather than signal. |
| Over 18 months | Within 5% of remaining duration | 5% to 12% | Over 12%, or the next gate is unreachable | Absolute weeks stop meaning anything. Rate against the next gate, not the end date. |
Swipe to see more →
Then run the distribution test, which is the fastest way to find out whether your thresholds are doing any work. Pull last quarter's ratings and count them. If more than about 70% of your portfolio is green in a typical month, the thresholds are too loose and the scale has stopped carrying information. If more than about a quarter is red, they are too tight, and what happens next is predictable: red becomes normal, executives stop reacting to it, and the ratings get quietly renegotiated in the corridor before the meeting.
Maturity matters more than people expect here. A portfolio office in its first year usually has no reliable baselines to measure against, so tight numeric thresholds produce ratings that are precise and wrong. Start with the wider bands, publish the criteria anyway so the rating is not a personal judgment, and tighten them once you have two or three quarters of real forecast data to calibrate against. Tightening a threshold with evidence is an easy conversation. Loosening one after everything went red is not.
Why the direction matters more than the color
A color is a snapshot, and a snapshot loses the one thing an executive needs, which is whether the situation is getting better or worse. Add a direction to every rating: improving, stable, or deteriorating since the last report. It costs one column and it changes which projects get attention.
| Color and direction | What it actually means | The right response |
|---|---|---|
| Green, deteriorating | The most under-read cell on any dashboard. Still inside tolerance, but heading out of it. | Act now, while it is cheap. This is the only point where a small intervention still works. |
| Green, stable | Genuinely fine. | Nothing. Do not spend meeting time here. |
| Amber, deteriorating | A project on its way to red, usually within two reporting cycles. | Treat as red. Ask for the decision now rather than watching it arrive. |
| Amber, improving | The recovery plan is working. | Leave it alone and check the date it returns to green. |
| Red, improving | Already escalated, already being fixed. | Confirm the recovery date. Adding scrutiny here slows the fix. |
| Red, stable | Escalated and not moving. The worst cell in the table. | The escalation did not produce a decision. Find out who owes one. |
Swipe to see more →
Most status meetings spend their time on red and stable, which is the one state where more discussion rarely helps, and skip green and deteriorating entirely because the color looks fine. Sorting the report by direction rather than by color redistributes the meeting toward the projects that can still be saved cheaply.
What is a watermelon project?
A watermelon project is one that reports green on the outside while being red on the inside. It looks healthy on the dashboard right up to the moment it fails, usually late, usually in public, and usually to the surprise of no one who was actually doing the work.
Watermelons are not a reporting problem, they are a culture problem. They appear wherever reporting red gets a project manager interrogated and reporting green gets them left alone. The fix is not a better template. It is a PMO that treats an early red as good news, because an early red is the only kind you can still do something about. Practical countermeasures:
- Make the criteria objective, so the rating is calculated rather than negotiated.
- Have the PMO set or challenge the rating, not just collect it.
- Cross-check the color against hard data: milestone slippage, and cost indices such as earned value CPI and SPI. When a project reports green with a CPI of 0.78, the number is right and the color is wrong.
- Track how long projects sit at amber. An amber that never moves is a red that nobody wants to declare.
- Reward the project manager who goes red early and recovers. Publicly.
Who decides the RAG status of a project?
The project manager proposes the rating and the PMO validates or challenges it before the report goes to the board. That split matters. If the PM alone owns the color, optimism creeps in. If the PMO alone sets it, the PM stops owning the truth of their own project.
Where there is real disagreement, escalate the disagreement itself. A report that says "the project manager rates this amber, the PMO rates it red, here is why" is more useful to a steering committee than any consensus color that gets negotiated in a corridor beforehand.
How do you show RAG status in Excel?
Use conditional formatting on a status column. Enter the rating as text (R, A, G, or Red, Amber, Green), then apply a rule that fills the cell with the matching color, so the rating is typed once and rendered automatically rather than colored by hand.
The steps in Excel:
- Create a Status column and restrict it with Data Validation to Red, Amber, Green so nobody invents "amber/green".
- Select the column, then Home, then Conditional Formatting, then New Rule, then Format only cells that contain.
- Set the rule to Specific Text, containing, Red, and choose a red fill. Repeat for Amber and Green.
- Add a second column for the rationale and make it mandatory. A color with no reason is not a status.
Add a trend column too, showing last period's color, so the board can see a project that has been amber for four months. The direction of travel is often more informative than the color itself. If you are building the wider view, the project portfolio dashboard guide covers the full layout, and the capacity planning template covers the resource side of the same spreadsheet.
What is the difference between RAG status and a KPI?
A RAG status is a judgment about one project's health at one point in time. A KPI is a measured quantity, tracked over time, usually across the whole portfolio. RAG answers "does this need my attention today", KPIs answer "is the portfolio getting better or worse".
They work together. RAG statuses aggregate into a portfolio KPI (the count or percentage of red projects is one of the most watched measures a PMO reports), while KPIs such as CPI and schedule variance are the evidence that keeps individual RAG ratings honest. The full set is covered in project portfolio management KPIs and metrics.
How often should RAG status be updated?
Weekly for project teams, monthly for the portfolio report to executives. That is the cadence that fits most organizations: the team needs a rhythm short enough to act on, the board needs one long enough that the picture has actually changed since last time.
The exception is a red project. Once a project goes red it should report on its recovery plan every week until it is amber or green again, or until the board stops it. Anything less and red becomes a resting state rather than a call to action. The wider reporting rhythm is covered in PMO reporting, and the forum where red projects actually get resolved is the portfolio review meeting.
How do you roll up project RAG status to a portfolio rating?
Do not take the worst project and do not take an average. Worst-of makes the portfolio permanently red once it holds forty projects, and averaging makes a color out of numbers that were never numbers. Roll up on materiality: rate the portfolio on the projects that carry the strategy, the spend, or the dependencies.
| Rollup method | What it does | Verdict |
|---|---|---|
| Worst of all projects | Portfolio is red if any project is red. | Fails above roughly fifteen projects. There is always one red, so the rating never changes and stops being read. |
| Average the colors | Convert to 1, 2, 3 and take the mean. | Avoid. It invents arithmetic on an ordinal scale, and it lets thirty greens hide the one project that matters. |
| Count and trend | Report the count in each color plus the change since last period. | Good as a companion, not as a rating. "4 red, up from 2" is a real sentence. |
| Weighted by budget | Red on the share of portfolio spend that is red. | Reasonable for a cost-driven portfolio. Blind to small projects that block large ones. |
| Material projects only | Rate on the named set that carries the strategic objectives, then report the rest by exception. | The one that survives contact with a real portfolio board. Requires you to name the set in advance, in public, which is the point. |
Swipe to see more →
The last method has a defense the others lack: because the material set is agreed before anyone knows the ratings, nobody can argue a project into or out of it after the fact. Review the list quarterly, not monthly, and keep it small enough that the board can hold it in mind, which in practice means somewhere between six and twelve projects however large the portfolio is.
Report the rest as counts with a trend and let exceptions surface themselves. A project outside the material set that goes red twice in a row should either join the set or be examined for whether it should still be running at all, which is a question for portfolio governance rather than for the status report. The mechanics of presenting all of this on one page belong in the portfolio status report.
Getting RAG status to earn its place
The convention survives because it works: one color, scanned in a second, telling a busy executive where to look. It fails when the color stops being tied to anything real. Write the criteria down, apply the worst dimension as the overall rating, put a one-line rationale next to every color, and check the greens against hard numbers from your risk register and RAID log. Do that and a portfolio full of greens becomes a fact rather than a hope.