Updated · All guides
The short answer
RAG status is an opinion: a project manager picks green, amber or red. A project risk score is a calculation: a number from 0 to 100 built from signals in the project data, such as overdue work, blocked work, team overload and schedule performance. Keep the familiar colours, but derive them from the score, and show the inputs behind every number so anyone can check why a project turned amber.
Why RAG status hides risk
- It is self-reported. Reporting red invites scrutiny, so projects stay green until the problem cannot be hidden, then jump straight to red. These are the "watermelon" projects: green outside, red inside.
- Every project manager defines it differently. One person's amber is another's green, so colours cannot be compared across a portfolio.
- It has no cause attached. "Amber" does not say whether the problem is blocked work, an overloaded team or a slipping plan, so leaders cannot tell how to help.
- It has no trend. A project drifting from barely green to nearly amber looks exactly the same as last week.
The signals behind a risk score
Each signal is measured as a percentage from 0 to 100, so they can be combined. Most come straight from Jira:
| Signal | How to measure it (0–100) |
|---|---|
| Overdue work | Open items past their due date ÷ open items. JQL: project = ABC AND statusCategory != Done AND duedate < now() |
| Blocked work | Blocked items ÷ all items. JQL depends on your workflow, for example project = ABC AND (status = Blocked OR Flagged is not EMPTY) |
| Team overload | People allocated beyond their capacity, across all their projects ÷ people on the project |
| Schedule performance | How far behind plan the work is. With earned value: (1 − SPI) × 100 when SPI is below 1 |
| Cost performance | How far over budget the work is: (1 − CPI) × 100 when CPI is below 1 |
| Team activity | Share of the team whose tracked activity has dropped, where activity is tracked |
Schedule and cost performance need estimates and a baseline plan. When most work is unestimated, leave them out rather than guess. The other signals still give a useful score.
Build one in a spreadsheet
- Measure each signal as a percentage, as in the table above.
- Choose weights that add up to 100, reflecting what predicts trouble in your organisation.
- Calculate the score: multiply each signal by its weight, add them up and divide by 100.
- Set bands that map the score to colours, for example green below 40, amber 40–69, red 70 and above.
- Show the breakdown. List each signal's contribution next to the score, so the biggest driver is obvious.
Here is an example with illustrative weights for a project of five people:
| Signal | Value | Weight | Contribution |
|---|---|---|---|
| Overdue work | 45 (9 of 20 open items) | 30 | 13.5 |
| Blocked work | 30 | 25 | 7.5 |
| Team overload | 60 (3 of 5 people) | 25 | 15.0 |
| Schedule performance | 40 (SPI 0.6) | 20 | 8.0 |
| Risk score | 100 | 44: amber |
The colour alone says "amber". The breakdown says more: team overload is the biggest driver, so moving work or people will help more than chasing overdue tickets. That is the conversation RAG status never starts.
Making the score trusted
- Calibrate it. After a few weeks, compare scores with the projects that actually slipped. Adjust weights and bands once, centrally, not per project.
- Use one model for the whole portfolio. The point is that amber means the same thing everywhere.
- Let people add context, not overrides. A project manager's note ("blocked items are waiting on a vendor fix due Friday") belongs next to the score. Silently changing the colour brings back the problem the score solves.
- Report the trend. A score rising from 25 to 38 over three weeks is an early warning, even though it is still green.
- Keep forecast confidence separate. A low risk score on a project with no due dates is not good news. Rate data quality on its own, as described in how to forecast a delivery date from Jira.
Common objections
- "Our project managers know more than the data." Often true, which is why their commentary sits next to the score. The score makes sure the signals are seen even when the commentary is optimistic.
- "Our Jira data is incomplete." Score what you have. Overdue work, blocked work and overload need no estimates, and missing data should lower confidence visibly.
- "People will game the numbers." Gaming a due date or a blocked flag is harder and more visible than choosing a colour, and the breakdown shows exactly what changed.
How Exentras scores project risk
Exentras calculates a 0–100 risk score for every project from your Jira Cloud data and team allocation: team overload across the whole portfolio, blocked work, overdue work, schedule and cost performance, and team activity where it is tracked. Scores below 40 are green, 40–69 amber and 70 or above red, the same bands on every page and in the weekly executive brief.
Each score comes with a breakdown of every factor's value, weight and contribution, and the top bottlenecks are listed in order. When fewer than 40% of work items are estimated, schedule and cost performance are left out and the score is calculated from the remaining signals. The engines are rule-based and weights are set centrally, so a score means the same thing on every project. What is software delivery intelligence?