What’s wrong with business cases

Dave Rogers’ tweet was spot on, and found a better way of saying what I’ve felt for a long time: business cases are not a good way to make decisions. They give us false certainty and almost invariably mislead some or all of an organisation’s leadership.

Business cases are lies. Not wilful lies usually, but they end up with the same results: misleading, misinforming and hiding reality.

Why would I feel so strongly about what is a pretty standard part of modern organisational life? Because I think it’s symptomatic of the challenge we face in moving to Internet-age public services. It’s easy for folk to nod along with the importance of ‘being digital and agile’ but then insisting on a ‘layer of programme management and finance oversight’ you know, “just to make sure it delivers”. This kills the good stuff and pulls us back to the wrong, lumpy ways of doing things.

Take a business case for a software implementation project. Probably what will have happened was requirements were collected, some market engagement done with potential suppliers and then estimation on what the work requires in terms of time and people. A return on investment will have been calculated to justify the costs involved. If everything looks reasonable, leaders will read through it, perhaps asking for some contingency funds or reassurance from managers. Then the document gets approved and people run off to do stuff. Almost certainly work doesn’t proceed as expected: Requirements change, a supplier experiences delays, costs rise.

If costs are within the total envelope no leaders are bothered with this. Programme managers juggle the finances internally. If spend goes above the envelope, then a scary moment as permission is sought to spend more. But usually we experience a few questions and the green light to carry on from our leaders. How so? Because the hole has already been dug, we need to finish it, the costs have been sunk. Let’s press on.

The ability to observe, orient, decide and act continuously is not the norm when business cases live among us. Let’s unpack our example:

1. The Requirements – The idea that we can capture all our requirements and then share them with suppliers to get answers is fantastical, and wrong. Usually the requirements are widely varying in detail and realism, furthermore they utterly fail to recognise that customising commercial software is poison. For years big vendors thought charging for customisations was a profitable wheeze for clients stupid enough to request this. But even they realised this was money they didn’t like as the cost of maintaining all these forked and patched version of their products was just too painful to bear. Customising commercial software almost never ever makes sense. Even more importantly the requirements tend to be a deeply imperfect snapshot at a moment in time. By the time any code is likely to be in use the world will have moved on.
   
2. The Cost – Software should not be a capital expenditure. It is a continuously changing, living thing that needs constant care and maintenance. The idea that a fixed price can “get us there” is fundamentally wrong. It takes us away from the power of funding teams, not projects. Business case methods massively favour capital expenditure, one-off type thinking. Yet for the complexity public servants are normally grappling with this is rarely the right approach. We need long term, patient funding for the wicked issues we seek to tackle. And also of course cost estimates for such business cases then to be wildly wrong.
   
3. The Time – Building a bridge or a school? Then a fixed timeline (with padding for slippage) makes sense. Trying to change complex systems issues like integrating health and social care? Then a fixed time business case is the wrong tool for the job.

I understand that the ‘certainty’ and ‘process’ surrounding business cases can be comforting for colleagues. But we’re fooling ourselves, we need to be courageous and hold the uncertainty as we explore the problems we face in open, collaborative ways.

Shifting away from business case culture takes time and effort – it’s a big cultural shift, as well as one that will take away a prized method some will have spent their careers on mastering. But shift this we must, otherwise we will look back in 2030 and see more wreckage of failed programmes led astray by false certainty and sunk hole mentalities. We can do this.