Data-Informed Decision-Making for Project Managers
Using numbers to catch a problem before it shows up in the schedule, without pretending the numbers make the decision for you.
Intermediate
TopNotchNote
Notes that matter
data as an input, not an autopilot
Every project generates data — schedule status, spend, defect counts, team throughput. Used well, it catches problems earlier and replaces "I have a feeling this is slipping" with something concrete to act on. Used badly, it becomes a dashboard nobody trusts or a target people quietly optimize for instead of the actual goal. Being data-informed means treating metrics as one input alongside context and judgment — not as a replacement for either.
leading vs. lagging indicators
A lagging indicator tells you what already happened — schedule variance, cost variance, whether a milestone was hit. It's accurate but arrives after the fact, when options for fixing it are more limited. A leading indicator is predictive — a signal that tends to move before the lagging metric confirms a problem, giving time to act while there's still room to.
| Leading (predicts trouble) | Lagging (confirms trouble) |
|---|---|
| Cycle time trending up | Missed milestone |
| Blocked-task count rising | Schedule variance |
| Defect discovery rate climbing | Failed release / production incident |
| Velocity trending down over sprints | Sprint goal missed |
Watching only lagging indicators means always finding out about problems after the point where the cheapest fixes were still available.
the traps: vanity metrics and goodhart's law
A vanity metric looks good on a slide but doesn't inform any actual decision — hours logged, lines of code written, number of meetings held. None of these tell a PM whether the project is actually healthier; tracking them mostly just produces noise.
Goodhart's law — "when a measure becomes a target, it ceases to be a good measure" — is the sharper trap. The moment a metric is tied to a reward or a judgment of performance, people (reasonably) start optimizing the number itself rather than the thing it was meant to represent. A team whose velocity is used to judge them will tend to inflate story-point estimates over time, and the metric quietly stops meaning what it used to.
a short example
A PM running a mobile app project notices cycle time (time from a task starting to being finished) creeping up over three sprints, well before schedule variance — a lagging indicator — would have shown anything wrong. Digging in, the cause is a single reviewer who's become a bottleneck for every pull request. Because the leading indicator caught it early, the fix is simple: add a second reviewer. Waiting for the lagging metric to confirm a problem would have meant finding out only once a milestone was already missed.
practical notes
A dashboard is only as useful as the data behind it is trusted and current — a metric nobody updates or believes gets ignored, no matter how good the visualization is.
If a metric has never once changed a decision, it's worth asking why it's still being tracked. Data collection has a real cost in time and attention; it should earn its place.