When is a business case not a business case?

Read part one   part two Read part three  Read part four

1. When it establishes that there is no case for the proposed initiative.
2. When it fails to identify and present the benefits of the proposal sufficiently well to win support.
   Both of these situations have the same result only the second one is a lost opportunity for the business.

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concepts of benefits were rarely discussed ten years ago, let alone benefits realisation.  Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university  Benefits Dependency Network Tool  and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non-detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political, economical, sociological and technical trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project.
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements.   In doing this, it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract from them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do-nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one   part two Read part three  Read part four

Related articles by Zemanta

• Tim Worstall: We need a proper cost benefit analysis of recycling: is it worth it?
• Brand shrinkage: a real business cost of not understanding social media