Project Management Metrics: Fewer Numbers, Better Decisions

The short answer

A metric is worth tracking only if a change in the number would change what someone does. If nobody would act on it, drop it.

For most projects, five or six measures are enough: one or two each for schedule, cost and quality, plus one that shows risk or stakeholder confidence. Add flow measures if the team works in small continuous batches, and earned value if the project is large enough to have a formal baseline.

The rest of this page is a menu, not a checklist. Pick from it, write down what each pick is for, and review the list every few months.

The main families of metrics

Metrics fall into a handful of families. The table pairs each with the decision it supports and a common trap. The examples are typical ones, not a required set.

Two notes on the table. First, leading measures (such as work item age or open risks) tell you something is going wrong before it shows in the date or the budget. Lagging measures (such as final cost variance) confirm what already happened. A good set has some of each.

Second, the families overlap. Rework is a quality measure and a cost measure. A rising change rate is a scope signal and a schedule warning. That is fine, as long as you do not count the same problem three times on one dashboard.

Earned value formulas

Earned value is the one family with standard formulas, so it is worth knowing them. It compares three numbers on the same date: what the plan said you would have done (planned value, PV), what you have actually done in budget terms (earned value, EV) and what you have spent (actual cost, AC). BAC is the total approved budget. The NASA earned value management reference card lists the standard formulas below.

Another common variant multiplies CPI by SPI in the EAC denominator, for projects where cost and schedule both pull the forecast. Which version to use is a judgment call, and it helps to show the range rather than one number. For the full process around these formulas, baselines and change control, see our guide to the monitoring and controlling process group.

A made-up earned value snapshot

The numbers below are invented to show the arithmetic. A project has a BAC of $100,000. At the status date the plan called for $40,000 of work (PV), the team has completed work worth $36,000 (EV), and it has spent $45,000 (AC).

How to read it: the project is a little behind but much less efficient with money. If the current trend holds, it ends about $25,000 over, or about $33,900 over under the harsher variant. To hit the original budget, the team would need to be 16% more cost-efficient than the plan assumed, on every remaining dollar, which is a big ask if nothing about the work changes.

That is the useful part. The numbers do not say why. They tell you to go and find out whether the estimates were low, the work was harder or the team was pulled onto something else.

Flow metrics for agile and kanban teams

Teams that deliver in small pieces often skip earned value and watch the flow of work instead. The Kanban Guide defines four flow measures:

• Work in progress (WIP): work started but not yet finished.
• Throughput: the number of items finished per unit of time.
• Work item age: time since start for an unfinished item.
• Cycle time: time from start to finish for a work item.

The first three describe the present, and cycle time describes the past. Work item age is the early-warning one. An item that is already older than most finished items took is the one to ask about at the next stand-up.

These measures are linked by Little’s Law, a general queueing result. For a stable process, on average, cycle time equals WIP divided by throughput. It is an average relationship and holds only when work enters and leaves at a similar rate, so treat it as a guide, not a promise.

A made-up example. A team has 12 items in progress and finishes 4 items a week. Average cycle time is 12 ÷ 4 = 3 weeks. If the team cuts WIP to 6 and throughput stays at 4, average cycle time becomes 1.5 weeks. Going the other way, if you want an average of 2 weeks at 4 items a week, WIP should be about 8 (2 × 4).

In real teams, cutting WIP does not always leave throughput unchanged. Less switching often helps, but fewer items in progress can also leave people idle. Try a lower limit for a few weeks and watch both numbers.

Many teams also chart velocity or burndown. Those are fine as planning aids for a single team, but they are weak for comparing teams, because the units are not shared.

How to choose your five or six

Start from decisions, not from a list of available numbers. Ask: what are the three or four decisions we will have to make in the next quarter? Then pick the metric that would tell you which way to go.

Write each pick on a short card before you start tracking it:

• Decision: what will change if this number moves?
• Definition: exactly how it is calculated, including what counts as “done”.
• Owner: one person who explains it when it moves.
• Source: where the data comes from, ideally without manual re-entry.
• Frequency: weekly, monthly or per release.
• Threshold: the level that triggers a conversation (set it before you see the data).

If you cannot fill in the decision and the threshold, you probably do not need the metric yet. If two metrics trigger the same decision, keep the one that is easier to collect.

A reasonable starting set for a mid-sized project might be: forecast finish date, budget variance, defects found and escaped, open high-rated risks, and a short stakeholder pulse. For a team using kanban, swap in cycle time and work item age. These are examples, so replace them with whatever your decisions need.

Dashboards by audience

One dashboard rarely serves everyone. Different readers need different detail.

Keep the executive view to a page. Show a trend, not just a snapshot, and add a sentence on what you are doing about anything red. A red light with no action next to it starts a worse conversation than a red light with a plan.

How metrics get gamed

People respond to what is measured. That is the point of metrics, and also the risk. Watch for these patterns:

• Velocity inflation. If velocity is used to compare or reward teams, estimates quietly grow.
• Premature “done”. Items are closed before testing or acceptance to hit a throughput target, and the defects show up later.
• The 90% done trap. Reported progress stalls near the end because the hard part was left for last. Count finished deliverables, not self-reported percentages.
• Vanity numbers. Tasks completed, hours logged and lines of code are easy to produce and say little about value.
• Hiding bad news. If a red status is punished, statuses stay green until they cannot.

Defenses are simple but need discipline. Pair every speed measure with a quality measure. Define done in writing. Use metrics to ask questions, not to rank people. And when a number looks too good, look at how it was produced.

Common mistakes

• Tracking everything. More numbers means less attention for each one.
• No definitions. Two people calculate “rework” two ways and the trend means nothing.
• Only lagging measures. By the time cost variance is red, the money is spent.
• Setting thresholds after seeing the data. It makes every number look acceptable.
• Using team metrics to judge individuals. It pushes people to protect themselves, not the project.
• Never retiring a metric. If it has not changed a decision in six months, remove it.

Learn more

If you want structured practice with baselines, earned value and reporting, online providers such as Coursera and Udemy list project management courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Check the syllabus to see whether it covers performance measurement. For related reading, see our guides to the iron triangle, scope creep and agile.

Frequently asked questions

What are the main project management metrics?

The most common cover schedule, cost, scope, quality, risk, people, delivery flow, benefits and stakeholder satisfaction. Which ones matter depends on the decisions your project faces.

How many metrics should a project track?

Usually five or six. More than that and few get read. Fewer than four may leave a blind spot, such as quality or risk.

What is the difference between a metric and a KPI?

A metric is any measure. A KPI (key performance indicator) is a metric chosen because it reflects a goal that matters. Use the word that your organization already uses, as long as everyone means the same thing.

What do SPI and CPI mean?

The schedule performance index is earned value divided by planned value. The cost performance index is earned value divided by actual cost. Both are ratios: 1.0 is on plan, below 1.0 is worse than plan.

What is cycle time?

The time from the start to the finish of a work item. The Kanban Guide defines it that way, and it is usually reported as an average and as a spread, since the slow items matter most.

Should agile teams use earned value?

Some do, especially on large contracts that require it. Many small teams get what they need from flow measures, release forecasts and defect trends instead. Use what your sponsor and your delivery model can support.

How often should metrics be reviewed?

Team-level flow measures weekly, project cost and schedule monthly or at each status report, and benefits at agreed points after delivery. Revisit the list itself every few months.