Do We Need A Business Case?
A few years back, when I was working for a large US multinational in the IT industry, the owner of the Product that I was project managing would create a Business Case after I had created my Project Plan (so they could ‘plug-in’ the project timescale and cost).
The culture was that you needed a Business Case to get through the funding loop, and start the project. Once that was done, the Business Case was ‘reviewed’ (but only to satisfy audit requirements). What took over and dominated the project was the Sales and Marketing Plan. This drove everything.
As long as you ‘got your numbers’ folks got their bonuses.
Looking back, I agree that ‘the numbers’ should have reflected back on the Business Case – so there was a relationship – but the emphasis and culture was off-course in my opinion.
I have been on many projects since that were just a ‘wish list’ from a senior manager, and I had the job to deliver the project. Success or otherwise was measured on delivering on time, on budget, and getting customer acceptance. Time and Budget seemed to be set by a senior manager’s opinion or demand.
Now, I don’t know what Industry and Corporation you work for, and the style, content, and investment techniques will be different for everyone, so I will use general language to describe what follows.
You see, it’s the business benefits that are the heart-beat of every project undertaking. And these are to be found in any Business Case. What we do as individuals in our daily lives is dictated by our own ‘internal business case’, where we balance the risks and costs of doing anything verses the benefits of doing so. After all, without our ‘business case’ how could we make decisions and take actions of our daily life?
Welcome to Project Business Management
Let’s suppose your catering manager is considering installing ‘cashless cards’ for staff to buy their restaurant meals. What might the benefits be?
Well, faster payment and quicker meals for employees for a start. Then maybe, less checkout staff and lower wage bills. Perhaps shorter lunch breaks giving rise to greater productivity?
All these benefits need to be ‘costed’ meaning what is the ‘dollar-value’ to be gained for each. This would then be weighed against the cost of installing and running the machines and cards. Broadly, benefits come in two flavours: Tangible benefits and Intangible benefits.
Tangible benefits are those that can be measured directly (financially or otherwise). Examples might be; time to market, reduced labor costs, or higher market share.
Intangible benefits are those that can only be measured indirectly. Examples might be; brand perception or improved staff morale.
Intangible benefits are often measured by questionnaires, and scoring systems are used to interpret the results. Another technique is to look at benefit consequence – and measure the consequence. For example improved staff morale might lead to lower staff turnover.
Some benefits might be stated as a ‘less negative’ type of benefit. For example “if this project is not done, we will be fined $1M” So doing the project will save $1M minus the project budget.
Now imagine that the catering manager had only said “I think it would be a great idea if we installed cashless cards – I hear lots of organisations are using them now – it’s the modern way to provide our catering services” And you are the lucky project manager…
Suppose the installation and set-up costs increased by 25%, and running costs look higher than first thought. Should we go ahead or what? How much is too much, how long is too long? It may be that the project budget can be easily found – but what about cost of ownership – whole life costs (I can get a bank loan to buy a Lexus – but maintenance and spares – running costs – are cheaper for a Ford).
Some organisations are created to provide services and are non-profit by nature. Can a Business Case add any value? Dead Right they can! How else can investment be tested to ensure it is providing value-for-money?
It’s all about professisonal project business management. So what information should be in a Business Case – here is a typical list of contents:
- Reasons. This should state clearly WHY the project is being done. And these should be BUSINESS reasons – possibly tying in with organisational strategies.
- Options.All options that have been considered should be included, including the ‘Do Nothing’ option as a base for the other options. The chosen option should be stated along with the reasons why.
- Benefits. As stated earlier, include all tangible and intangible benefit descriptions. Each benefit MUST have a clear statement of what measurements will be used to show it has been realised.
- Risks. This will be a summary of all known risks. A good idea is to summarize them in terms of their category, for example, political, environmental, technical, etc.
- Cost and Timescale. This information is drawn mainly from the Project Plan. The next section will contain similar data during the operational life of the end-product.
- Investment Appraisal. This is the section where your organisation will use whatever financial modelling technique is preferred. It may be Return On Investment (ROI), Cost/Benefit Analysis (CBA), or some other metrics.
The important thing here, is to get the ‘whole-life-picture’ so that the Business Case explicitly shows and proves that the project is viable, desirable, and achievable.
- Evaluation. This is a conclusion of the Investment Appraisal and Benefits. Sensitivity Analysis is a technique that is used to see whether the Business Case ‘stacks up’ should staff costs increase or the market competition increases, and so forth.
Another technique is GAP analysis (Good, Average, And Poor). This re-drafts the Investment Appraisal for three situations – Best Case, Most Likely Case, and Worst Case. Management then makes a decision whether the project should start or not.
The Business Case is reviewed at the start of the project, and if approved – along with the Project Plan, then the project goes ahead. But the Business Case should be reviewed on a regular basis, because situations change, and what was a good idea at the start may not be viable part way through the project.
As a minimum, the Business Case should be reviewed (or at least checked)at the following points:
- Whenever new risks arise, or existing risks change
- Whenever a change is proposed, or an issue is raised
- At the end of each stage of the project
- At appropriate milestone points
- At project closure
At the close of the project, the Business Case and its potential benefits are handed over to those with operational responsibilities – often the business area manager where the benefits will be felt. As part of closure a Benefit Realisation Plan should be created showing how and when the path to benefit realisation will be managed, tracked, and controlled.
The project manager is not responsible for the Business Case, although they may manage it on behalf of the sponsor or business owner. As an absolute minimum, a Business Case should contain the reasons why the project is being undertaken, and the expected benefits.
The Business Case should be understood by all parties, including the design team – a more business-optimised design will result.