The Project Management Institute (PMI) found that only 9 per cent of organisations ‘do benefit identification extremely well’ and that ‘35 per cent of project benefits are often overly optimistic’. According to a KPMG study, ‘Only 21 per cent of organisations consistently deliver on their benefits’. A recent McKinsey report discovered that ‘17 per cent of IT projects go so badly that they threaten the very existence of a company’. More than a quarter of the organisations surveyed by KPMG New Zealand ‘do not undertake any form of strategic review to track the benefits realised by the business’.

I’m deliberately labouring this point — stay with me …

ABC News announced, ‘The government approved a $1.5 billion payment to the Victorian state government for the East–West Road Link project, without any form of cost–benefit analysis’. The Auditor General’s report into the road project commented, ‘The likely net benefits of the project were not sufficiently demonstrated’.

The PMI has calculated that ‘83 per cent of organisations lack maturity in benefit realisation and waste $122 million for every $1 billion spent’. Turning to the NZ Gateway Review paper into Government projects: ‘Concerns continue around the application of core project and programme management disciplines and processes, with a startling proportion of recommendations showing a lack of maturity in benefits realisation’.

It’s depressing, isn’t it? I’m almost in tears just writing it. And every year, we wheel out the excuses, when in reality there are only three reasons for not getting the benefits we expected:

1. We were overly optimistic in the business case (or exaggerated the potential) in order to get the funding in the first place.
2. Market conditions changed during the course of the project, reducing the benefits we could expect. We decided it was worth pursuing anyway.
3. We don’t care enough as leaders to do the hard work to get the benefits once the project has finished.

As the project sponsor, you are responsible for ensuring that the project provides the benefits promised. It’s not the project manager’s job. They are responsible for ensuring that the asset gets built.

So there’s no confusion, when I say benefits I mean outcomes, essentially the ‘rewards’ you get as an organisation once you complete the project. And that’s why it’s not the project manager’s job to ensure you get them. Their job ends once the asset has been built and handed over to operations; yours doesn’t. At that point you revert to the role of benefits owner and make sure the organisation does everything it said it would in order to save money, earn money or change the way it operates.

Sadly for most, the project ends but the malady lingers on for one of the three reasons just listed. Here’s how to avoid them and be the sponsor and organisation that delivers on its promises every time.

Optimism/exaggeration

When you want something there’s a temptation to overstate what you can achieve once you have it. If you’ve ever bought fitness equipment for your home you’ll know exactly what I mean. Not only will you be saving money on that gym membership you never use, but you’ll be able to keep fit every day of the week without any excuses. Result? Three months later, the equipment is gathering dust in the garage and you’re three kilos heavier.

Avoid the temptation to do this — to overstate benefits I mean, not to exercise. You should definitely exercise.

When doing your analysis in the early stages of deciding whether or not to undertake a project, always err on the side of caution and go with the lowest possible expectations. It’s always better to underpromise and overdeliver.

This means ensuring the planning process is comprehensive so you understand what you’re in for from the start. I’ve seen too many projects deliver a negative ROI because not enough work was done to establish the ‘true costs’.

If, once planning is completed, the project numbers don’t stack up, then stop, straight away. Continuing because you’ve already spent money on planning (sunk costs) is just about the worst thing you can do. Another is trying to get a different answer to the same question. It doesn’t stack up. Period. So stop it.

Market condition changes

One organisation I worked with produced a strong business case to introduce Blackberrys across the senior management team, back when the Blackberry was still a thing. It was going to cost around $100 000, but the tangible benefits for fieldwork and their disparate office locations meant it was a relatively easy decision to make. They also wanted to demonstrate to their customers that they were early adopters when it came to technology.

Then the rumours of an Apple phone started to circulate. They were quite wild to begin with, but essentially it was going to do everything a Blackberry could do, but with greater flexibility, increased security and less cost. At that stage the project should have been stopped and deferred until a time when more was known about alternatives, but they ploughed ahead. The money was spent, the handsets were distributed and the training undertaken.

Then the iPhone was released — and no one wanted a Blackberry anymore. Instead they wanted something that gave them the opportunity to use (hitherto unknown) applications to increase productivity further. The Blackberrys were replaced six months later.

In this ever-changing world of ours, there’s a good chance that something new will come along once you’re in the middle of your project, and ignoring it or pretending it hasn’t happened isn’t a viable option.

If market conditions change, such that you’re unable to get what you expected, then you need to stop and re-evaluate the project before it’s too late. An excuse I hear all the time is that organisations simply didn’t know they wouldn’t be able to get the benefits they expected. In reality they couldn’t be bothered to put in the work to find out, or else they took their eye off the ball completely during the project.

What you don’t do at this stage is put the project on hold. There’s nothing more confusing to the team than when senior managers do this. It creates widespread confusion over whether or not the project is still a priority. What you do is pause the implementation in order to re-evaluate the plan.

If you’re using an agile approach, this is much easier to do and is even expected by the team. If you’re taking a waterfall approach, though, you may need to commission some people to investigate the potential ‘new’ option and do some analysis on how it would impact your current time and cost estimates.

Only once you’ve gathered all the information, and understood its impact on the outcomes, can you make the decision to restart, replan or stop altogether.

No one cares

Perhaps the biggest reason for not getting the benefits is the fact that senior leaders just don’t care enough to follow through. It’s too hard. There’s not enough time. I didn’t believe we could do it in the first place. It’s not my job. Excuses, excuses, excuses.

Having committed to the project in the first place, it is your job to see it through. Go back to the business case or justification for doing the project and make the changes you promised you would. Show how much you care and help the organisation achieve its strategic goals.

If it’s an organisation-wide problem, then suggest that when people declare financial benefits in business cases, they also declare the budget line to be reduced or the sales targets to be increased the following year. Nothing makes benefits real better than taking money from people or increasing their targets.

This was an approach I used successfully in my roles heading up project departments. Where senior managers declared cost savings or revenue increases, then these numbers were immediately baked into the following year’s budgets to provide solid accountability for achieving them.

In one organisation, this approach reduced the amount of new business cases by half, which meant we delivered on our business plan promises and weren’t distracted by new pet projects. We recognised there were some senior managers who wanted to buy things and cared little about achieving the benefits they themselves had outlined in order to get a project approved. Don’t be one of these people.

As sponsor, you’re going to ensure that the products the project manager builds will give you the mechanisms to get the benefits you promised. You will follow this up with them every month.

Apathy towards results has no place in leadership roles. Don’t become another statistic when it comes to realising the project benefits. After all, they are the reason we do projects in the first place.