“Dear Elizabeth: I want to get better at measuring the success (or failure) of my projects. What project management metrics should I be focusing on? And how can I use these metrics to improve project performance?”

OK. I don’t mean to start off by being controversial, but you’re asking the wrong person.

It’s your project stakeholders who decide if your project is a success or a failure. So what you should be asking is: how will they judge me?

Do they care if you are late by a few weeks as long as you deliver something of supreme quality? Is it essential that you hit the delivery milestone by any means possible, even if that means sacrificing a few bits of functionality?
You can measure time taken to fix defects, number of change requests, deviation from schedule baseline, percent complete, burn rate, or anything else you want. These measures will give you some interesting management information and might help you manage the team. But if your sponsor is unhappy in the end, she won’t feel any better by you telling her you were under budget by 1.3 percent.

So, let’s split your question.

First, talk to your project sponsor and the important stakeholders about what they value. What do they want to get out of the project? How will they know if the project has been a success? Typically, they’ll judge on time, cost, or quality, but it could also be customer/staff satisfaction. Or, they might rate something else. When you know what it is, you can measure it, track it, and prove that you are doing it.

The thing to bear in mind here is that expectations will change as the project progresses. The sponsor who thinks he wants you to hit the delivery date at all costs might change his mind when he realizes he can have extra functionality that’s going to boost customer retention by 20 percent — if he’s prepared for the schedule to slip by a month.

You need to stay close to the expectations of your project decision makers. Keep checking in with them and seeing if their definition of success has changed. Talk to them often and tell them how you are doing against meeting the targets they set with you and the targets they think are important.

At the end of the day, the stakeholders decide if you met their needs and if the project did what they wanted. You can deliver something on time, on budget, and to the specified scope, and they will still be unhappy. I don’t want situation for you. So check it out with them in advance, and tailor what you measure to their expectations.

That will give you clarity on what success (or failure) looks like and how best to track it. But for your project management purposes, you probably want some other metrics to go on.

Performance metrics help you see how the team is doing and let you spot where there might be problems. If this is the first time you’ve really focused on measuring project performance, don’t make it too complicated. People hold up Earned Value as the way to go for the ultimate in performance tracking, but it’s overkill for most projects.

Try these:

Schedule Variance: Plot your baseline project schedule. Then track your actual performance. Measure the difference between where you thought you’d be and where you actually are. This can be represented as a discrete number of days (“We’re 10 days behind.”) or a percentage (“We’re 6 percent ahead of schedule.”).

Cost Variance: This is the same principle as schedule variance. First, establish your budget baseline. Then, track what you actually spend and compare the two. You’ll end up over- or underspent (it’s rare that you’ll be exactly spent in line with your baseline, but good for you if that happens). You can represent this as a fixed price (“We’re underspent by $5,000.”) or a percentage (“We’re 10 percent over budget.”).

Number of Change Requests: This useful measure offers an indication of how good your requirements were at the beginning. When people want to make a lot of changes, it means you didn’t really know what you were doing upfront. That might be an issue for you. It depends on the methodology you are using. Agile methods tend to be more flexible in dealing with change. Waterfall development methodologies are less good at coping with change to the extent that adding more changes late in the project can be very costly. Either way, tracking trends on the volumes of change requests will let you spot if it’s worth taking a deep dive into requirements or your backlog again.

When it comes to metrics, it’s the context that makes the knowledge valuable. Knowing you are six percent ahead of schedule is meaningless without some narrative that explains why. Perhaps you just cut a huge portion out of your scope, so it’s obvious that you are ahead–you have less work to do overall. Perhaps you got a new starter on the team who is picking up the tasks at a rapid pace (but costing you money on your resource line).

Whatever you choose to measure, make sure you can interpret it intelligently and use your professional judgment to help uncover what it really means for your project. Then you can explain it to your team, use the data in a helpful way, and make better decisions about how to manage your project.

I’m sorry if you just wanted a few easy answers! I think it’s better to give you a realistic view of how to manage successfully than a list of bullet points that make an attractive but pointless project dashboard.

Are you grappling with a stubborn project management work issue? Leave your question in the comments to ask Elizabeth!

Elizabeth Harrin is a project manager, author of several books, and a mentor. Find her online at her blog, A Girl’s Guide to Project Management.