5 Useful Project Metrics: What to Track, How to Calculate It and How to Read It

What makes a metric useful

A useful project metric passes three tests:

• It changes a decision. If nobody would act differently whatever the number says, drop it.
• It is cheap to collect. If gathering it takes half a day each week, it will be skipped.
• It is hard to fake. Counts and dates beat opinions such as “90% done.”

The five below cover the classic triangle of time, cost and scope (see our guide to the iron triangle), plus quality and people, which are what the triangle tends to hide.

The five metrics at a glance

1. On-time milestone rate

List your milestones with their planned dates. At each check, count how many are due so far and how many were met on time. Also note how late the late ones were.

• Why it works: milestones are binary. They are either done or not, which makes this much harder to gloss over than a percent-complete estimate.
• How to read it: a falling rate is an early warning, even if the final date has not moved yet. Look at average slip, too. Five days late on every milestone points to a planning problem. One milestone 30 days late points to a specific blocker.
• Watch for: milestones that are too big or too far apart. Aim for one every one to three weeks so the number moves often.

2. Budget variance

Compare what you planned to have spent by now with what you actually spent. A plain version: variance = actual − planned. Divide by planned to get a percentage. Positive means over budget in this convention. Some sources flip the sign, so write the convention at the top of your report.

• Why it works: it compares like with like, at the same point in time, not just against the total budget.
• How to read it: spending more than planned at the halfway point is not always bad if the work is also ahead. That is why the next metrics matter. If you want to link cost and progress in one figure, earned value does it, and we explain it in our guide to the monitoring and controlling process group.
• Watch for: costs that arrive late, such as invoices and contractor hours. Include commitments you have made, not only bills paid.

3. Scope change rate

Start with a baseline count of deliverables, features or work packages. Each time one is added or removed, log it. The rate is changes divided by the baseline. Also count requests that arrived but were not formally logged. Those are the real warning.

• Why it works: it makes scope growth visible before it shows up in the schedule or the budget.
• How to read it: approved changes are fine, as long as time and cost were adjusted. Unlogged requests are the problem. Our scope creep guide covers how to stop them.
• Watch for: counting every item as equal. One large feature is not one small fix. If sizes vary a lot, count effort in days instead.

4. Rework share

Rework is time spent redoing work that was already called done: fixing defects, rewriting rejected documents, redoing designs. Track the hours your team logs against rework and divide by total hours.

• Why it works: it reveals quality problems in the unit that matters, which is time and money. It also needs no special tools, just a time-tracking category.
• How to read it: a rising share means problems are being found late, usually because requirements were unclear or reviews were skipped. A very low number can also mean problems are being hidden.
• Watch for: a team that is afraid to log rework. Make the point that the number is for fixing the process, not for blaming people.

5. Stakeholder satisfaction

Ask the sponsor and key users the same one or two questions at regular intervals, for example: “On a scale of 1 to 5, how confident are you that this project will deliver what you need?” Track the average and, more importantly, the trend.

• Why it works: projects can hit every date and still fail because the people they serve lose confidence.
• How to read it: a drop of half a point or more between surveys is a prompt for a conversation. Read the comments. Numbers only tell you something changed.
• Watch for: survey fatigue. Keep it to two questions and send it no more than every two to four weeks.

A worked example

The project, the numbers and the thresholds are our illustration, not real data. A team is in week 12 of a 16-week website project.

Reading them together. No single number is alarming, but the pattern is a classic one. Unlogged requests (scope) add work. The extra work causes rework and late milestones, which pushes spending 10% above plan, and sponsor confidence slips. The common cause is scope control, so that is where the manager acts first: log every request, price it, and have the sponsor approve or decline it. Next month’s check will show whether the other four numbers recover.

That is the value of a small set: they point to one cause, instead of leaving you with a pile of unrelated red lights.

These thresholds are our rules of thumb, not industry standards. Agree your own with the sponsor at the start so nobody argues about the colors later.

Spreadsheet formulas

These work in Excel and Google Sheets. Adjust the cell references to your layout.

Format the results as percentages where needed, and use conditional formatting for the green, amber and red cells. A single sheet with one row per week is enough to chart each metric over time.

Traps to avoid

• Too many metrics. Five is plenty to start. Add one only when a decision needs it.
• Gut-feel percent complete. “90% done” often stays at 90% for weeks. Count finished deliverables instead.
• Measuring people, not process. If the numbers become a way to blame individuals, people will stop reporting honestly. A well-known saying, often called Goodhart’s law, puts it this way: when a measure becomes a target, it stops being a good measure.
• Hours logged as a productivity score. Time spent is not value delivered.
• Reporting without acting. Each review should end with one decision or one named follow-up.
• Changing definitions mid-project. Write down how each metric is calculated and keep it fixed so trends are meaningful.

Where to go next

For a wider catalog of measures, see our guide to project management metrics. To link cost and progress in one number, read about earned value in the monitoring and controlling process group guide. NASA’s earned value reference card sets out the standard formulas for schedule and cost variance and performance indexes.

To learn more in a structured way, 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 for measurement and reporting topics.

Frequently asked questions

What are the most important project management metrics?

For most projects: schedule performance, cost performance, scope change, quality and stakeholder satisfaction. This page uses the on-time milestone rate, budget variance, scope change rate, rework share and a satisfaction score.

How many metrics should a project track?

As few as help you decide. Five is a good start for a small or medium project. Add more only when a specific question needs one.

What is the difference between a metric and a KPI?

A metric is any measurement. A key performance indicator (KPI) is a metric chosen because it reflects a goal that matters. Terms are used loosely, so define yours in the plan.

How often should I review project metrics?

Weekly for fast projects and every two weeks for slower ones, with a short monthly review to look at trends.

What is a good on-time rate?

There is no universal standard. Many teams aim for 90% or more on milestones, but what matters is the trend and the reasons for slips. Set your target with your sponsor.

Do I need earned value management?

Not for small projects. It helps when cost and schedule interact and you must forecast the final cost, and some contracts require it. The five metrics here are a lighter place to start.

What tools do I need?

A spreadsheet is enough. Project tools can calculate some metrics automatically, but the discipline of recording the numbers matters more than the software.

How do I get my team to log rework honestly?

Say clearly that the aim is to improve the process, not to grade people, and act on what you learn. Fix an early cause of rework publicly so people see logging has a purpose.