What Is a RAG Report? Red-Amber-Green Status Reporting Explained

A RAG report is a project status document that uses three colours - Red, Amber, and Green - to show at a glance whether work is on track, at risk, or in trouble. It is one of the most widely used reporting formats in UK project management, favoured in government programmes, financial services, professional services, and any organisation running a portfolio of initiatives that a senior stakeholder needs to scan in under 60 seconds.

The format sounds trivial. In practice, most RAG reports are poorly written, inconsistently rated, and quietly ignored by the people they are meant to inform. This guide covers what a RAG report actually contains, how the ratings should be defined, common failure modes, and how modern teams are automating the mechanical parts so status reporting stops eating an afternoon a week.

The origin and purpose of RAG status reporting

RAG - short for Red, Amber, Green - borrows from traffic-light signalling. The Cabinet Office and the Infrastructure and Projects Authority (IPA) formalised RAG (and its extended DCA - Delivery Confidence Assessment - variant with five ratings) as the reporting standard for the UK Government Major Projects Portfolio. The IPA's Annual Report on Major Projects continues to publish DCA ratings for every project above the threshold, and the format has trickled into virtually every large UK organisation as a result.

The purpose is compression. A programme director overseeing 40 workstreams cannot read 40 narrative updates each week. They need a scannable summary that surfaces the things that need their attention and lets them ignore the rest. A well-run RAG report does three things: it flags what is off-track, explains why, and states what is being done about it. Everything else is optional.

The alternative - status meetings where each project lead talks for five minutes - scales badly and produces worse decisions because it rewards whoever is loudest rather than whoever is most at risk. RAG reporting, when the ratings are honest, forces prioritisation.

What the three (or four) ratings actually mean

The core failure mode of RAG reporting is that nobody agrees on what the colours mean. A project manager rates themselves Amber because they are slightly worried; their sponsor reads Amber as "I need to intervene next week." Both are behaving reasonably. Both are wrong, because the definitions were never written down.

Workable definitions look like this:

• Green - On track. Scope, schedule, and budget are within tolerance. Known risks have owners and mitigations. No escalation required. The project lead is not asking for help.
• Amber - At risk. One or more of scope, schedule, or budget is trending outside tolerance, or a material risk has emerged without a credible mitigation. Recoverable with management action within the current reporting period. Escalation for awareness, not intervention.
• Red - Off track. Scope, schedule, or budget has breached tolerance, or a risk has crystallised that the project cannot resolve within its own remit. Escalation for decision, not awareness. A recovery plan is required.

Some organisations add a fourth rating, Amber-Red (or Blue for successful closure, in the IPA's DCA scheme). Amber-Red is useful because it captures the honest middle ground where a project is deteriorating and unlikely to recover without help, but has not yet formally breached tolerance. Without it, project managers cluster at Amber because Red feels like an admission of failure.

Tolerances need to be numeric. "On schedule" is not a definition; "within 10% of baseline duration and within 5% of the current milestone date" is. The IPA's guidance on Delivery Confidence Assessments (available via gov.uk) sets out five-point ratings tied to specific delivery evidence, which is a good template even if you only need three colours.

The anatomy of a good RAG report

A useful RAG report for a single project fits on one page. A portfolio-level report fits on one page per ten projects. Anything longer is a briefing document dressed up as a status update.

The standard structure:

1. Header block

Project name, reporting period, project sponsor, project manager, overall RAG rating, and previous period's rating. The delta between this week's and last week's rating is often the single most important number on the page - a project that has gone Green to Amber in one week deserves more attention than a project that has been Amber for three months.

2. RAG breakdown by dimension

An overall rating is too coarse. Break it down into at least: Schedule, Budget, Scope / Quality, Resources, and Risks and Issues. The overall rating is usually the worst of these, or a weighted judgement if one dimension is dominant.

3. Progress since last report

Three to five bullet points. What actually got done. Not what people were busy with - what shipped, closed, was signed off, or was delivered.

4. Planned for next period

Three to five bullet points. What will be delivered before the next report. These are the items that will show up in "Progress since last report" next week, so they need to be specific enough to be judged.

5. Risks, issues, and decisions needed

The most important section. Any Red or Amber rating must have a corresponding entry here explaining the cause. Any decision the project needs from the sponsor goes here, with a deadline. This is the section senior readers actually read.

6. Financials

Budget approved, spent to date, forecast at completion, variance. Two lines, not a spreadsheet.

Common failure modes and how to avoid them

Most RAG reports fail in predictable ways. Recognising them is half the fix.

Watermelon reporting. Green on the outside, Red on the inside. The project manager reports Green because Red is politically expensive, then the project blows up and everyone is surprised. The fix is a review layer - an independent PMO function, or peer review across project leads - that challenges ratings. The IPA's assurance regime for major projects exists precisely because self-reported ratings drift towards Green.

Ratings inflation. Everyone rates themselves Amber to look diligent without triggering intervention. The fix is a portfolio-level rule: no more than 30% of projects can be Amber, or the definitions get retightened. Forcing distribution surfaces the genuinely at-risk work.

Narrative bloat. The report grows from one page to five pages of "context" because project managers use it to defend themselves. The fix is a hard template with word limits per section. If the template says three bullets, three bullets is the limit.

Stale reports. The report is written on Friday for a Monday meeting and is already 48 hours out of date. The fix is either same-day reporting or, better, automated data collection so the status reflects the current state of Jira, HubSpot, the finance system, and whatever else holds the underlying truth.

Decoupled from action. The report is produced, filed, and never referenced again. The fix is to make the RAG report the input to the sponsor meeting - if the meeting agenda is not driven by the Reds and Ambers, the report has no purpose.

RAG reports at portfolio level

A single-project RAG report is straightforward. A portfolio RAG report - the view a CIO, COO, or programme director actually needs - is harder because it requires consistent ratings across projects run by different people with different appetites for admitting problems.

Portfolio RAG reports typically show a heatmap: projects down the rows, dimensions across the columns (Schedule, Budget, Scope, Resources, Risks), each cell coloured. The overall column is highlighted. A well-run portfolio review spends 80% of its time on the Reds, 20% on the Ambers, and zero on the Greens. If your portfolio review talks about Green projects, either the ratings are wrong or the meeting is wrong.

The IPA's Annual Report on Major Projects (published on gov.uk) is worth reading as a worked example. It rates every major government project on a five-point DCA scale with a written justification for each. Very few UK organisations report at that level of rigour internally, and most would benefit from copying the format.

Automating the mechanical parts

The information in a RAG report already exists in your systems. Schedule variance is in the project plan. Budget variance is in the finance system. Open risks and issues are in a register somewhere. Ticket burndown is in Jira, Linear, or Azure DevOps. The reason RAG reports take three hours to produce is that a human is copying numbers between systems and writing narrative around them.

Modern automation stacks handle most of this. A workflow tool such as n8n can pull scheduled data from project management, finance, and issue tracking systems on a timer, calculate the variances against baseline, and generate a draft report in the correct template. An LLM layer can turn the raw variances into the narrative bullets - "Schedule is Amber because the UAT phase slipped by 6 working days against a 4-day tolerance, driven by delayed sign-off from Legal on the data processing agreement" - which the project manager reviews and edits rather than writes from scratch.

The rating itself should stay human. Automation gets the data on the page and drafts the language; the project manager owns the colour. This split matters because ratings are judgements about recoverability and stakeholder expectation, not calculations, and delegating them to a rule engine produces confidently wrong reports.

Organisations that automate status reporting typically cut the production time from 2-4 hours per project per week to 20-30 minutes of review. On a portfolio of 30 projects that is roughly a full-time equivalent recovered, and - more importantly - the report is generated from live data rather than half-remembered numbers, so the accuracy improves at the same time.

When RAG reporting is the wrong tool

RAG is not universal. It works for defined-scope projects with baselines to vary against. It works poorly for continuous operations (use SLA dashboards instead), for research work where progress is non-linear (use milestone reviews), and for early-stage product development where the whole point is to change direction (use OKRs or similar).

The failure mode is applying RAG to work that has no baseline. If there is no schedule to slip against, no budget to overrun, and no scope to descope, the colours are meaningless. "Green" then means "the person writing this feels okay," which is not a management signal.

Pick RAG when you have a plan and want to know whether reality is diverging from it. Pick something else when you do not have a plan yet, or when the plan is deliberately loose.

Frequently asked questions

What does RAG stand for in project management?

RAG stands for Red, Amber, Green - the three colours used to indicate project status. Green means on track, Amber means at risk, and Red means off track. The format originated in UK government and infrastructure programme management and is now standard across most UK sectors, particularly financial services, professional services, and public sector delivery. Some organisations extend the scheme to four ratings (adding Amber-Red) or five (the Delivery Confidence Assessment used by the Infrastructure and Projects Authority), but the core three-colour version is what most people mean when they refer to a RAG report.

How often should RAG reports be produced?

Weekly is standard for active delivery projects, fortnightly for slower-moving programmes, and monthly for portfolio-level summaries. The cadence should match the rate at which the status can meaningfully change. A construction programme with quarterly milestones does not benefit from weekly reporting; a software delivery running two-week sprints needs at least fortnightly, arguably weekly. The wrong cadence is common - either too frequent (nothing has changed since last week, so the report becomes copy-paste) or too infrequent (problems have escalated by the time they are reported).

Who should write the RAG rating - the project manager or an independent reviewer?

The project manager writes it; an independent function reviews it. Self-rating is unavoidable because the project manager has the context, but self-rating without challenge drifts towards Green because Red is politically expensive. Larger organisations run a PMO or assurance function that reviews ratings weekly and can override them. Smaller organisations can achieve the same effect with peer review - project leads rate each other's projects, which surfaces disagreements quickly. The IPA's approach to major government projects, where independent assurance reviews challenge self-reported ratings, is the reference model.

What is the difference between RAG and DCA?

DCA - Delivery Confidence Assessment - is the five-point scale used by the UK Infrastructure and Projects Authority for major government projects. It runs from Green (successful delivery highly likely) through Amber-Green, Amber, Amber-Red, to Red (successful delivery unachievable). RAG is the simpler three-colour version most organisations use internally. DCA is more granular and captures the honest middle ground better, but requires more discipline to apply consistently. If your organisation is running a large regulated portfolio, DCA is worth adopting; for most commercial teams, three colours plus tight definitions is enough.

Can RAG reports be automated?

The data collection and draft narrative can be automated; the rating itself should stay human. Tools like n8n, Zapier, or custom Python pipelines can pull schedule variance from your project management tool, budget variance from finance, and open risks from a register, then use an LLM to generate the narrative bullets in a fixed template. The project manager reviews the draft, sets the RAG colour based on their judgement of recoverability, and publishes. This typically reduces reporting time by 70-80% and improves accuracy because the numbers come from live systems rather than manual recall.

What should trigger a Red rating?

A Red rating should trigger when the project cannot resolve the issue within its own remit and needs a sponsor decision. Common triggers include: schedule slip that will breach a committed external date, budget overrun that exceeds the project manager's tolerance authority, a scope change that has not been approved through change control, a critical resource departure that cannot be replaced within the timeframe, or a risk crystallising into an issue with material commercial or regulatory impact. If the project manager can fix it themselves within the current reporting period, it is Amber, not Red.

How long should a RAG report be?

One page for a single project, one page per ten projects at portfolio level. The point of RAG is compression - if the report runs to five pages, it has become a briefing document and lost the scannability that makes the format useful. Discipline this with a template that has word limits per section: three to five bullets for progress, three to five for next period, no more than one paragraph per Red or Amber explanation. Anything longer belongs in an appendix or a separate deep-dive document.

Is RAG reporting still relevant with agile delivery?

Yes, but the baseline shifts. Agile projects do not have a fixed end-date to vary against, but they still have committed scope for the current release, a burn-up chart, a budget envelope, and a set of quality metrics. RAG at sprint or release level - are we on track to deliver the committed scope, within the budget envelope, at the required quality - works well. What breaks down is applying RAG to individual sprints as if they were mini-waterfalls; the format is for release or programme-level status, not sprint retrospectives, which have their own tooling.

Getting your RAG reporting right

A RAG report is only as good as the definitions behind the colours, the honesty of the people writing them, and the extent to which the resulting information actually drives decisions. The mechanical work of assembling the data, formatting the page, and drafting the narrative can now be automated with modern workflow tools, freeing project managers to focus on the judgement calls that matter. If you are running a portfolio where status reporting eats hours each week and the reports still feel unreliable, AI Advisory helps organisations automate the data pipeline behind their RAG reporting while keeping the human judgement where it belongs.

Further reading

Sources referenced for context not directly cited in the body:

Ready to put this into production? book a discovery call.

• IPA Annual Report on Major Projects 2022 to 23 - GOV.UK