The Different Types of Benefits

Are all benefits created equal? No! There is a difference whether you can say that you will make one million USD or whether you expect that customers like you better. Not saying that the latter can be even more valuable, but it needs to be clarified what you will get out of this.

But is it even a benefit to say that customers like you better? The answer is a clear “It depends". It might be all that matters for a small café at the corner of a residential area. But it will be difficult to say how much a customer will like you better if you decorate the café differently. And it will also be challenging to say how your turnover will move by a different decoration.

But if I were a decorator, then I would happily sell the "benefit" of better-liking customers to the café owner, knowing that I would improve the turnover (and hence profit) with a nice decoration. Conversely, the company’s turnover might not change if you decorate a back office. But maybe the workers feel better? Is that a benefit? Possibly there would be beneficial knock-on effects.

What is a benefit?

Our definition is quite simple: it is a benefit if you find somebody willing to stand up and say, “This is a benefit", and is ready to spend his money (or reputation, or KPI, or... ) on it. It doesn't mean you have to deliver the benefit just because you have identified it, but there is a benefit, and you have a benefit owner.

Why is a benefit owner important? If you continue thinking about the café, imagine the decoration includes flowers or other plants. Someone will need to water them. Someone will need to take ownership of the delivered solution ("decoration") and start working with the delivered solution and realise the benefit (improved customer impression).

It is a typical situation that a solution delivered will not automatically create benefits. Instead, it will require some change in how the business is run ("care for plants") that will lead to the benefit. And the benefit owner needs to be the person who executes these changed behaviours/processes directly or via others.

By the way, it works as well in the other direction: if you go to the team lead and tell her that she can save 10min in a process by making a change to the team's processes, and she ("benefit owner") says no, then we don't consider it a benefit. She won't be willing to push for the changes needed, and the benefit will not materialise, at least not to the expected amount. She might have good reasons for her opinion, and it is worth listening to her argumentation. Was a similar approach already attempted three years ago and failed? Well, what could be done differently this time? And if she thinks that only 5min can be saved with the changes discussed, then the benefit is a 5-minute saving, not 10 minutes. If the benefit owner won't commit, then the project has no benefit. Ultimately, the benefit owner needs to feel responsible for the benefit if the project starts.

Structure to the help

It helps to think about the different kinds of benefits in a more structured way. The structure allows us to ask the right questions. There is a "hierarchy of benefits". The different benefits are described in the table below.

A measurable benefit is also observable, a quantifiable benefit is measurable, and a financial benefit is quantifiable. We all want to have well-defined financial benefits for every project. But actually, that is rarely sometimes the case.

We have seen a business case based on a clear financial benefit. The story was similar to this: The project team promised to shorten the time to do X from 20 minutes to 4 minutes. We have Y people working on doing X. The expectation was that the workforce could be reduced by 80%, amounting to a large annual sum of Z. The project was "successful" in delivering the change, shortening the execution time of X from 20 minutes to 4 minutes, which summed up to a vast sum of minutes saved by the hundreds of executions per day. However, the financial benefit didn't materialise. Due to the reduced time to execute and the resulting faster turnaround, more people requested the work from the team in question (a 2nd order effect). Ultimately, the team needed to grow to fulfil the significantly increased demand. Therefore, key stakeholders considered the project a big failure as the benefit wasn't delivered. But the project did exactly what it was supposed to do. It would have succeeded based on a quantifiable benefit of execution time(20 minutes down to 4 minutes). Financially (within the agreed measure, team size), it failed. Unfortunately, the project team couldn’t pinpoint a financial benefit steaming from a faster execution rate. And those weren’t part of the KPIs anyway.

A lesson from the story, always include a measure of the executions of X, not just whatever you measure about X. And you should consider whether a change of X might lead to a change in the number of executions.

What is the task of the benefit owner during the project?

Ultimately, our benefit owners must stand up for the project and its impact on their respective benefits. The project cannot change a team size; that can only be the person responsible for delivery who should therefore be our benefit owner. Hence, they have a unique role in project success and should be treated as such.

Projects often take months or years. I have seen a project being silent for over a year and then presenting a "solution” to an unprepared benefit owner. The solution didn't match its expectations, and the benefit disappeared whilst looking at it.

What to do? Turn it around! If you identified the benefit owners early on, you must work with them throughout the project. Keep the benefits owners informed during the process and double-check whether the proposed solution fits the problems. Make changes to the solution if needed. Adjust benefit size if required. But ensure throughout the process that you have the goodwill of the benefit owner (and still a viable project). Without them, the benefit will not be realised. You will need the full buy-in at the time the solution is ready. Or you could provide them with more but more minor changes, already testing the impact of later steps. This will provide you with significant insights for the rest of the project.

So, as project manager, just set up regular meetings with your benefit owners and discuss where you are. We suggest a minimum of every three months. It doesn't have to be a long meeting, but they need to know what the project will bring. And the project manager will need to adjust the project to the needs of the benefit.

Read More

You can read more about benefit realisation in this article.