Project health metrics: what to track and what to ignore
Not all project metrics are worth tracking. Here is how to identify the health signals that predict delivery success and stop measuring activity over progress.
Project health metrics exist to answer one question: is this project going to deliver what it promised, when it promised? Everything else is context.
Most teams track too many metrics and act on too few. They have dashboards showing task completion rates, hours logged, budget burn, risk counts, and a dozen other numbers. But when asked "is this project healthy?" they still rely on gut feel because none of the metrics give a clear answer.
The problem is not a lack of data. It is a lack of signal. The right health metrics are leading indicators that predict problems before they become crises. The wrong ones are lagging indicators that confirm what everyone already knew.
Leading vs lagging indicators
The most important distinction in project health metrics is between leading and lagging indicators.
Lagging indicators tell you what already happened. "This project was delivered two weeks late" is a lagging indicator. It is useful for retrospectives but useless for intervention.
Leading indicators tell you what is about to happen. "This project's next milestone is at risk because two dependencies are unresolved" is a leading indicator. It gives you time to act.
Most project dashboards are full of lagging indicators because they are easy to measure. Leading indicators require more thought to define but are far more valuable for project governance.
The five health metrics that matter
1. Milestone trajectory
Are milestones being hit on time? More importantly, is the next milestone on track? Milestone trajectory is the strongest predictor of overall project health because milestones represent meaningful progress, not just activity.
Track: percentage of milestones delivered on time over the last three periods, and the status of the next upcoming milestone.
2. Risk count and trend
How many open risks does the project have, and is that number growing or shrinking? A project with a rising risk count is deteriorating even if the tasks are getting done.
Track: number of open risks, number of new risks added this period, and number of risks resolved this period.
3. Decision velocity
How quickly are decisions being made when they are needed? A project that is waiting for decisions is a project that is stalling. Decision velocity measures whether governance is keeping up with the work.
Track: number of open decisions awaiting resolution, and average time from decision request to resolution.
4. Scope stability
Is the scope changing? Some change is normal, but frequent scope additions without corresponding timeline or resource adjustments indicate a project that is growing beyond its original commitment.
Track: number of scope changes this period, and whether timeline and resources were adjusted to match.
5. Team confidence
This is the most subjective metric but often the most accurate. Does the project team believe they will deliver on time and on scope? A simple weekly confidence check (high, medium, low) often surfaces problems before they show up in the objective metrics.
Track: weekly team confidence rating, and the trend over the last four weeks.
Metrics you should stop tracking
Task completion rate. The number of tasks completed tells you nothing about whether the right tasks are being done or whether the project is on track. A team can complete fifty tasks and still miss a milestone.
Hours logged. Unless you are billing by the hour, time tracking does not predict project health. A team can log the right number of hours and still be working on the wrong things.
Percentage complete. This is the most misleading metric in project management. A project that is "80% complete" may have 80% of the easy work done and 100% of the hard work remaining. It creates false confidence.
Number of status updates. Measuring whether people submit updates measures compliance, not health. If you need to track this, the update process is too burdensome.
How to use health metrics effectively
Define thresholds. For each metric, define what green, amber, and red look like. "Milestone adherence above 80% is green, 60–80% is amber, below 60% is red." Without thresholds, metrics are just numbers.
Act on amber, not red. The value of leading indicators is that they give you time to intervene. If you only act when a project turns red, you have already lost the window for easy correction.
Review weekly. Health metrics should be reviewed weekly at the project level and rolled up to the portfolio level. Monthly is too infrequent for intervention.
Keep it visible. Health metrics should be on the project dashboard, visible to the team and stakeholders. Hidden metrics do not drive behaviour.
Combine objective and subjective. The objective metrics (milestones, risks, decisions) tell you what is happening. The subjective metric (team confidence) tells you what the team believes is about to happen. Both are valuable.
Real-world example
A digital agency was tracking twelve metrics per project: task completion, hours logged, budget burn, risk count, issue count, change requests, client satisfaction, team utilisation, milestone status, scope changes, quality defects, and stakeholder engagement.
Nobody could tell from the dashboard whether a project was healthy. The metrics were all green on a project that was clearly struggling because the team was completing tasks but missing the point.
They stripped it down to four metrics: milestone trajectory, risk trend, decision velocity, and team confidence. Within a month, the project managers were making better decisions because the signal was clear. Two at-risk projects were caught early because the team confidence metric dropped before the objective metrics showed problems.
How Praxiox helps
Praxiox tracks project health through milestones, risks, and status indicators that roll up to the portfolio dashboard automatically. When a milestone slips or a risk is flagged, the project health reflects it without manual intervention.
The portfolio view shows health distribution across all projects, making it easy to spot patterns and intervene early. Meeting records capture decisions and track decision velocity as part of the governance cadence.
For teams building a health metrics practice, the features page shows how health indicators work in the portfolio dashboard. The PMO KPIs guide provides the portfolio-level perspective on which metrics drive decisions.
A practical rollout
The easiest way to introduce this kind of workflow is to treat it as a habit change, not a documentation exercise. People adopt what saves them time. They ignore anything that adds ceremony without changing the work itself.
That means the first goal is not full coverage. It is one visible win that shows the new approach is lighter than the old one. If the team can feel the difference in the first cycle, the change has a chance to stick.
- Identify the step that causes the most chasing, copying, or follow-up.
- Replace that step with something the team can update in place.
- Revisit the change after two or three cycles and remove anything nobody is using.
In practice, the first owner should be the person already closest to the work, not someone assigned to police the process. The best change is the one the team can keep alive without making a separate ritual out of it.
The features page shows the operational side of a lighter workflow, and the PMO use case shows how the same habit supports a wider portfolio.
When the first version feels easy, people keep going. When it feels like extra process, the rollout will stall no matter how useful the idea is.
How to tell it is working
The process is working when the team stops asking where the latest version lives. You see fewer reminders, fewer surprise escalations, and fewer meetings spent re-creating the same status.
Watch for three signs:
- people update it without being chased
- meetings get shorter because the status is already visible
- decisions move faster because the facts are current
The real signal is trust. When people stop keeping their own shadow list and start relying on the shared view, the system has begun to work properly.
The features page shows the kind of setup that makes those signals easier to see. The PMO use case shows the same behaviour at portfolio level.
If those signs do not move, the workflow is still too hard to maintain. The fix is usually to simplify the steps people touch every week, not to add another rule.
Practical next step
If Project health metrics is still relying on manual updates, start by fixing the place where people lose the most time: the handoff between the work and the report. A better process does not begin with a bigger dashboard. It begins with one shared view that answers the same question every time: what changed, what needs attention, and who needs to act.
Keep the rollout narrow. Pick one team, one cadence, and one owner who is already close to the work. Then define the smallest set of fields that actually matter: status, owner, next milestone, and the reason the item is at risk or blocked.
Once that is in place, test it for two review cycles. If the team still needs a shadow spreadsheet or a separate Slack reminder to keep it current, the workflow is still too heavy. The goal is to make the reporting happen as part of the work, not after the work has already changed shape.
The features page shows how the workflow stays connected to the work. The PMO use case shows how the same structure plays out in a live operating model.
After two cycles, review what people are still doing outside the system. If the answer is “copying status,” “asking for the latest version,” or “keeping a backup spreadsheet,” the process still needs one more simplification pass. If the answer is “nothing,” the change is probably small enough to stick.
Frequently asked questions
What are project health metrics?
Project health metrics are indicators that predict whether a project will deliver its commitments on time and on scope. They include milestone trajectory, risk trends, decision velocity, scope stability, and team confidence.
What is the difference between health metrics and status reporting?
Status reporting describes what happened. Health metrics predict what will happen. The best project governance uses both — status for context and health metrics for early warning.
How many health metrics should a project track?
Three to five active metrics with defined thresholds. More than that creates noise. The specific metrics should be chosen based on what matters most for your project type and risk profile.
Should health metrics be the same for all projects?
The core metrics (milestones, risks, decisions) apply universally. The thresholds may vary based on project size, complexity, and risk tolerance. A small internal project may have different thresholds than a large client engagement.
How do I get project managers to update health metrics honestly?
Make the metrics objective where possible (milestone dates are facts, not opinions). For subjective metrics like team confidence, create psychological safety so people can report honestly without fear of blame.
What do I do when a project's health metrics turn amber?
Investigate the root cause, develop a mitigation plan, and decide whether to escalate to portfolio governance. Amber is the intervention window — use it before the project turns red.
Related reading
Want to test this on one live project?
Start with one engagement, compare it against your current workflow, and see whether the reporting gets simpler.
Start FreeNo credit card. Cancel anytime.