Traditionally, we measure the success of projects, programmes and the people who deliver them by whether they are delivered on time, within budget and to an agreed level of quality. In my experience, if that’s all you’re measuring, you’re measuring the wrong things.
If you think that’s a bold statement, even a misguided one, let me explain. Time, cost and quality simply measure efficiency, not effectiveness. Projects and programmes are not ends in and of themselves, they are vehicles for change. They provide something, ranging from discrete tactical deliverables to strategic transformational outcomes, which the business then uses to do something new or different. It’s from this new business capability that (hopefully) benefits will flow. The true measure of a project or programme’s effectiveness is the extent to which the required capability shift is adopted and its associated benefits realised.
Even with non-complex, tactical projects, it’s possible to deliver to time, cost and quality and still fail. How? It can be as simple as the difference between just successfully rolling out a new system and having it adopted by everyone who needs to use it. Imagine this. What if a project resulted in people being less rather than more productive, maybe because user training wasn’t included in its agreed scope, but it came in ahead of schedule and under budget? Success or failure?
I found a great quote in this year’s Pulse of the Profession report from the Project Management Institute that neatly summarises a better way of measuring success. Matthew Klein Jr., senior director of the enterprise project management office (EPMO) at Farasis Energy in California said, “A great value proposition for project management is to find ways to reduce pain points within the organization and for customers.” If you adopt this value proposition, success for any project is how well it reduces the pain point it was created to address. As projects get bigger, more complex, more transformational, our degree of success can only be fully measured by how comprehensively our organisation has transitioned to its desired future state. Depending on the strategic value of the programme, getting it right might outweigh delivering on time and to budget.
I think time, cost and quality are lazy metrics because they’re generic and they’re symptomatic of a bigger problem – our predisposition to focus on how rather than why. It’s a situation nicely encapsulated by the phrase “solving the wrong problem really well”. If you’re headed in the wrong direction, a more efficient car will just deliver you more quickly or cheaply to somewhere you don’t want to be. To borrow a quote from Albert Einstein, “If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.”
Transformation, or capability shift, isn’t simply a matter of implementing a new IT system or process. We need to change how people think and act. We need to persuade them to embrace the change. Our metrics need to reflect that. When we define our desired future state, we need to clearly articulate who will be affected by the change and therefore needs to embrace it for it to be successful. Our metrics need to track where those stakeholder groups are on their adoption journey because it will directly impact whether we achieve our desired business objectives – which should also be part of our project’s measures of success.
The specific measures for success for any project or programme will be context-specific but there are a few questions you should always ask as you start to consider them.
- “What is the need the project or programme is intended to fulfil?” This is a good time to use the Five Whys. Keep asking “Why?” until there isn’t a “because…” For example, installing that new CRM system isn’t an end in itself, you’re doing it because you want to be more customer intimate to reduce churn, decrease cost of sales, and increase profit. When you acknowledge that, you realise installing the CRM system is only part of a much larger task.
- “Who benefits and why?” Once you identify who the internal customer is, it’s easier to work out what constitutes success and how to measure it. While you’re doing that, don’t forget to ask who is affected and why. It’ll help you understand what you mustn’t break or make worse in the process – or what mitigating steps you’ll need to take.
- “When is the problem truly solved?” Are you done when the new software system is installed or old process changed? Or does something else need to happen before the desired benefits can be realised.
I’m not advocating abandoning time, cost and quality but rather suggesting everyone should acknowledge their limitations as measures of success. Instead, I believe they should be part of a more holistic scorecard that better matches the original rationale for change and better measures the desired benefits.
Peter Drucker may or may not have originated the line “What gets measured, gets managed” but it holds true regardless. The first step towards a successful project is knowing how to measure success and the best way to do that is to spend more time thinking about “Why?”. The most valuable things to have when you’re setting out on a journey are a map and a compass, not a stopwatch.
Here at Changemaker, we support organisations and individuals in delivering sustainable and lasting change. Our focus is on enabling successful outcomes through bringing deep experience and knowledge that helps our client build their own capability and success. If you want to learn more about us, take a look at our website (www.changemaker.org.uk/) or email us at email@example.com.