Why do you need to write a business case anyway?

I’ve never seen a project submitted for approval that had a negative rate of return.  I’ve never seen a business case before an exec board that generated a negative return.  I’m sure they do exist deep down in the bowels of a strategy department but by the time a business case gets to the top it will have been pruned, preened and buffed and polished to a gleaming shiny optimism.  Forgive my cynicism for a second but I’m not completely sure that these business cases are always strictly accurate.  Not through any intent to deceive necessarily but sometimes in the heat of the moment the desire to overinflate the all powerful impact of our new shiny technology (CRM, app, website etc.) we get ahead of ourselves. It’s human nature.  You are competing with a whole bunch of other brilliant ideas for a finite allocation of dollars to your initiative. Moreover business cases associated with customer impacting change suffer from the weakness of uncertainty.  We can’t really be sure that the change we’re proposing is really going to have a positive impact on the bottom line.  Customers are unpredictable are they not?  So in order to succeed not only do our ideas need to compel for customers they need to compel internally.  Our business idea  (business cases are so 2010) needs to be able to do at least three things:

  1. [stextbox id=”info”]It needs to convince people that not only is your  customer impacting change programme a good idea; but more importantly that it is a good idea that needs to be done NOW (so it kinda makes sense to have a WHY NOW? section in your document)[/stextbox]
  2. [stextbox id=”info”]It needs to be built upon a compelling VISION that people in the business can own themselves and get on board with[/stextbox]
  3. [stextbox id=”info”]It needs to be your anchor point throughout your programme.  The single touchstone that explains why you are doing what you are doing.  It means that your business case will become a parent of many presentations and documents that will find their way across your business.  These components represent WHAT your executive signed off and therefore represent the be all and end all of your programme[/stextbox]

Agile or agile?

So where does Agile fit in to all of this?  Well one concept of Agile or agile is that you don’t have projects; you have a flow of value delivering changes that are adaptive, responsive and quick (delivered at pace rather than in a short amount of time).  That delivery of a vision may not always be done in the way you originally committed to.  Now from here on in I’m going to remove the capital A from my use of the word agile.  I’m not basing this article on the Agile manifesto but on the techniques and methods that support an agile methodology.  And from this point forth we’ll work with a concrete business idea; that of moving a whole bunch of customer transactions from a high cost channel to a perceived lower cost channel (a contact centre to an app for example).  Here are the three points above put simply and succintly.

[stextbox id=”info”]

  1. Our competition is moving fast to enable digital transactions for their customers.  Our customers are digital natives.  They expect to do business when and where they please
  2. By 2020 we will have moved 80% of our transactions to mobile, device independent apps delivering an xx% reduction in cost to serve
  3. If we don’t go digital this line of business will die

[/stextbox]

Now all you need to do is write a business case is to set how how your proposed programme will satisfy or help achieve specific set of business objectives and vision above.  The beauty of the set of statements above is that it’s a greenfield proposition.  Not everyone has that luxury; in many cases we’re replacing an old thing with a new thing.  This can make the business case easier but it doesn’t make phased delivery simple.

Critical customer change business case elements (or agenda)

Elaborate on the first point by developing a compelling story of why you need to do (the numbers will come later) whatever it is you are proposing to do.  This is the threat, the opportunity presented where doing nothing is not an option.   Make sure that waiting is not an option either.  Investment boards or other governance boards happen periodically.  There’s a limbo world where an idea is never rejected but then again it’s never accepted either.  So your story needs a bit of jeopardy… time is running out.  Competitor case studies, Gartner papers etc. all add grist to the mill.

[stextbox id=”black”]Make your story people based – illustrate your case with “day in the life” cameos of how the world of tomorrow will be so much better.  Engage all of your internal stakeholders to test and gauge the stories you are gathering.  Gather these stories from a wide group of stakeholders.  Make sure they are the ones that provide the flavour and depth.  Seek constant feedback and review[/stextbox]

Establish robust causality.  Simply saying that your shiny new CRM system or app or website will help improve revenue or sales ratios is (IMHO) simply not good enough.  Put some effort into explaining (perhaps in your cameos) how, because things are faster, cheaper, better etc people will be able to deliver more business benefits or how you are going to make money.  Look, for example, at transactional behaviours from your customers that support the use cases you are developing.  If they don’t then come up with use cases that do.  We want to be delivering business benefits here not building white elephants.  If you are the one that’s going to be delivering the change then you really should know how it’s going to be done.  Your business case is your blueprint or roadmap for doing so.

Possible CRM business case structure (leveraging the pyramid method)

  1. Business challenge/opportunity – the description of why the world is changing and why it presents such a threat or opportunity (see above)
  2. Solution to the challenge or proposal
  3. Overview of benefits of the proposal that are aimed at your target stakeholders
  4. Why now?
  5. How will we develop and deploy – the methods and approaches that will derisk the investment and ensure a positive delivery
  6. What will success look like? – ensure you know how you’ll measure benefit.  Carry out some initial baselining before you change a thing so you have a robust comparison starting point
  7. Making it successful & critical success factors
  8. Costings
  9. Alternatives and why they don’t meet the challenge – really think about these.  There are many ways of solving a business challenge.  Honest assessment of alternative options no matter how outlandish will actually strengthen your case.  It will show that you’ve looked at alternatives and evaluated these as a way of delivering your business outcome (lower cost to serve in our case).
  10. Critical risk areas and how they will be managed

Make the barriers to entry and exit as low as possible – create your MVP

So in a greenfield situation where you are simply building a new thing you can take advantage of the concept of MVP (minimum viable product).  MVP is a concept from lean start ups where you only do what is required to get going and understand what your customers really do want.  By setting and defining an MVP you lower the buy in cost for your business case.  This buy in cost also represents the exit price for your investment board should priorities change or your original idea is clearly not going to fly.  Where your change is brownfield (replacing an old thing with a new shiny thing) your exit and entry costs are much higher but the price of inaction should be much clearer cut.  Increased support costs, loss of functionality and easy to understand and quantify. Offering a phased deployment on platform swap out is harder as you’ll work hard to convince people that your MVP is less than the functionality you already have.  One way of doing this is to have parallel operations of old and new where a pilot group is prepared to accept less earlier on in exchange for more benefits further down the line.  The point at which development equals current functionality is the point at which you widen out your pilot.  In our example of an app the MVP may be a very rough and ready transaction that is then enhanced and developed over time.

Selling your case

By the time a business case gets to the executive you should know that it will be signed off.  If you don’t know what the decision is going to be you won’t have done your homework.  Ensure that you have reached out to a wide range of stakeholders for your prospective program to ensure that the corridor noise is aligned and “on message” with what you are trying to achieve.  Try and pick out a few slides or points that convey what you want to do, why you want to do it and what it will take to achieve.  Rinse and repeat.