Project Health Reports Software

What "health" means when we say it

Most project health reports are built on a score nobody can quite explain: a red, yellow or green a project manager assigns partly from data and partly from mood. It's not dishonest exactly, but it isn't measurable either, and two people looking at the same project often pick different colours for reasons that have more to do with temperament than the project itself.

ShipSprint doesn't invent a composite health score. What it shows is narrower and, we think, more trustworthy: the project's delivery forecast, calculated from the team's measured velocity, compared against the date you actually promised. If the forecast is inside the deadline, the project reads as in range. If the forecast has drifted past it, the project reads as at risk. That's the whole mechanism, one comparison, recalculated every time a sprint closes.

There's no separate algorithm blending scope, sentiment and budget into a single number. If you need that kind of composite score, this isn't it. What you get instead is a forecast you can trace back to the sprints that produced it.

Here's what that looks like in practice. Say the deadline is the 30th and the current forecast, based on the last three sprints' velocity, points to the 24th. That project reads in range, with six days of margin, and the margin is a real number rather than a feeling. If the next sprint runs slower and the forecast slides to the 3rd, it flips to at risk, and you can see exactly which sprint caused the flip, because the forecast is just velocity projected forward, nothing hidden behind it.

Margin also isn't a fixed cushion you can bank once and forget. Six days of margin on a project with steady velocity is fairly reassuring; six days of margin on a project whose velocity has swung wildly the last three sprints is worth watching more closely, because a single slow sprint could erase it. The report shows the trend behind the margin, not just the margin itself, precisely so that distinction doesn't get lost in a single green checkmark.

Why we're not selling you a health score

A composite score feels reassuring because it's simple: one number, one colour. But collapse forecast risk, team sentiment, budget variance and scope creep into a single figure and you lose the ability to ask the one question that actually matters: why. A project reading "at risk" because velocity has dropped needs a different response than one reading "at risk" because scope has doubled, and a blended score hides that difference on purpose.

ShipSprint's forecast-versus-deadline comparison stays traceable. If a project is at risk, you can go look at the velocity trend and the stalled cards behind it and see exactly why, rather than trusting a number to have already done that thinking for you. That's the real payoff of this design: a status meeting that used to open with "why is this red" can open with the actual cause already on screen.

There's also a quieter cost to composite scores that's easy to miss: they invite gaming at the input level. If a "health" number partly depends on a manager's self-reported confidence, confidence creeps upward over time regardless of what's actually happening, because nobody wants to be the one reporting yellow three weeks running. A forecast built purely from measured velocity has nothing to self-report. It's either tracking to the date or it isn't.

That said, a schedule read isn't the whole picture, and we'd rather say that plainly than let the word "health" imply more than it delivers. A project can be perfectly in range on the forecast and still have a frustrated client, a burning-out team, or a technical decision nobody's happy with. Those things matter and this particular signal won't catch them. It answers one question, precisely, and leaves the rest to conversations a dashboard can't have for you.

What it does give you is a defensible starting point for those conversations. "The forecast slipped four days after last sprint" is a fact you can bring to a retro; "the project feels unhealthy" is an opinion someone has to defend without much to point at. Starting from the traceable version tends to get a team to the real cause faster, because nobody's first move is arguing about whether the read itself is fair.

What "in range" and "at risk" cover

• In range: the forecast date, based on current velocity, lands on or before the deadline you set.
• At risk: the forecast has drifted past the deadline, based on the same live calculation.
• No other project attribute, budget, sentiment, stakeholder mood, feeds into this particular read. It's specifically a schedule signal.
• The read updates automatically as sprints close; nobody needs to log in and manually reclassify a project from in range to at risk.