Metric Definition
A single signal for project status
Project health score
A project health score is a single composite number, usually on a 0 to 100 scale, that summarises how a project is tracking against its schedule, budget, scope and quality commitments. It rolls several status signals into one figure so leaders can scan a portfolio quickly and spot the projects that need attention. The value of the score is not the number itself but the components underneath it, which tell you exactly where a project is slipping.
8 min read
What is project health score?
A project health score is a single composite number that summarises how a project is tracking against its schedule, budget, scope and quality commitments. Most teams express it on a 0 to 100 scale, or map it to a red, amber, green status. A score of 85 might mean the project is on track with minor concerns, while a score of 40 signals a project that is materially off plan and needs intervention.
The score exists because leaders cannot read every status report in a large portfolio. A delivery director with forty active projects needs a way to triage. The health score gives them one number per project, sortable and comparable, so they can spend their attention where it matters. It turns a wall of narrative updates into a ranked list.
The risk with any composite score is that it hides as much as it reveals. A project scoring 70 could be perfectly on budget but two weeks behind schedule, or exactly on time but burning cash faster than planned. The number is only useful when you can open it up and see which component pulled it down. That is why the score should always be paired with its underlying drivers rather than reported in isolation.
A project health score should be derived from objective inputs wherever possible. Schedule variance, budget variance and open defect counts come from systems, not opinions. When the score depends entirely on a manager rating the project green, it becomes a sentiment signal rather than a measure, and watermelon projects appear: green on the outside, red on the inside.
How to calculate project health score
A project health score is a weighted average of several component scores, each measuring one dimension of project health on a common scale. The weights reflect what matters most for your organisation. A fixed-price agency might weight budget heavily, while a regulated programme might weight quality and risk above all else. The inputs below are the dimensions most teams include.
- 1
Schedule health
How far ahead or behind plan the project is. A common input is the schedule performance index, which compares work completed against work planned. A project that has delivered 80 per cent of planned work by a given date scores lower than one that has delivered 100 per cent.
- 2
Budget health
How actual spend compares to the budget for the work done. The cost performance index, which divides the value of completed work by what it cost, is the standard input. Spending 120 pounds to deliver 100 pounds of planned value pulls this component down.
- 3
Scope health
Whether the project is delivering what was agreed without uncontrolled growth. High volumes of unapproved change requests, or a backlog growing faster than it is cleared, signal scope problems that erode this component.
- 4
Quality and risk health
The state of open risks, issues and defects. A rising count of high-severity open risks, or defects found late in delivery, lowers this score. This component is where a project that looks fine on schedule and budget often reveals the trouble ahead.
- 5
Weighting
Each component is multiplied by a weight that sums to one across all components. Setting the weights is a deliberate choice about what your organisation considers most important, and it should be consistent across every project so scores stay comparable.
Worked example. Suppose schedule scores 90, budget scores 70, scope scores 80 and quality scores 60, with equal weights of 0.25 each. The health score is (90 x 0.25) + (70 x 0.25) + (80 x 0.25) + (60 x 0.25), which equals 75. The headline of 75 looks healthy, but the quality component at 60 is the one to investigate. The decomposition is what makes the score actionable rather than decorative.
Project health score in a metric tree
A metric tree decomposes the project health score into the four component scores, and each component into the operational signals that move it. This turns a single status number into a diagnostic map. When the score drops, the tree tells you whether the cause is slipping milestones, cost overrun, scope creep or rising risk, and each of those points to a different owner and a different intervention.
The first level splits the score into schedule, budget, scope and quality. Schedule decomposes into milestone slippage and task completion rate. Budget decomposes into cost variance and forecast accuracy. Scope decomposes into change request volume and backlog growth. Quality decomposes into open risk count and defect trend. Each leaf is something a person can actually act on.
The difference between a dashboard and a decision is ownership. A composite score sitting on a portfolio dashboard tells you a project is amber. A metric tree with RACI ownership on each branch tells you that the amber is coming from budget variance, that the project sponsor is accountable for it, and pushes that signal to them the moment it crosses the threshold rather than waiting for the weekly review.
Metric tree insight
Quality and risk is the component that most often leaks ahead of the others. Schedule and budget describe what has already happened, while open risks and defect trends describe what is about to. When you weight the tree to surface the quality branch early, the health score becomes a leading indicator rather than a postmortem.
Project health score benchmarks
There is no universal benchmark for a project health score because the scale and weighting are set per organisation. What matters is a consistent mapping from score to status, applied the same way across every project so scores can be compared and trended. The bands below are a common starting point for a 0 to 100 scale.
| Score band | Status | What it typically means |
|---|---|---|
| 85 to 100 | Green, on track | All components are at or near plan. Minor variances exist but none threaten delivery. The project needs monitoring, not intervention. |
| 70 to 84 | Green to amber, watch | One component is slipping while the others hold. This is the band where early intervention is cheapest. Identify the weak component and act before it pulls the others down. |
| 50 to 69 | Amber, at risk | Two or more components are off plan, or one is materially off. The project needs an active recovery plan and a named owner for each failing branch. |
| Below 50 | Red, off track | The project is materially off plan across several dimensions. Escalation, replanning or a scope decision is usually required. A score in this band that persists is a candidate for a stop or reset review. |
The trend matters more than the absolute band. A project sitting at 72 and rising week on week is in a healthier position than one at 80 and falling. Plot the score over time alongside its components so you can see not just where a project is, but where it is heading and which branch is driving the direction.
How to improve project health score
Improving a health score means improving the weakest component, not nudging the composite. The number rises when the underlying driver is fixed. The most common mistake is treating the score as the thing to manage rather than the symptom to read.
Recover schedule first
When schedule is the weak component, replan the critical path rather than asking everyone to work harder. Reduce parallel work, clear blocked tasks and renegotiate non-essential milestones. Schedule recovery compounds, because slippage early in delivery propagates through every later phase.
Tighten the budget forecast
Budget health often falls because the forecast drifts from reality, not because spend is uncontrolled. Re-baseline the estimate to complete against actual progress, then manage to the new forecast. An accurate forecast that shows a problem early is worth more than an optimistic one that hides it.
Control scope at the gate
Scope health degrades quietly through accumulated small changes. Route every change request through a single approval gate, quantify its cost and schedule impact, and make the trade-off explicit. Saying yes to scope without saying no to something else is how green projects turn red.
Work the risk register
Quality and risk improves when open risks are actively retired, not just logged. Review the high-severity items every cycle, assign each an owner and a closing action, and watch the defect discovery trend for early signs of trouble. A shrinking risk register lifts the component that most often predicts the others.
The metric tree approach to improving a health score starts by ranking the components by the gap between current and target, then acting on the largest gap first. If quality scores 50 and everything else scores 85, the leverage is entirely in the quality branch.
KPI Tree lets you model this by connecting each component of the health score to the team and the action that influences it. The delivery lead owns schedule recovery. Finance owns the budget forecast. The product owner owns the scope gate. The risk owner works the register. With RACI ownership on every branch and a push to the accountable owner the moment a component crosses its threshold, the health score stops being a status report read after the fact and becomes a decision made in time.
Common mistakes when tracking project health score
- 1
Relying on a subjective rating
When the score is just a manager choosing green, amber or red, it reflects optimism rather than reality. Watermelon projects, green on the surface and red underneath, slip through. Anchor as many components as possible to objective inputs from your delivery and finance systems.
- 2
Reporting the composite without the components
A single number with no decomposition tells you a project is troubled but not why. Always pair the score with its component breakdown so the reader can see which dimension is dragging it down and act on it.
- 3
Changing the weighting between projects
If one project weights budget heavily and another weights schedule heavily, their scores are not comparable. Set the weighting once and apply it consistently across the portfolio, otherwise the ranking that the score exists to produce becomes meaningless.
- 4
Ignoring the trend
A static snapshot misses the most useful signal. A project at 75 and falling needs attention before a project at 65 and climbing. Track the score and its components over time, not just at the point of reporting.
Related metrics
Sprint velocity
Agile planning metric
Operations Metrics
Metric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Cycle time
Process speed
Operations MetricsMetric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Deployment frequency
DORA metric
Operations Metrics
Metric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Average resolution time
Customer Support Metrics
Metric Definition
Average Resolution Time = Total Resolution Time Across All Tickets / Total Tickets Resolved
Average resolution time measures the mean elapsed time from when a support ticket is created to when it is fully resolved and closed. It captures the end-to-end customer experience of getting an issue fixed, encompassing wait times, agent work time, escalations, and any back-and-forth exchanges required to reach a solution.
Metric trees for operations teams
Metric Definition
See how a project health score sits alongside the other operational signals an operations team tracks in a single metric tree.
Vanity metrics vs actionable metrics
Metric Definition
Make sure your project health score drives action rather than becoming a single number that looks reassuring but tells the team nothing they can act on.
Build your project health score as a metric tree
Stop reporting a single status number that hides where a project is slipping. In KPI Tree you decompose the health score into schedule, budget, scope and quality, put a RACI owner on every branch, and push each component to its accountable owner the moment it moves. The score becomes a decision, not a dashboard.
