The Purpose-Benefit Gap: Are You Missing the Bigger Picture?

I’ve always been more benefits-focused than your average Project Manager, but focusing too much on the benefits can create problems too. It appears that too much of anything really is a bad thing.

Benefits are not why we do projects

OK, sometimes they are. But often they are not. Sure, it helps if a project has benefits that outweigh its costs. It also helps if people know how to measure things properly and how to define benefits properly but I gave up hoping for that miracle years ago. Regardless, not all projects are done for benefits.

Over the last 7 or 8 years, most of my projects have been in the Modernisation space. Where the aim of the project is to take an existing asset, or set of assets, and make them more modern. There are benefits for these types of projects. Benefits typically fall into camps of risk reduction, operating cost reduction, software cost reduction, increase in development speed, reduction in cognitive load. But it can create problems if you focus too much on just the benefits.

That sounds far-fetched. Can you back that up?

Let’s take an example. Let’s take the example where we have a particular asset and there are two schools of thought about how to treat the asset.

School one says we should lift and shift the asset to a more modern platform. All the problems that exist in the technology today, will exist in the future. All the bugs will be copied over as-is. We will make no improvements on the way, just a copy and paste.

This is the benefits-focused approach. The quicker we can get rid of the old, the quicker we can realise the software cost saving, the operational cost saving and the risk reduction.

School two says that we should remediate as we modernise. Sure, move it to a more modern platform, but fix bugs as we go. In fact, look for opportunities to improve as we go too. This means carefully examining every component and evaluating what improvement opportunities that there are. Rather than treating all parts of the asset equally and applying the one treatment, this approach might apply a unique treatment to each part of the asset.

This approach costs more - a lot more. It takes a lot more time. It’s a lot longer until the benefits are realised. And it might just be the preferred option.

Mind the gap

It comes down to WHY are we doing the project? The purpose of a project doesn’t have to be the realisation of the benefits. The realisation of the benefits supports the business case, but the purpose can be tangential.

If the purpose of the project is to “modernise”, one could argue that automating some parts that are manual today, or rewriting the code using a low-code technology, or working out which bits of code are not widely used any more and deleting some code on the way, or taking apart each part and making them into microservices with APIs would all create a more “modern” end state. That might be longer and more costly than a lift and shift. But it might closer address the purpose.

When you’re too focused on benefits, you run the risk of falling into the gap between benefits and purpose. Purpose drives our why and benefits don’t always fully articulate the purpose.

The Bridge

The bridge between the purpose and the benefit, is the outcome. The outcome is the state change or behaviour change that you want for the project. In our example, the outcome could be reducing processing time (state change), or reducing the number of times someone needs to touch the code in the next 3 years (behaviour change), or removing key person risk (state change), or using technology patterns that are more commonly understood by the developers (state change). All of these could be valid. And all of these could be missed if the focus is too tight on benefits.

Delivering benefits is important. But projects that focus on delivering outcomes often deliver a stronger end result than those that focus exclusively on benefits.