12 Project Management Metrics & KPIs That Actually Matter

Most project dashboards are decoration. They're full of green circles, percent-complete bars, and "85% on track" badges that nobody trusts and no one acts on. A metric earns its place on a dashboard only if a different number would change a decision you'd actually make this week.

This guide lists 12 project management metrics that pass that test, grouped by the question they answer. It's deliberately biased toward metrics you can read in five seconds and that are hard to game — because those are the ones a busy team will keep using after the novelty wears off.

Delivery: are we shipping on time?

These four answer the only question most stakeholders care about: will it be done when you said it would?

1. Cycle time

How long a task takes from the moment work starts to the moment it's done. It's the single most honest delivery metric because it measures reality, not estimates. Rising cycle time is the earliest warning that a team is overloaded or blocked — usually visible weeks before a deadline slips.

2. Lead time

The clock from when a task is created (or requested) to when it's delivered. Lead time includes the wait before work starts, so a big gap between lead time and cycle time tells you the problem is your backlog/triage, not your execution.

3. On-time completion rate

The share of tasks finished on or before their due date over a period. One late task is noise; a 60% on-time rate across a quarter is a planning problem. Track the trend, not the absolute number — a team that climbs from 55% to 80% is doing something right.

4. Schedule variance

Planned end date minus actual (or forecast) end date, in days, per project. Reported as a simple "+4 days" or "−2 days," it's the least ambiguous status update you can give a stakeholder. It replaces the meaningless "we're at 90%."

Rule of thumb: if a status update can't be expressed as a number of days early or late, it isn't a status update — it's a feeling.

Cost & effort: are we spending what we expected?

5. Estimated vs. actual hours

For any task or project, the gap between what you thought it would take and what it did. Persistent under-estimation isn't a people problem — it's a calibration problem you can only see if hours are logged against the work itself.

6. Budget / effort variance

The percentage you're over or under the planned effort or budget for a project. For client work this maps directly to margin; for internal work it's your early signal to cut scope rather than ask for more time.

7. Billable vs. non-billable ratio

For teams that bill clients, the split between hours that earn revenue and hours that don't. A quietly drifting ratio is how an agency becomes unprofitable without a single dramatic event. This metric only exists if time is tracked per task — guessing at month-end doesn't count.

8. Cost of delay (qualitative)

Not every team can put a number on it, but every team can rank work by "what does it cost us per week this is late?" Even a rough High/Medium/Low tag on this changes prioritisation more than any backlog-grooming ritual.

Capacity & people: can the team actually take this on?

9. Work in progress (WIP)

How many tasks are in progress per person at once. High WIP is the most common, least diagnosed cause of slow delivery: everything is started, nothing finishes. Capping WIP is the cheapest performance fix in project management — it costs nothing and works immediately.

10. Utilisation

The share of available working hours that goes to tracked work. Useful as a trend, dangerous as a target: pushing utilisation toward 100% reliably destroys quality and burns people out. Watch it to spot the team that's silently underwater, not to squeeze the team that's fine.

11. Capacity vs. committed load

Available person-days for the next period (after subtracting leave and holidays) versus the work you've committed to. This is the metric that prevents the most damage, because it catches over-commitment before the sprint starts instead of explaining it afterward. It depends on knowing who's actually available — which is where leave and a holiday calendar stop being HR trivia and become planning inputs.

12. Throughput

The number of tasks completed per week or sprint. On its own it's a vanity number (more, smaller tasks inflate it). Paired with cycle time, it becomes a stable measure of sustainable delivery pace — the realistic input for "when can you have this done?"

The metrics worth ignoring

Be honest about what doesn't belong on a dashboard:

• Percent complete. Self-reported, optimistic until the day before the deadline, and almost never 90%-to-100% in a straight line.
• Number of tasks created. Activity, not progress. Easy to inflate, predicts nothing.
• Comment / message volume. Engagement theatre. A busy thread is not a shipped feature.
• Story points velocity, for non-engineering teams. A useful tool in a specific context, frequently cargo-culted into ops/marketing teams where it measures nothing.

A metric that can't change a decision is a distraction with a chart attached. (For the broader framework on choosing tools and what to measure, see how to choose a project management tool.)

A starter dashboard for a small team

You don't need all twelve. Start with five and add only when a real decision needs more:

Every one of these is derivable from data you already capture if your tool records start dates, due dates, statuses, and logged hours. No data team, no BI stack — a normal report and a CSV export are enough.

How TaskWithAI fits

TaskWithAI records the raw inputs these metrics need as a side effect of normal use: start and due dates on every task, simple statuses for cycle/lead time, per-task timers for estimated-vs-actual and billable ratios, and clock-in/out plus a leave and holiday calendar for real capacity. Reports and CSV/XLSX export are on every plan at one flat per-seat price — there's no analytics tier to climb to. Model that against your current stack on the pricing page, or start a free 7-day trial with no card and build the five-metric dashboard above on a real project. If you're still shortlisting tools, the comparison pages show how the numbers come out elsewhere.

The one-paragraph version

A project metric only matters if a different value would change a decision. Track cycle time, on-time rate, and schedule variance for delivery; estimated-vs-actual hours and budget variance for cost; WIP and capacity-vs-committed-load for people. Ignore percent-complete, task counts, and message volume — they demo well and predict nothing. Start with five metrics on one dashboard, derive them from data you already capture, and add more only when a real decision forces it. The team with the cleanest five-number dashboard almost always ships more predictably than the one with the richest analytics suite nobody opens.