Five Fatal Flaws in Project Metrics

Have you ever heard of project success defined as that project being completed “on time, within budget, and to scope?” This traditional definition may have been useful for project leaders in the past; however, there’s much more to consider for present-day programs. 

The Five Fatal Flaws of Project Metrics 

Only using project metrics focused on time, budget and scope are flawed because they do not account for important project and business success factors. Let’s look at what time, budget and scope DO NOT ACCOUNT FOR in their metrics.

1. They Do Not Account for Benefits Realisation

A project should be measured for its return on investment and whether or not the intended benefits of the effort were realised. That’s an important measure of success that links back to the initial strategy, business case and why the project was undertaken in the first place.

2. They Do Not Account for VUCA

VUCA is an acronym for volatility, uncertainty, complexity and ambiguity. The term reflects the unpredictable nature of the world whether it’s the speed of change (V), lack of predictability (U), confounding cause-and-effect reactions (C), and the mixed meaning or misinformation surrounding a situation (A). 

Given the pace of change in the market and the global impact from Covid-19 alone, project metrics need to account for ‘learning and adapting as you go’ on a project. A successful project is one that had the foresight to adapt to the market and pivot, rather than carry-on to deliver on time, budget and scope for something the world no longer needed. 

3. They Do Not Account for Team Health and Wellbeing

One of the unfortunate knock-on effects of using traditional project metrics is that it’s been acceptable to under-resource a program and/or ignore raised issues and risks to stay under budget and on scope. 

When a project delivers on time, in budget and to scope, and then the majority of the team departs the organisation from burn-out (taking their knowledge and expertise with them), that is not a success for the business. 

4. They Do Not Account for Business Integration

A project that is deemed a success in terms of time, budget and scope, but was delivered in a silo without end-to-end integration is not really a success for the business. 

A downside to using traditional project metrics is that scope may be ‘reduced’ for the sake of budget and time. It is reasonable to run a proof of concept with a limited scope, and that is different. It is less reasonable to plan a program that requires manual workarounds, or does not account for the customer journey across departments, or ignores the role of a key department, like Operations. 

5. They Do Not Account for Re-work After Delivery

During the testing phase of a project, unexpected issues arise. It’s a good thing because that is the point of testing the product/system/platform, etc. Unfortunately, when the outcome of testing results in a delay in time to fix issues, an increase in investment for the fix and re-testing, and even a possible scope shift to add an important feature, a project outcome may be compromised if the baseline for time, budget and scope cannot be reset. 

If a project is compromised in this way, there is likely to be re-work to fix bugs and malfunctions. There is also a cost to poor customer and employee experience. When that happens - and even if the project was delivered on time, in budget and to scope - it’s not really a success for the business.  

One of the really important metrics is benefits realisation. The benefits are the WHY behind the project and the investment. It’s important not to lose sight of the big picture of these benefits along the way. 

Here is a brief example to explain the importance of benefits realisation in a common, current project focused on the transition to the future of work. There are at least four points in this project where it’s important to define and measure activity for the purposes of analysing effectiveness. The 4 points (with examples) are:

1. Program Milestones (The plan was completed to transition to a hybrid work model.)
2. Program Go-Live Milestones (New practices and systems went into effect to support the hybrid model.)
3. Adoption Milestones (Employees took up the hybrid model, new behaviours, practices and systems.)
4. Benefits Realisation Milestones (Employees reported feeling connected. Employees collaborated well virtually. There were no reported feelings of isolation.)

Consider the metrics that you use to measure projects’ outcomes, benefits and return to the business. If you have any questions on the topic, pop them into the comments section below. We’re happy to help. Alternatively, if you think this article would benefit your project team or network, feel free to share it and tag us!