(Insights — Transformation)
Why the business case is the easy part
Insights — Transformation · 7 min read · Rebecca Barwood
Building a business case is craft work, and most of us in this sector are good at it. Bringing ideas together, articulating them, selling the outcome to a board or a Minister is bread and butter. The part that decides whether any of it happens is the management case, and it is routinely written by people who have never had to deliver one.
I have never seen a business case fail.
I have seen plenty of programmes fail, and almost every one of them had an approved business case sitting behind it. Signed off, well argued, properly benchmarked, with a benefits realisation plan and a clean set of options. The failure did not happen at the approval gate. It happened eighteen months later, when the thing that had been described on paper met procurement timeframes, governance appetite, market capacity and the ordinary friction of getting anything done across multiple agencies.
I feel we have quietly agreed, as a sector, to treat approval as the finish line. It is not. It is the moment the actual difficulty begins, and the business case is where we either equip ourselves for that difficulty or set ourselves up to be surprised by it.
Three questions, three business cases
The New Zealand model gives us a sensible ladder. Indicative, detailed, implementation. Each one is really just a different question.
The indicative business case asks: do we agree with the idea? That is all. Is there a problem worth solving, is there a plausible case for change, is this the sort of thing the Crown should be doing. It is a conversation about direction.
The detailed business case asks: how might we get there? Options, analysis, trade offs, a preferred way forward. Still exploratory. Still, in an important sense, theoretical.
The implementation business case asks something entirely different: this is how we are going to do it. Not how we might. How we will. Who, by when, at what cost, under whose governance, procured which way, with what happening in the first ninety days.
The three questions ask for three different kinds of expertise, and this is where I see programmes come unstuck. The same group of people, with the same skill set, carries the document all the way up the ladder. They are usually excellent at the first question. They are often good at the second. And then they answer the third question in the same register, because it is the register they know.
That is how you end up with a delivery plan that reads beautifully and cannot survive contact with a procurement calendar.
Four things I would insist on
01
Put delivery people in the room at the indicative stage
The instinct is to bring delivery expertise in late, once the shape of the thing is settled, because that is when it becomes relevant. I would reverse it entirely.
Someone who has run this kind of programme before does not just improve the management case. They change what gets proposed in the first place. They will look at an option and say, quietly, that the sequencing does not work, or that there are four organisations in the country who can do that piece of work and two of them are booked out. That is not detail. That is strategy, arriving early enough to be useful.
Bring them in at the implementation stage and all they can do is cost what has already been decided. You have paid for their expertise and used almost none of it.
02
Write the management case as though somebody has to do it
The five cases are not equal in practice. Strategic, economic, commercial and financial get the analytical firepower, the peer review and the redrafting. The management case gets written last, by whoever has capacity, often against a template.
Yet the management case is the only one that describes what will actually happen. It carries the delivery approach, the timeline, the governance, the resourcing, the risk. Everything else is argument. This is the plan.
The test I would apply is simple. Give the management case to someone who will have to deliver it and has no stake in the approval. Ask them what they would need to know on their first Monday. If the answer involves a lot of assumptions that are not written down anywhere, the case is not finished, however polished the rest of it looks.
03
Name what will trip it up, in writing
Every experienced delivery person walks into a programme with a mental list of what will go wrong. Dependencies on another agency's timeline. A single specialist role that is hard to fill. A consenting pathway with no slack in it. A vendor market that is thinner than the strategy assumes.
Very little of that list makes it into the document. Partly because risk registers reward the generic over the specific, and partly because there is a real, unspoken pressure not to give the approver a reason to say no.
I would put it in anyway, in plain terms, with what you intend to do about it. Approvers are not naive. A case that names three hard problems and shows how they will be managed reads as competent. A case with no visible difficulty reads as either optimistic or unexamined, and the people around those tables have seen enough to tell the difference.
04
Make governance a delivery instrument, not a reporting one
Governance in business cases is usually described in structural terms. A board, a steering group, a set of reporting lines, a monthly cadence. All correct and none of it useful.
The question worth answering is who can make a decision, how quickly, and what happens when the answer needs to come faster than the meeting cycle allows. Delivery is a sequence of decisions. If your governance design cannot produce them at the rate the programme needs, the programme will slow to the speed of your calendar, and every status report will describe the symptom without naming the cause.
I would design governance around the decisions the delivery plan will demand, and I would work out that list before drawing the boxes.
What this means beyond business cases
None of this is an argument against the business case. The craft is genuinely valuable. Synthesising a messy problem into a clear case for change, testing options honestly, building a story that a board or a Minister can back with confidence, is real work and it deserves to be done well.
It is just that we have got the difficulty rating backwards. We treat the persuasion as the hard part and the delivery plan as the administrative tail. In my experience it is the other way round, and the cost of that mistake is not paid at the approval gate. It is paid slowly, over years, by the people holding a commitment that was never achievable.
The version I would like to see is a sector where implementation expertise is present from the first conversation rather than summoned at the end. Where the management case is the most scrutinised section rather than the last one written. Where we judge a business case not by how compelling it is, but by whether the people who have to deliver it recognise their own work in it.
A business case that gets approved is a good day.
A business case that gets delivered is the entire point.
Rebecca Barwood has authored and delivered business cases across central and local government, including the implementation business case for cross agency property centralisation at MBIE. She works with public and private sector organisations on delivery, procurement and digital transformation.
More from Rebecca →