True measures of project success

I recently saw reference to an academic paper that said in the summary: “On time, on budget and to specification were not the only measures of success – there was fourth, equally important measure.” I thought, Hallelujah they’ve seen the light and recognised that delivery of the business benefits is an important measure of success.

Not so. The fourth measure of success was, “That the project team had a good experience!” Ah well, a faint hope for a few minutes.

But it raises the question of what is ‘success’?

Many projects target ‘critical success factors’ by which they mean the most important success measures. This suggests that the project and governance teams can pick and choose which project measures they’ll target and deliver and which they’ll neglect or discard. Nice in theory but in reality what you do and don’t do has downstream implications: if not on the project then on the ongoing business operations.

If you are going to discard some measures of success you also need to know, track and measure the downstream impacts. Just because it doesn’t impact the project (except by reducing the workload and cost) does not mean it is a safe decision, even if the governance team signs-off. This is a dangerous and unnecessary approach.

Another common measure appears to be ‘stakeholder satisfaction’. If the stakeholders are happy then all is well. Well no, this is not a valid measure. On problem projects, getting anything over the line will make many stakeholders happy: “It’s finished, I can focus on something else.” But this is not what the project was commissioned to deliver, however happy the stakeholders are.

Admittedly, an otherwise successful project can be deemed a failure if it is not well implemented and thereby alienates the stakeholders. How you implement is as important as what you implement. But this does not override completely ‘what you implement’.

If you invest in building a four-bedroom house with a study, delivery of a four-bedroom house without a study (because it was not deemed a critical success factor or the wife signed off on its omission) is not ‘success’—it is, at best, compromised success.

Let’s get back to basics.

At the outset of a project (or at least at the business case stage) a set of clear, specific, measurable desired business outcomes, associated business benefits and their value are approved to be delivered. ‘Success’ is delivering these outcomes, benefits and value in full.

There are a few caveats to this statement.

• The cost and time of delivery need to be efficient so that they don’t overwhelm the value delivered.
• The delivery and implementation process needs to be effective so that the solution is well adopted and fully used.

But the baseline is: what the organisation agreed to invest in at the business case stage is what is delivered—efficiently, effectively and for the least practical cost.

Your project’s ‘value proposition’ defines the proposed measures of success. While the value of the financial benefits may legitimately change due to external factors, the outcomes and their benefits should not change but be protected by the governance team until they are fully delivered.

Picking and choosing what you’ll consider as ‘success’ can only be done at the business case stage, not during the project depending on what you can deliver or what the stakeholders will let you get away with.