Project Management KPIs

A metric is only as good as its failure mode

Every metric in this list can be improved without the underlying reality improving at all. That's not a flaw specific to any one of them, it's a property of measuring anything that people know is being measured. The metrics below are still worth tracking. But each one is presented with the specific way it gets gamed, because a KPI you don't know how to distrust is a KPI you'll eventually be misled by.

This is a reference on the metrics themselves, what they measure and how to read them, not on status reporting or broader success criteria, which are different problems with their own considerations.

Rates over snapshots

A single reading of any of these numbers tells you almost nothing. 82% on-time delivery could be a healthy team having a normal month, or a team in the middle of a slide from 95%. The value in every metric on this page is in the trend, read over enough cycles that a single bad sprint doesn't distort it, and compared against the same team's own history rather than an external benchmark.

Comparing velocity or cycle time across teams is a specific trap worth naming directly: a story point means whatever a given team decided it means when they set their estimation baseline, so "Team A does 40 points a sprint, Team B does 25" says nothing about which team is more productive. It says their point scales aren't the same.

Leading versus lagging

On-time delivery rate is a lagging indicator: it tells you what already happened. Cycle time and WIP-limit adherence are closer to leading indicators, because a cycle time that's drifting up or a WIP limit that's being routinely exceeded shows a problem building before it shows up as a missed date. A dashboard built only from lagging metrics will always feel like it's reporting old news, because it is.

The practical implication is to weight the leading indicators more heavily in a weekly review and save the lagging ones for a monthly or quarterly retrospective, where they're better suited to answering "did the changes we made actually work."

Choosing which ones matter for your team

Five metrics is already more than most teams should actively watch at once. A small team running one steady stream of work probably only needs cycle time and WIP-limit adherence, the two most sensitive to day-to-day process health. A team managing several fixed-date commitments to clients needs on-time delivery rate front and centre. Velocity matters most to anyone forecasting delivery dates for work that hasn't started yet.

• Is each metric being read as a trend, not a single snapshot?
• Do you know, specifically, how each one could be gamed on your team?
• Are you comparing a metric against its own history, not another team's?
• Is at least one leading indicator in the mix, not only lagging ones?
• Could someone explain what a bad number should trigger, not just that it's bad?

Where the numbers should come from

Every metric above is only trustworthy if it's calculated from data nobody had to manually assemble. The moment a KPI depends on someone remembering to log something at the end of a busy day, the number quietly starts measuring diligence at logging rather than the thing it claims to measure. That's true of every tool, not just ShipSprint's: planned-vs-actual hours calculated from a five-second log taken next to the task someone just finished will be more honest than the same metric built from an end-of-week timesheet reconstruction. In ShipSprint specifically, velocity and on-time delivery come straight out of the same board people already work from as sprints complete, so the forecast is just arithmetic on that measured throughput, not a separate number someone has to maintain alongside it.