RAG Status Criteria: Thresholds You Can Compute

Someone asks for the RAG. You look at a late milestone, a thin contingency and a sponsor who wants “green for the pack”. Ten minutes later the slide is green. The plan is not.

RAG status criteria work when each colour maps to a rule you can compute from plan data, every override is logged, and every non-green status has an explicit road to green. This guide gives you starting thresholds, a one-page Excel-style calculator and a short SteerCo narrative. Treat the numbers as a draft to agree with your board—not as a universal standard.

Definition — RAG status criteria: the agreed rules that turn project data (time, cost, scope, risk, benefits) into Red, Amber or Green. Good criteria are computable, use worst-of aggregation (not averages), log overrides, and require a road to green whenever status is not Green.

If reporting itself is the bottleneck, pair this with how to reduce project reporting time. If money is the driver, see what happens when a project goes over budget.

What RAG Is For (And What It Is Not)

RAG (Red / Amber / Green) is a status signal for decision makers. It is not a forecast, not a risk score on its own and not a substitute for the underlying schedule, cost and issue records.

Green: within agreed tolerances; no escalation required this cycle.
Amber: outside at least one soft threshold, or on a path that will breach soon without action; management attention needed.
Red: outside hard tolerance, or recovery needs a decision the project manager cannot take alone (scope, money, date, risk appetite).

In PRINCE2 language, RAG should line up with management by exception: you escalate when tolerances are forecast to break, not when a slide needs a warmer colour. Your SteerCo pack should say what you need—not only how you feel. See also steering committee basics.

Starting Thresholds You Can Type Into Excel

The bands below are example starting points for a single project reporting weekly to a SteerCo. Agree them in writing. Change them for portfolios, regulatory programmes or fixed-date events. Do not treat them as industry averages—they are not.

Dimension	Input (example)	Amber if…	Red if…
Time	Days of float on the critical path (or days late vs baseline finish)	Float < 10 working days, or forecast finish 6–15 days late	Float ≤ 0, or forecast finish > 15 days late
Cost	Estimate at completion vs budget (including agreed contingency policy)	EAC within 5–10% over approved budget	EAC > 10% over approved budget, or contingency exhausted with further overspend forecast
Scope / change	Open change requests affecting baseline	Material changes open without SteerCo decision date	Unapproved scope in delivery, or baseline no longer matches what is being built
Risk / issue	Highest open risk score or issue severity (your scale)	One “high” item without an owner and next review date	One “critical” item, or several highs blocking the next milestone
Benefits (if tracked)	Confidence that benefits assumptions still hold	Key assumption invalidated; replacement not agreed	Benefits case no longer credible and no reset path

Overall project RAG: take the worst dimension RAG among the dimensions you agreed to report. Do not average colours. Averaging hides the exception that needs a decision.

The One-Page Calculator (Copy Into a Sheet)

Create one row per reporting cycle. Keep formulas boring so anyone can audit them.

Cell / column	What you enter or calculate
A — Cycle date	Reporting date
B — Baseline finish	Agreed baseline end date
C — Forecast finish	Current forecast end date
D — Days late	`=C-B` in working-day logic you already use (or calendar days if that is your standard)
E — Time RAG	Nested IF from the time row in the table above
F — Budget	Approved budget (state whether contingency is inside)
G — EAC	Current estimate at completion
H — Cost variance %	`=(G-F)/F`
I — Cost RAG	IF from the cost row
J–L — Scope / risk / benefits RAG	Manual but rule-based (dropdown: Green / Amber / Red)
M — Computed RAG	Worst of E, I, J, K, L
N — Declared RAG	What you will put on the slide (defaults to M)
O — Override?	Yes / No
P — Override reason + approver	Mandatory if O = Yes
Q — Road to green	One sentence + owner + date (mandatory if N ≠ Green)

That sheet is the calculator for version one: transparent, portable and reviewable in a SteerCo pack. An interactive web widget can wait until the rules are stable.

Worked Example (Illustrative Numbers Only)

Suppose baseline finish is 30 working days away, forecast finish is 22 days of float consumed with 5 days of float left, EAC is 7% over budget, and one high risk has an owner and a review this week.

Time → Amber (float under the 10-day soft band in the starter table).
Cost → Amber (7% sits in the 5–10% band).
Risk → Green under the starter rule (high item has owner + review date).
Computed RAG → Amber (worst of the set).

Declared RAG should stay Amber unless someone with authority overrides and logs why—for example, temporary cost pressure already funded by an approved change that the EAC field has not yet reflected. If you override to Green without fixing the inputs, you are doing watermelon reporting: green outside, red inside.

Override Log (Non-Negotiable)

Overrides happen. Sponsors ask. Politics exists. The failure mode is an override with no memory.

Minimum fields when Declared RAG ≠ Computed RAG:

Date and reporting cycle
Computed vs declared colour
Reason in one sentence (fact, not hope)
Approver name and role
Expiry: which future cycle the override dies unless renewed

If you cannot name an approver, you do not have an override—you have a wrong status.

Road to Green

Every Amber or Red needs a recovery path that a stranger can understand in thirty seconds:

Cause: which dimension tripped the rule
Action: what changes in the plan (not “monitor closely”)
Owner: one name
Date: when the action lands, and when RAG should be re-computed
Ask: what decision you need from SteerCo, if any (money, scope, date, risk acceptance)

For messy recoveries, the practical reset moves in how to bring order to a messy project sit beside this RAG discipline—not instead of it.

How to Roll This Out in One Week

Draft thresholds with the project board or PMO (use the starter table).
Build the one-page sheet; lock column meanings.
Run one cycle in parallel with your old slide colour—compare Computed vs Declared.
Agree the override rule in SteerCo minutes.
Retire gut-feel colouring for that project.

Checklist Before You Send the Pack

Every dimension has a stated input and rule
Overall RAG is worst-of, not average
Computed and declared colours are both visible
Overrides have approver and expiry
Non-green has cause, action, owner, date, ask
Numbers in the RAG sheet match the schedule and cost files you would defend in the room

FAQ

What does RAG mean in project management?

RAG means Red, Amber and Green. It is a status signal for decision makers, not a forecast by itself. Each colour should map to a rule you can recompute from the same inputs every cycle.

How do you set RAG status criteria?

Agree dimensions (at least time and cost), set Amber and Red thresholds per dimension, take the worst dimension as overall RAG, require an override log when the slide colour differs from the computed colour, and require a road to green for every non-green status.

Should you average RAG colours across workstreams?

No. Averaging hides the exception that needs a decision. Use worst-of for the project overall, and show workstream RAGs separately if needed.

RAG Status Criteria: Thresholds You Can Compute (With a Simple Calculator)