The problem: delivery without a shared project KPI scoreboard
Teams close tasks, run sprints, and watch burndowns—yet leaders still ask questions nobody answers with the same numbers: Are we faster than last quarter? Where does work stall? Which initiative actually moved a strategic goal?
Without agreed project KPIs, decisions rely on gut feel. Product says velocity looks fine; engineering sees aging tickets; finance sees spend without throughput. By the quarterly business review (QBR), someone rebuilds slides manually and the same debates repeat.
Missing project KPIs is not just a tooling gap—it is a measurement design problem. Too many metrics create noise; too few hide bottlenecks. The fix is a small set of indicators wired to real Kanban flow, not a new dashboard every month.
Symptoms and cost of missing project KPIs
| Symptom | Cost |
|---|---|
| Different Done definitions per squad | False rollup at QBR |
| QBR driven by anecdotes | Late investment decisions |
| Leading signals ignored until release slips | Weekly firefighting |
| Finance and engineering use different time windows | Unfair blame |
| PMO deck contradicts live board | "Which number is right?" debates |
| Seasonal goals not linked to tasks | Strategy drift |
Hidden costs include slide assembly hours, stakeholder distrust, and "improvements" with no baseline—you cannot prove what worked.
Leading vs lagging project KPIs
Lagging KPIs prove outcomes after the fact: release hit rate, budget variance, goal completion. Leading KPIs warn early: Review WIP, cycle time, aging beyond SLA, mid-sprint scope change rate.
Every project KPI should play one role—not both. Leading without lagging means alarms without proof; lagging without leading means surprises.
| Type | Examples | When to review |
|---|---|---|
| Leading | Aging, Review WIP | 15-minute weekly review |
| Lagging | Release hit, burn vs plan | QBR and quarterly calibration |
Seven-step framework: project KPIs you can run this week
1. Audit two weeks with evidence. Before defining new project KPIs, pull board history: items Done, columns with stuck WIP, aging spikes. Without a baseline, any number is arbitrary.
2. Pick five fixed KPIs—not more. Starter set: median cycle time, Review WIP, aging beyond SLA, release hit (yes/no per milestone), percent of tasks linked to quarterly goals. More than seven turns review into chart tourism.
3. Write definitions in wiki. What is Done? When does aging start? Does release hit mean full scope or MVP only? Without wiki definitions, weekly debates repeat.
4. Assign an owner and cadence per KPI. Every metric has a name—not "the team." Same five numbers every Monday, 15 minutes, exception-only narrative.
5. Link one KPI to a strategic goal. In WKFGo Goals, connect key results to epics or labels. Rollup "percent of sprint work on KR X" is impossible without links.
6. Red leading KPI = one experiment—not another slide. Hypothesis, owner, revisit date. Example: thick Review band → cap upstream WIP for two weeks. Log in the decision log.
7. Quarterly calibration. At QBR, compare lagging project KPIs to forecast. Tune definitions—not new metrics every quarter.
Suggested KPI table
| KPI | Leading/lagging | What it measures |
|---|---|---|
| Median cycle time | Leading | Real throughput |
| Review WIP | Leading | Bottleneck before slip |
| Aging > SLA | Leading | Named stuck items |
| Release hit | Lagging | Stakeholder trust |
| Scope change rate | Leading | Mid-sprint discipline |
Anti-patterns
- Vanity counts—"120 tasks closed" with no Done definition
- Metrics without owners—everyone responsible means nobody is
- Dashboard sprawl—twelve charts nobody opens
- Different Done per squad—false QBR rollups
- New KPI every month—impossible trend comparison
- Reports after the decision—slides to justify, not inform
How WKFGo helps with project KPIs (honest map)
Reports (/reports)—lagging indicators: user throughput, cycle time trends, project summaries without Excel exports.
Kanban (/dashboard)—source of truth for WIP and movement; foundation for CFD and aging.
MCP flow_cfd—cumulative flow by column; thick Review band = bottleneck before missed dates.
MCP flow_aging—items beyond SLA with task names and owners—actionable leading signals.
Goals—link key results to work; roll up percent of effort on strategic targets.
MCP get_project_report—structured brief with advice—replaces manual slides for weekly review.
MCP portfolio_overview—multi-project rollup for PMO and CEO views.
Decision log—records outcomes when a KPI turns red.
Permissions match the web app via FeatureAccess—contractors do not see finance without role access.
Common scenarios
Product squad: Green velocity, slipped release—QA aging unseen. Services firm: Client Excel vs internal board ahead. Enterprise PMO: Ten dashboards, zero shared Done. All three fix missing project KPIs with five fixed numbers and wiki definitions—not another tool.
From red KPI to action
When a leading project KPI turns red, assign one experiment with an owner. Example: Review aging > 5 days → cap WIP plus daily exception scan. Revisit the same five numbers in two weeks; if still red, escalate with executive_brief evidence—not QBR anecdotes.
FAQ — project KPIs
How many project KPIs to start?
Five to seven. Fewer creates blind spots; more exhausts the team in review.
Do we need a data team?
Not for small squads—cycle time, aging, and release hit from Kanban are enough. Data teams serve warehouses separately.
Pure Scrum teams?
Velocity is lagging; aging between sprints is leading. Keep both—they serve different roles.
Where to start with MCP?
flow_cfd, flow_aging, get_project_report—three calls before Monday review.
Start this week
Define project KPIs today: five numbers, wiki definitions, owners, 15-minute Monday review. Pull a two-week baseline—the next QBR is trends, not stories.