A RAG status calculator is useful only when another person can follow its reasoning. A green cell without a source, an evidence date or an agreed rule is still an opinion. This scorecard workflow shows how to carry evidence through to the colour, expose uncertainty and prepare a reviewable status statement without hiding a serious exception inside an average.

Definition

RAG calculator: A RAG calculator applies agreed project status rules to current evidence, producing a colour and an explanation that people can check before using it in a report.

In practice: Keep each dimension visible, apply the worst assessed colour and flag missing evidence separately.

Not the same as: A probability of project success or permission to proceed with delivery.

Start with the existing criteria, then add evidence discipline

The RAG status criteria guide already explains thresholds, worst-of aggregation and a simple one-page calculator. Use that guide to agree the rules. This companion focuses on a different problem: making each assessment traceable when evidence arrives at different times, owners disagree or someone proposes an override. It is a worksheet workflow, so you can use it without installing a web widget.

As of Oct 2026, this is an editorial scorecard method for local adaptation, not an industry scoring standard or a validated prediction model. Agree the dimensions, thresholds, authority and review cadence with the people who will use the report. Do not treat a copied example as approval to change your organisation’s governance arrangements.

Agree the questions before designing the sheet

Choose the dimensions that genuinely describe this project’s delivery confidence. Time, cost, scope, quality and risk may be useful starting points; benefits or critical dependencies may need their own rows. State which rows are required for the reporting cycle. Otherwise, removing a difficult row can make the overall colour improve without anything changing in delivery.

For each dimension, write a rule that distinguishes green, amber and red. Define the input, unit, baseline and boundary conditions. If two rules could apply, state the precedence. If the rules overlap or leave a gap, resolve that before calculating. Keep the rule version with the cycle so a later reviewer can reproduce the result.

Collect the inputs that make the colour defensible

The input checklist is deliberately broader than a metric and a dropdown. Record the cycle date, dimension, criterion version, approved baseline reference, current observation, unit and source reference. Add the evidence date, named evidence owner, next review date and maximum acceptable evidence age. Use the same date convention throughout the pack, including working-day calendars where schedule rules depend on them.

Add confidence factors alongside those inputs: is the source direct or an estimate, has the owner confirmed it, and is there contradictory evidence? Record a short explanation rather than an unexplained confidence score. Identify the affected decision, action owner and due date when a result needs attention. Restricted source material can remain in its controlled location; the shared scorecard needs a usable reference, not a copy of sensitive details.

Check evidence before assigning a colour

Agree an evidence-age limit for each dimension. A cost forecast and a deployment readiness check may need different limits. Evidence is current when its age is within that agreed limit, and it is usable only when the source and observation can be verified. Missing, stale or contradictory evidence needs an explicit review state; it must not silently count as green.

Use “Not assessed” for a required dimension whose evidence or rule is not usable. Keep the last known colour in the historical record, but label it with its date rather than presenting it as the current assessment. A provisional estimate can still inform discussion if clearly labelled. It should not quietly pass the publication check as a verified observation.

Calculate the dimension colours and the overall result

Apply each agreed rule to usable evidence. Encode Green as 0, Amber as 1 and Red as 2 only to make ordering convenient in a spreadsheet. Those codes do not measure distance, likelihood or progress. Never average them: several green rows cannot cancel the red row that needs a decision. Keep the individual colours beside the overall result.

Use an explicit precedence rule. If any current assessed dimension is red, show computed Red and retain any evidence gaps alongside it. If none is red but a required dimension is not assessed, show computed Not assessed. Otherwise take the worst assessed colour. This prevents missing evidence from concealing a known red exception and prevents an incomplete set of green rows from becoming a fully green project.

Keep report readiness separate from the colour. A complete assessment with owner confirmation can be Ready for review; an evidence gap, unresolved contradiction, low confidence or missing recovery action should be Review required. Readiness is an editorial control for the pack, not permission to deliver or an instruction to suppress a material risk. Escalate urgent exceptions even while the report is being checked.

Worked example: a rehearsal that may slip

Illustrative example only: all names, records and dates in this scenario are fictional. A small service project is preparing a rehearsal. For this example, time is green when the forecast meets the approved rehearsal date, amber when it misses that date but meets the agreed fallback date, and red when it misses the fallback too. These are local teaching rules, not recommended universal tolerances.

At the 24 October 2026 reporting cycle, the approved rehearsal is 2 November and the fallback is 5 November. The current forecast is 4 November, supported by the delivery lead’s 23 October plan update. Time is therefore Amber. Scope is Green because the scope owner confirms the current build matches the approved scope record. Quality is Red because a mandatory acceptance check failed and has no accepted resolution.

The cost owner has not supplied the current forecast, so cost is Not assessed. The computed result is Red because the quality exception is already established; the missing cost evidence remains visible. Readiness is Review required. Nobody can infer that the budget is safe from this result. The pack must state both the quality failure and the outstanding forecast.

The next steps are specific: the quality lead will provide retest evidence by 27 October; the cost owner will confirm the forecast by 26 October; and the sponsor will consider a revised rehearsal approach if the retest fails. A later retest can change the quality row, but the reviewer must recompute the whole result and resolve the cost gap before describing the assessment as complete.

Treat overrides as records, not repairs

Show computed and declared status side by side. If someone proposes a different declared colour, record the reason, evidence, authorised approver, approval date and expiry cycle. Keep the original computation intact. An override changes what is declared under an agreed authority; it does not fix a missing input, erase a failed check or update the delivery baseline by itself.

The default declared status should follow the computed result. Where an approved exception allows a different declaration, label it as an override in the narrative. Require a reviewer to check the approval and its continuing validity each cycle. An expired or unsupported override blocks the pack’s readiness check, while any known red exception still requires attention through the agreed escalation route.

Use confidence to direct questions

Low confidence should tell you where to investigate. A supplier promise without a confirmed plan may justify a follow-up question even if the currently entered date meets the rule. Ask what evidence would strengthen or change the assessment. Link the follow-up to the RAID log using the project’s chosen expansion, or to a separate action log, so a narrative concern becomes owned work.

Do not multiply confidence by a colour code to produce a reassuring composite score. Keep the dimensions and the reasons visible. Confidence can be low because a source is old, a forecast is volatile or two owners disagree. Those are different problems with different responses. The worksheet should preserve that distinction instead of making all uncertainty look like one small number.

Turn the result into a useful status paragraph

A concise report states the computed colour, evidence date, main cause, consequence and next decision. For the example: “Computed Red at 24 October: the mandatory quality check failed. Cost remains unassessed pending the current forecast. Retest evidence is due 27 October; the sponsor will review the rehearsal approach if the retest fails.” If AI helps draft that paragraph, use the AI project status-report checklist to check every date, owner and claim against the inputs.

When a single number is the wrong answer

Do not compress safety, legal compliance, a mandatory acceptance condition or an irreversible decision into an average. Use the relevant specialist governance and make the unresolved condition explicit. Where programmes combine dissimilar workstreams, show their separate colours and dependencies. The weakest dimension may be a useful escalation signal, but it is not a complete account of business value or the decision required.

Pause automatic classification when the baseline is disputed, criteria no longer fit the decision or evidence cannot support the rule. Resolve the underlying question with the authorised owner. A transparent Not assessed result can be more useful than a polished colour, provided the gap has an owner, deadline and escalation route. Uncertainty must lead to action rather than disappear from the pack.

Review one reporting cycle before wider use

Run the scorecard alongside an existing report for one cycle and compare the explanations, not just the colours. Ask another person to reproduce each classification from its source and rule. Correct ambiguous boundaries and missing evidence fields, then agree the version to use next time. Return to the RAG criteria pillar when setting or changing thresholds; keep this worksheet focused on evidence and reviewability.