Skip to content

3 quick tips for building a “benefits friendly” business case

Introduction: Business cases are critical for projects


Blue darts hitting green targetsAs regular readers of this blog will know, I’m a firm believer that organisations should progress business and IT change projects for the right reasons.  The harsh reality is that all organisations – whether mid-size or multinational—have limited budgets for change. Naturally their executives and sponsors look to maximise the value for money they gain from their projects.   Whether the project is to implement a new process, a new IT system, or launch a new product, it’s vital to know the likely financial consequences before making a decision.   In order to assess this, decision makers need a firm view of the feasibility, costs and likely benefits that a change project will bring. This is often expressed in some form of business case or as part of a feasibility study.  This becomes central to the change project, and should be revisited whenever there’s a material change in scope or when new information presents itself.


A clear business case enables senior decision makers to see the “size of the prize”.  Putting it simply, they can see the size of the bet they are placing.  How much money do they need to invest in the project? What return are they likely to get and over what period? And what other impacts might the project have.  This is all essential decision making information which helps executives and project sponsors to decide which projects to pursue.


The business case lives beyond the project… but watch out for the trap!


The business case lives on beyond the project lifecycle.  Ultimately, at some point in the future once the project has been delivered, the business case should be used for a benefits realisation exercise.  This typically involves checking whether the organisation actually achieved the benefits that were projected.  Perhaps the project is hoping to increase operational efficiency by smarter use of IT, enabling the organisation to deal with 10% more customers (and make 10% more sales) per annum. Or perhaps it’s going to reduce customer waiting time by 50%.  Assessing the benefits actually achieve helps organisations to learn lessons from previous projects, but also may uncover opportunities for further improvement.


However, there’s a common trap here!  The reality is that measuring the business benefit is impossible if the organisation doesn’t have a true and credible benchmark of how things were before the change.  If you run a project to reduce customer waiting time, but you can’t currently measure this, how will you know if the goal has been achieved?  Finding this absence of data after the project has been delivered is extremely frustrating; it means the organisation has spent money and it will never know whether that spend was worthwhile.


Three tips that can help


Here are three key considerations to keep in mind when aiming for “benefits friendly” business cases:


1. Ensure you can benchmark the status quo:  As mentioned above, if you can’t measure the current performance, then it is impossible to determine objectively whether performance has improved.  If you suspect there will be benefits, but cannot measure the current performance, these can still be mentioned in the business case but without a specific figure.


2. Build data collection into your processes:  Having established the benchmark, ensure that you have processes in place to continue to collect the data you need to assess whether the project has delivered the expected benefits.  It can be highly beneficial to automate this and employ an appropriate analytical solution.


3. Ensure you can disentangle benefits:  The reality of course is that organisations are often progressing several change projects at once.  If you are running 3 projects, all of which are aiming to produce a 10% increase in sales, and 12 months later you’ve seen a 15% increase in sales, how can you determine which projects have succeeded and which have failed?  This is a complex area, but again, ensuring you collect the adequate data (and have the capability to ‘crunch’ the data) is important.


Whilst not an extensive list by any means, keeping these three considerations in mind from the time the project is conceived will help you to write a “benefits friendly” business case document.


I hope you have found this article useful.  What are your views on business cases and benefits realisation? I’d love to hear them – please add a comment below.  – Adrian.



This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.


IBM Logo



tumblr tracker

4 thoughts on “3 quick tips for building a “benefits friendly” business case”

  1. Great article. I usually see two big problems with business cases and/or project visions.
    1) The complete lack of a Current Situation Analysis – as you said, if we don’t know where we are, it’s pretty hard to know if have reached our goals. Not to mention if we don’t know where we are, we can’t really know whether we want to stay or go.

    2) The distracted tourist symptom – as the project goes along, we see some benefits, we discover some additional benefits we could achieve in unrelated areas and scope-creep. Seeing something “not that far” from our original path we take a detour. And like on a vacation that has a definite end in time, we end up wasting time on things different from our original goal.

    Projects, especially with lots of people on board tend to develop a special kind of ADD, and without strong management it can turn into a bit of a mess after a few months – interestingly enough, Agile methodologies are very prone to this after all “we are Agile, we can do!”. But that’s the problem of people not understanding Agile, not the methodology.

    This can be solved by starting new projects with new business cases for the “roadside amazing little chapel you must see it’s awesome” things. And that needs a confident, strong management on top.

    1. Hi Roland,

      Thanks for the comment. I agree wholeheartedly and I really like your description of the “distracted tourist” symptom. On major programmes, lack of focus can certainly be an issue. In fact, different stakeholders — even senior stakeholders — might have completely different visions over what the project can achieve. Perhaps the Marketing manager is aiming for increased revenue, but the Production manager is aiming for increased revenue *whilst staying within operational capacity*. Two subtly different world-views on the same project, that are likely to lead to conflict!

      I agree about the business case, and in many ways I think that these sort of things can be nipped in the bud before them. IIBA BABOK would call this “Enterprise Analysis”, but I tend to call it ‘pre-project problem analysis’ — i.e. establishing the WHY of the project: “What problem are we trying to solve here?” and “How will we measure success?”. Or put more succinctly, what is the business NEED and the drivers? These all feed into feasibility and the business case for sure… but a simple 1-pager saying “Here’s our problem” can really help!

      Thanks again for the comment 🙂


  2. Disentangling benefits from the wider business / economic context is a minefield… if you find the project’s sales growth target has been met, it’s tempting to call the project a success even though the growth may be due to, say, a rising market. If the target isn’t met, out come the excuses – e.g. a rival has released a competing product – which may or may not be valid.
    Baselining the as-is position and making sure you’re able to measure the change is certainly a very sensible addition to a project checklist!

    1. Hi Jon, thanks for the comment! You make a really interesting additional observation — that increased performance/sales might *actually* be related to a completely separate factor or factor(s). As a completely random side-thought: This could get even more tricky to measure if, say, you were a company that makes tonic water. Your sales might be directly proportionate to the sales of gin (cross-elasticity of demand, as I believe economists call it!). So, if you launch a brand new type of tonic water, and you see an increase in overall sales… is that due to the product *or* is it because gin consumption has increased? Of course, if you *know* that relationship exists, you can adjust for it…. but there are all sorts of weird and wonderful unexpected variables that might apply. In situations like this, it’s virtually impossible to do a scientific ‘double blind’ test… As you say, a real mine-field… and short of knowing the complexities of every variable, it’s difficult to see how it can be completely overcome. Although perhaps this is an area where ‘big data’ could help and add some insight…

      Thanks for the thought provoking comment 🙂


Leave a Reply

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