The only reason we do projects is to get some kind of benefit for our companies. That might be the right to stay in business (as would happen if you were working on a legal/compliance/regulatory project or something similar) or a financial or other commercial benefit. Without benefits, there isn’t much point in doing projects.

I think everyone realises this, so apologies for stressing the point. What I want to look at today is what barriers you might face when trying to get those benefits in the business case turned into something tangible and useful for your company.

I understand that traditionally project managers haven’t had much to do with benefits realisation. This has been seen as the role of the programme manager, or a business change or operational manager. But I think this is a narrow-minded view of what the project manager can do. And a lot of issues with benefits realisation start with the project’s delivery phase. You have to build in the ability to get the benefits while the project is taking shape. And who better to do that than the project manager?

Let’s look at some reasons why projects don’t get the benefits that are predicted and what you can do about them.

1. Ownership

Who is responsible (long term) for delivering the benefits? This tends to be the person who wrote the business case, or the project’s customer. But it isn’t always that person, and often benefits realisation can fall through the cracks. Someone believes it is the job of someone else in a different team. As a result, no one actually takes responsibility for delivering or measuring benefits and you can’t prove if the project was successful or not.

One way to help people take accountability for delivering the benefits is to put it in their objectives. If people are assessed on something then they usually get on and do it. So rewriting their performance objectives to include hitting these new targets as enabled by the project could be a step in the right direction. Couple this with reward mechanisms such as bonuses for hitting certain targets. Financial measures will work for some people but not in all cases, so use these with care.

There’s another problem as well. The business case benefits might look great on paper, but the project sponsor might believe that they are unrealistic (especially if they weren’t responsible for the data that went into the business case). If that’s the case, they may resist taking ownership for that level of benefit and try to disengage from the whole benefits piece.

Actions to address this:

  • Project plan should include tasks to identify benefits owner(s).
  • Project plan should include tasks to set up reward and recognition schemes if appropriate for benefit owners/teams delivering new benefits.
  • Project plan should include tasks to ratify benefits and review business case targets. Make this a repeating task that occurs at several points throughout the project as whether or not you can achieve business case targets could change as the project progresses.

2. Technology

Projects (or rather, project owners and sponsors) can get carried away with new tools. We see it all the time with system implementations that don’t deliver the promised streamlined processes, or ERP projects that spiral out of control and take years to get anywhere near any level of usefulness. That’s normally because the technology isn’t used effectively and the business processes aren’t updated and changed to reflect new tools. Don’t replace old, manual processes, with the same way of doing things – just electronically. Technology should support your business processes and often presents a great opportunity for reviewing how things are done.

Sometimes projects fail to deliver the predicted benefits because IT suppliers walk away after the installation is complete. That isn’t their fault: they are not contracted to hang around and provide support unless the project team engages them to do so.

Actions to address this:

  • Ensure project activities include process reviews so that technology is used intelligently. A business analyst can be a huge asset to your project team here.
  • Project plan should include adequate tasks to set up operational IT support model, including third party support if required. Or adequate handover to internal teams to enable efficient running without third party intervention.
  • Budget should reflect ongoing support costs of third party support or training internal resources to do the same job.
  • Make sure you know how to use your own project management software. Tools like iMindQ help you structure your ideas and project tasks, but if you don’t use them to their full potential you will lose time and find your project team members feel frustrated.

3. Timing

Sometimes project benefits aren’t realised because the timing is wrong. Major change after major change is tiring for people and if you are already stretched to capacity then taking on something else is likely to be too much. In turn, that means project investment is lost because the operational teams don’t embrace the change and use the new tools they have been given to deliver great results for the business.

Actions to address this:

  • Review the project plan with major stakeholders and also those who are aware of other projects going on such as your programme manager or PMO team. Make sure there are no significant clashes and that you aren’t expecting one team to deal with too much change at a time.

4. Capacity for change

Timing of a project is one thing – you can’t expect to implement a project when a department is going through another massive change and still get the same results as if you did it at a time when things were quieter and they were focused 100% on your initiative. Capacity for change is slightly different and relates more to an individual’s ability to get on with working in a new way.

Without the appropriate support and training, users will not adopt new ways of working and therefore won’t be able to deliver the expected level of benefits. This is hardly news, but sometimes the knock on implications for benefits are overlooked. Training focuses more on how to complete tasks ‘the new way’ and not about why they are doing it this way and what benefit that brings to the company.

You’ll also have to deal with people who are resistant to change, regardless of how much training and support they are offered.

Actions to address this:

  • Project plan should include adequate training for users.
  • Project plan should include an adequate support period after project has gone live.
  • Communications plan and stakeholder management plan should address how to deal with employees resistant to change.

5. Culture

However positive your project sponsor when the project starts, sometimes organisational culture simply gets in the way of a good result. There are several things at play here. Often the business focus is on driving down costs and not on achieving value. In other words, spending money on training may be seen as an unnecessary investment but in reality it will significantly contribute to the delivery of value (and, of course, everyone needs to agree on what ‘value’ is). Keep the project culture positive by sharing quick wins, and putting in place a good communication plan so that everyone can see how the project is working towards delivering benefits. Make value and benefits part of the regular project messages. This has the added advantage of helping people see that those business case targets are achievable, and this is a good way to win round the skeptics.

Actions to address this:

  • Communications plan should cover positive messages and bringing on board local champions to help build a positive culture around the project.

6. Data

Sometimes project benefits don’t get delivered because the data is wrong, or flawed. This can happen at the point of business case creation, for example using incorrect assumptions to calculate predicted future sales, or during the project, or afterwards. I’m sure you have seen this too: business cases put together based on information that is difficult (or impossible) to measure and then teams tasked with ‘proving’ that the project has been a success. Good data starts at the beginning of the project with the business case, and as a project manager you may not be involved at this point. However, you can review the business case once you are assigned to the project and put tasks on your plan to ratify the data and ensure that you are still on track to deliver the agreed benefits.

Talk to your project sponsor about how they intend to report on project benefits later and then you can build in a mechanism for them to do this. For example, if they intend to report on new sales as a result of your marketing campaign, your project needs to include tasks to enable the marketing campaign to be linked to new sales and a report produced showing how many sales were generated as a direct result. You’d use something like a campaign code for this – it’s a very simple example but it helps illustrate my point and you can see how that would translate into appropriate data and reporting for whatever it is that your project is delivering. Even if these reports are not used during the project you can (and should) build in the functionality now.

Your PMO team may have more insight into how to get the project data to be as accurate and reliable as possible so that it is of use for management decisions. Don’t be afraid to draw on their expertise, especially if you have concerns that your benefits look unrealistic. 

Actions to address this:

  • Project plan should include regular reviews of business case to ensure project is on track to deliver against stated benefits.
  • Project plan should include tasks to deliver appropriate management information tools/data to help benefit identification and reporting later on.

Hopefully your projects haven’t suffered from difficulties identifying, recording and reporting benefits, but if they have in the past you can use these pointers and actions to avoid that situation in the future.