Project health score
A project health score summarises a project's delivery risk as a single figure or status, calculated from signals such as milestone progress, task completion and how recently anything moved. It is a triage device: a way of deciding which projects deserve a closer look this week.
Sixty live projects cannot all be reviewed well every week. A score decides where the attention goes, and that is a real job worth doing.
What a score cannot do is replace the look. It is built from what a system can see: activity, dates, and what is ticked off. The things that sink projects hide from all three. A client going quiet. A key person unhappy. An assumption nobody checked.
The dangerous failure is a green project that is quietly in trouble. Everything measurable is on track, so nobody opens it, and the score has actively diverted attention away.
That risk is why the inputs should be visible and adjustable. A score whose formula nobody can inspect becomes an authority rather than a signal. A score a team can see the workings of gets argued with, and that argument is where the real review happens.
Where this shows up in PeopleMuster
PeopleMuster shows Health, Tasks and Setup as three separate scores per project, and keeps project health configurable in tenant settings rather than fixed in code.
Questions people ask
What goes into a project health score?
Usually milestone and task progress, plus how recently things moved. In PeopleMuster the weighting is a tenant setting, so a team can decide what its own score is built from.
Why separate health, tasks and setup?
They fail differently. A project can be progressing well while its own setup is incomplete, and one combined figure would average away exactly the problem worth seeing.
Can a score replace a project review?
No. It decides which reviews to hold first. Client mood, team morale and untested assumptions leave no trace in any of the inputs a score is built from.