Skip to content

Benefits Realisation Shouldn’t Be A Witch-Hunt!

  • Adrian Reed 
  • 6 min read

Unhappy/angry office worker with head on deskOrganisations that initiate projects generally do so to embed some kind of favourable change into their operation. The types of outcome and benefits desired will vary depending on the organisation’s situation and strategy, but might involve increasing revenue, reducing costs, achieving regulatory compliance, improving customer service or any other combination of goals. Let’s imagine that a financial services organisation decides to streamline its ‘customer sign-up/on-boarding’ process. Possible benefits might include providing enhanced customer service (leading to an increase in sales) and lower processing costs (leading to higher profits). There are likely to be many different ways of achieving these outcomes—and those options are likely to be examined in some form of business case. For small projects this might be a very lightweight document, with larger projects and programmes needing a more thorough and formal document. Either way, the relative pros/cons of various approaches will be considered—including the tangible and intangible costs/benefits, and also the risks.


The business case is often the gateway to getting a project off the ground. In many organisations it is like a key to the cheque-book—until the business case has been signed off work cannot start with any vigour. This leads to a useful focus on a business case early in the project lifecycle—which is a good thing of course—but once the cheques have been written, interest can start to evaporate very quickly. There is a danger that the business case will fester away, collecting dust in a document repository rather than being seen as a ‘living document’ that is central to the project and change initiative. This can lead to some very unfortunate outcomes.


A business case shouldn’t be “one and done”

There are a whole range of reasons why a business case should be regularly re-visited. Ultimately, however much we might like to pretend that we can foresee the future, the reality is that a business case is a prediction—a “best guess.” As more information becomes available, our view on the calculations and assumptions in the business case may change. We might find out more about the likely costs, benefits or complexity of the situation. The decisions made within it should be re-visited regularly throughout the project to ensure that the project is still viable and on the right track. This activity is useful right through the project, right through to the often avoided “post-project benefits review exercise.”


When you think about a post-projects benefit review, it is easy to understand why there may be some resistance. It doesn’t always sound like a very compelling prospect—what we are really saying is “Let’s spend time months or even years after the project has launched to check that the benefits we predicted were actually delivered.” Saying these words can cause a project sponsor’s eyes to glaze over. What possible good can this bring…if the benefits haven’t been achieved, won’t this start a witch hunt? A session in identifying a convenient scapegoat?


It really doesn’t have to.


A properly conducted benefits assessment exercise can help accelerate organisational learning and enhance and improve future business cases. It shouldn’t be an exercise to find a scapegoat and allocate blame unnecessarily. It is worth remembering of course that if the project was well executed, with regular collaboration between a business analyst and project manager, then there’s a good chance the benefits will have been achieved (or even exceeded!) and this will be a cause for success.


Carrying out this type of exercise helps in so many ways, including:


1. Identifies other improvements: If the project has only achieved 60 percent of the projected benefits, perhaps there’s a small incremental tweak that will unlock the remaining 40 percent. The organisation will thank you for this!


2. Other benefits: Once the solution is in operation it might become apparent that it can be used in different ways, by different people or in different locations to achieve a wider set of benefits. This is worth considering and investigating. If the solution is rolled out elsewhere, this may spawn another project, with its own business case.


3. Changing business environment: Perhaps the reason that the benefits haven’t been achieved is that the business has changed. Maybe further incremental (or radical) changes or projects are needed. This exercise may act as a useful ‘wake-up call’ to keep things on track.


4. Prevents over-inflated business cases: Most people reading this blog will have seen situations—at least once in their career—where a business case has been deliberately over-inflated. Perhaps the benefits have been overstated in order to get the money for the project. By carrying out an assessment to assess the benefits, we enable this to be highlighted so that relevant questions can be asked. The very fact that stakeholders know that benefits will be assessed may stop the temptation to over-inflate benefits in the first place!


5. Celebrate the successes: Finally, assessing the benefits allows us to celebrate our successes. It really isn’t all doom and gloom—a well-executed project is likely to deliver the outcomes and benefits that are needed. Some might even over achieve—these can be ‘modelled’ and any learning points can be carried forward. In some cases over-achievement might mean that the solution can be scaled down (saving even more costs). Either way, celebrating our successes—and articulating what made those initiative successful—means we are more likely to repeat them in future.


So, whether you’re an internal business analyst working with internal clients, or a managed service provider delivering services for external clients, it is very worthwhile keeping an eye on the business case and encouraging a benefits review exercise. The organisation and your clients will thank you for it in the long run!



Do you have any suggestions or thoughts related to business cases or benefits realisation? I’d love to hear from you – please add a comment below!


If you’ve enjoyed this article don’t forget to subscribe.

Subscribe to Adrian Reed's Business Analysis Blog



This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business

IBM Logo

tumblr tracker

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.