The quality of the average business case sucks. I’ve had a number of project and programme assurance roles and run some large portfolio management offices so I have reviewed quite a few business cases over the years. And the majority I’ve seen don’t cut the mustard.
Here are just a few of the common issues I have encountered:
- No explanation of strategic fit – all projects/programmes should support the strategic objectives of the business. If this ‘fit’ is not explained in the business case, then it probably isn’t there.
- Unrealistic benefits – benefits that have little or no objective basis for calculating them.
- Just enough benefits – just enough to justify the costs. Easy to spot if you track a business case through development. As the costs go up, so too, miraculously, do the benefits!
- Insufficient or no benefits – why would you even put forward a discretionary change business case without any benefits? Even business enabling projects – ones that you need to do to enable other projects to deliver benefits – at least have the enabling as a benefit. Quantify what is being enabled.
- Missing costs – business cases often exclude the costs of the business people involved. This is ok if it is a relatively small proportion of their time, but if it is not, there is an opportunity cost to the organisation. Also, projects often have knock-on effects which don’t get included in the business case such as health & safety changes, business continuity changes etc.
- No benefits tracking – the business case fails to explain how delivery of the benefits can be tracked or proven.
- Lack of Alternative solutions – the business case fails to articulate the alternatives that were considered, or dismisses them without a clear explanation.
- No explanation of the risks to delivery or the associated benefits
Fear and expectation
The problems begin with fear and expectation. There is a fear that once the business case is approved you will be held responsible – to the penny. That leads to the expectation that you must get as much work done as possible to validate and verify your numbers before the business case is submitted for approval. The result is a long drawn out process resulting in hedged and caveated numbers that offer little real value to the business.
Start with the end in mind
A business case should be written, like a plan, with the end in mind. Start with the end outcome and break it down. You’ll get a much better sense of the scale, scope and timeframes.
For a multi-year, multi-million pound programme you cannot hope to accurately estimate the full costs and timescales at the outset. That needs to be accepted by the organisation and should be factored into the business case approval process. Hard estimates +/- 5% for the next phase, with the tolerances increasing the further out you go. Checkpoints are scheduled and the business case revisited to assess performance and re-validate future phases.
If the remainder of the programme doesn’t stack up, either because of the things that have come to light through earlier phases, or because the market has changed, then the programme can be stopped and ni further money wasted. That’s still a success in my book – especially when so many programmes stumble on to under-deliver or fail further down the line.
What issues have you encountered with your business cases