About defining project success by the inputs
By Frank Jaffa on LinkedIn, Feb. 11th, 2020

On projects, the common success criteria are “on-time”, “on-budget” and “to-specification” – what is often referred to as the Iron Triangle.

Time, cost and scope are religiously planned, tracked and evaluated, with time and cost continuously being the key subject for status reporting and discussions on steering committee and management meetings.

For larger projects and programmes, entire controlling functions are established to provide, process and present data on time and cost.

If a project is completed on time and budget, it’s regarded as a success.

And if the project also completes the defined scope it’s an even greater success…

This is still by far the predominant view on project success, and regardless that the last 20 years have been spent on introducing new project management approaches and methodologies, in essence, the general perception of project success hasn’t changed.

Most projects (still) fail

Studies have repeatedly shown that projects more often fail than succeed.

The Standish Chaos Report is probably the best-known source for this information, but also studies from McKinsey, Boston Consulting Group, Deloitte and others show the same.

For the past 20 years enormous investments have been made in training and implementing methodologies, frameworks, and practices to make projects become more predictable and improve their ability to deliver what the business needs. Agile, Scrum, Kanban, Lean, SAFe, Prince2, MSP, etc. just to mention some, and the expectation could be that these huge investments would make the project success rate improve dramatically.

But, according to Standish, the project success rate in year 2000 was 28% and in 2018 it reached 42% when using Agile, while Waterfall remained at the 2000 level.

I think that we could have expected more, and I’m a bit pessimistic about how much more success rates will continue to improve with the current focus on project management, change management, portfolio management, etc. as long as we continue to ignore what it really is we are trying to achieve:

We execute projects to make change that creates value

The keyword in that sentence is “value”, not project or change. Projects and change are simply means of reaching the goal in the same way as time and cost are merely inputs to the project process.

So, we measure success for projects by the inputs and not by the outputs, and we train hard to become good drivers of projects without knowing exactly where we are going, as the destination – the outcomes, benefits and value - remain unclear.

The approach and the focus are wrong.

If we are to really improve on project success rates, we must focus on what we want to achieve. Therefore, value delivery and benefits management are the key elements to achieve better results and improved project reliability.

Value delivery and Agile

All the modern agile methodologies I know of all have one thing in common (and in common with Waterfall), and that is the lack of focus on the business value that the project is commissioned to deliver. That is clearly a shortcoming.

Sometimes, when talking to Release Train Engineers, Project Managers, Scrum Masters and Product Owners about this, they claim that the agile methods actually do handle business value.

But I disagree from a value delivery perspective, as the methods don’t make the value, the benefits and the outcomes the key focal point for projects. They address the "how we produce" and not the "what we produce".

Addressing how we run projects responsibly in a good, structured, transparent and involving way is of course very important. It is as important a prerequisite for running successful projects as is the management of benefits and value. But neither of these can stand alone. To be truly successful we need both, and by running projects with sole focus on the "how we produce", we may end up executing projects perfectly - on time, on budget, to specification - but producing something there is no need for and thus isn't worth the money and effort.

The business value, the benefits and the desired business outcomes are the reason why we run projects. They are the real measures for project success, and thus they should be handled as thoroughly as we handle time and cost.

Value Delivery is simple

Value Delivery and Benefits Management isn’t hard or complicated at all. There are methods, tools and processes available to be taken into use, but basically for a start it’s just a matter of changing the traditional approach to project execution from being focused on the inputs to defining, tracking and managing the outputs.

If this matter is of interest to you or you’d like to have a talk about how to improve project success and value delivery in your organisation, simply reach out to me.