Business Case as a Roadmap


The creation of a business case is too often viewed as a step in the process to get a project approved.  Instead it can, and should, be used as a roadmap to prioritize activities during the project implementation and keep the team focused on the key objectives.  This failing is largely due to a common perception that ‘we all know this just needs to get done’ and a subsequent lack of focus on defined outcomes.  Benefits realization needs to be actively pursued rather than assumed as a natural result of implementing the changes that the business case was used to justify.


‘Business case’ means a lot of things to a lot of people.  At one extreme, this author observed a $125M systems implementation justified by three bullet points on a PowerPoint slide.  At the other extreme was a much smaller systems implementation that required a cash flow forecast to be developed in monthly increments for five years, incorporating details as granular as employees’ holiday schedules and their expected promotion salary increases.  Both were worthless.

‘Feeding the green monster’ is a common problem when developing a business case. The spreadsheet becomes the focus of attention instead of a tool to support the analysis.

‘Worthless’ may seem too strong a term but the fact is that neither of these business cases helped in the decision making process to approve or disapprove the initiative and both were filed away and lost as soon as the decision was made.  Senior management in both cases made their decisions on the basis of hope, fear, and politics and then tasked the project teams to put in a system.  They lost the ability to define the narrative.  This meant that the projects became task driven rather than outcome based.

Contrast this with another system implementation that this author was involved with (system implementations tend to generate business cases in exactly the same way that market studies don’t) where the consultants’ fees were dependent on the benefits realized.  This was one case where the business case was most definitely not filed away and forgotten as soon as the initiative was approved.  There were literally sixteen million good reasons to continually focus on the business case as the work was performed.  The contract called for fifty cents to be paid to the consultants for every dollar of working capital benefits that were realized, up to a maximum payout of $8M.  This forced the team to continually ask themselves what impact their work would have on the business and if this would flow through to measurable benefits.  This didn’t mean that activities were abandoned if they didn’t relate directly to working capital but the right questions were being asked.


In the narrative above, there is an implicit understanding of what a business case should do.  Let’s make it explicit: a business case should indicate the business benefits to be obtained from an initiative and should be used to drive the right behavior during the implementation of that initiative.  Although this paper is primarily concerned with the second half of that sentence, we should spend a moment making sure that we understand the first half.

The business case should “indicate the business benefits to be obtained from an initiative”.  This requires a baseline; the situation that will occur if the initiative does not take place.  Does anyone out there have a functioning crystal ball?  Going back to the earlier example of a $125M system implementation that was justified on the basis of three bullet points, the year was 1997 and the alternative to a new system was a vision of aircraft falling out of the sky, bank accounts being lost, and cars bursting into flames when the clock struck midnight on December 31 two years later (okay, perhaps the flames was a bit of an exaggeration).  This was an extreme case based on (perhaps unnecessary) fear but it’s always important to understand what you are basing the alternative scenario on.  An equally absurd example (although with fewer flames) that the author came across was at a successful bio-technology company that decided to implement, you guessed it, new systems.  During the previous ten years, whenever the company’s revenue grew by 15%, employee numbers grew by 15%.  When revenue grew by 22%, employee numbers grew by 22%.  However, when the business case was being developed, the team was told to assume that the ‘do nothing’ scenario consisted of a 100% increase in revenue while employee headcount was held to 20%.  Would anyone like to be held to that business case?  This wasn’t so much a crystal ball prediction as it was a hallucinatory episode.

A business case is a forecast which, by its nature, is going to be imprecise. However, we need to avoid assumptions that are inconsistent with known facts.

Now onto the second part of the statement: “a business case…should be used to drive the right behavior during the implementation of that initiative”.  The line that ‘you get what you measure’ is oft repeated for a good reason; it’s fairly accurate.  If you file away the business case as soon as you get approval for the initiative, then you will get exactly what you are measuring in terms of benefits: nothing.  Benefits realization is not easy and it doesn’t happen unless someone actively manages it.  A new piece of software may provide the company with the ability to reduce manual effort for a specific process, but that doesn’t turn into financial savings unless the work is re-organized and fewer people are employed.  Someone has to make sure that happens.  Even in a less emotional context – inventory levels rather than employee numbers – someone has to ensure that order quantities or frequencies are changed, they have to change the scorecards for employees who are held responsible for inventory levels, and, most importantly, they have to take employees through the changes to these elements so they understand what is happening and why.  Only then do inventory levels decrease.  All of this is over and above the system implementation.

Realization of benefits often involves changes that impact lots of people slightly positively but a few people very negatively. This can be emotionally difficult.

System implementations are not the only culprits.  The initiative could relate to organizational redesign, post-merger integration, supply chain reconfiguration, or any number of other initiatives.  In each case, the primary focus is on a change to the business, the benefits of which can only be realized by taking actions above those prescribed by the immediate project.  This author has participated in organizational design projects where jobs and reporting lines were simplified to make the organization more efficient, and yet no-one lost their job in the process because no-one took the final step of identifying people whose roles no longer existed.  Change is difficult and it’s not made easier when people lose their source of income.

The only way to keep people focused on the reason for the change and to have any chance of realizing the projected benefits is to focus on the business case through a benefits realization effort.  This may be as simple as measuring and communicating benefits realized or it may entail dedicated resources to make additional changes to processes, policies and organizations to ensure that benefits are realized.


How then do we set up the benefits realization effort to optimize our chances of success?  It has to begin with the business case.  At the beginning of this paper, the author argued that a business case that is too high level or too low level is useless.  Think of how you would like to be given a challenge.  Would you like to be given a target of $100M in savings over the next three years, with no detail as to how these are to be achieved, or be given a massive checklist of tasks such as the need to manage the cost of a specific type of software engineer three years from now?  Most people would run away from both of these challenges.  How about being asked to reduce the number of days of finished goods inventory by 10 days through the implementation of a system and related policies and procedures that will allow the company to adhere to its stated goal of 95% availability?  In this case, the goal and the path to achieving the goal are reasonably clear, particularly if the calculations used in the business case support the goal that has been set.

It is critical that the business case is reviewed by people who understand the part of the business that it relates to.  This may seem very obvious but it is amazing how many times a spreadsheet exercise goes from a series of numerical doodles into something that is viewed as infallible, without anyone having taken the time to check the basic assumptions underlying it.  This doesn’t have to be a detailed audit of the spreadsheet.  It can take the form of a simple gut check by someone whose gut is qualified to perform said check.

There are three steps when it comes to business case logic and assumptions: 1-validate, 2-validate, and 3-validate.

With a business case developed at the right level of detail and being in the realm of the plausible, the work on realizing it can begin.  If a system implementation is involved, then let’s make sure that the functionality that we need in order to realize the benefits is actually implemented.  In one example that this author has experienced, an excessively labor intensive process was to be automated through the roll out of two separate systems.  Unfortunately, one transaction type that linked the systems wasn’t included in the scope of either system roll outs and the company was left with exactly the same labor effort as existed before.  The extra effort was small but it was the part that was critical for benefits realization.  If I was to explain this to a kid in middle school, they would give me a withering look and express a ‘duh’ kind of verbal response.  It’s that obvious and yet intelligent, experienced people miss it in the context of a large, difficult project.

Now that we know the right things are being implemented, we need to track their progress.  This entails a combination of enabling and realization metrics.  For example, you would like to know if the process changes to cash collections have been implemented and, given that the new process was expected to result in earlier collection of remittances, you would like to know if accounts receivables and write offs have decreased.  Note that the enabling metrics consist primarily of milestones (i.e. have we done it yet?) while the realization metrics are financial or operational indicators.

All of this takes time, which means that someone needs to be given the responsibility for tracking and communicating benefits.  Someone also has to be held responsible for realizing the benefits and overcoming obstacles.   This responsibility may rest with team leads or with an independent benefits realization team.  The former is preferable where the benefits are the result of work that is undertaken exclusively within that stream of work.  Where several implementation streams impact our ability to realize the benefits, an independent team makes more sense.

An individual’s performance assessment on a project should be tied to their contribution to the benefits realization and not just to milestone attainment.


Earlier in this paper, we referred to senior management’s ability to define the narrative.  People respond to stories that are simple with clear causal links.  If we develop a business case that can be realized, then we have the ability to tie the effort to the benefits.  Change is difficult and creates fear but we can make it palatable if we explain why it is being undertaken and then show that the work led directly to the benefits that we realized.  This makes it possible to keep employees motivated and engaged through the effort as well as keeping them focused on the right things.

If you would like to discuss this topic in more detail, please contact us at