As I become more senior I have more of a need to write business cases. I turned to the excellent Peter Grzeszczak for advice, and this is what he said.
Instead of opening with the solution you are proposing, start by defining the problem you are trying to solve. This is really useful to clarify your own thoughts on the matter.
Make the strategic point – why is this a problem that we want to solve? What is the outcome we are trying to get to and how does that support the organisation’s stated aims? In our case, why is this something government should care about?
The reason you are writing this is probably to make a case for doing something that you already think is a good idea. It’s a good exercise to think about some other ways you could achieve the same outcomes. You might realise there is a better way to approach the problem. If nothing else, it demonstrates to the people the business case is aimed at that you have properly considered other options.
What is the cost of doing nothing? Are there any benefits to taking no action? Again, this is very useful for clarifying your own thoughts, as we tend to have a bias towards taking action.
Often the benefits will be “soft” benefits, i.e. intangible, or things it is hard to quantify. For example, something might be good for recruitment, or it might lead to a better alignment with government policy.
If you can give actual or estimated costs for things that’s even better. For example, how much does a developer on average cost and how long would this piece of work need them for? Tangible benefits are also good.
Case studies can be quantitative or qualitative. The former is where you outline how a similar solution to the one you are proposing saved £X and is therefore evidence for your suggestion that your proposal will save £X. The latter is an example where you can’t offer hard figures, and is where you are recognising that your solution may be a leap of faith but your case study shows why you believe it’s a punt worth making.
The former is better, but the latter can strengthen your case if used judiciously.
Make sure you’ve considered what potential extra costs there could be, and how you would make sure they are addressed.
If you’ve made a good case so far, then it should be obvious at this point what your solution is. You’ve considered other options, including doing nothing, you’ve weighed up the costs, benefits and risks, and this is the case for your desired solution.
If they approve this case, how would you manage it as a project? Do you already have an idea of the group of people you would get together to work on it? If so, include these details.
You should also cover measurement. When you evaluate this piece of work at the end, how will you know it’s been successful?
Make it easy for those reading the business case to see that if approved, you would be able to deliver this successfully.
Part of the point of making a business case is sharing the information. It shouldn’t come out of the blue for anyone who will be involved in making the decision or supporting the work.
As a rough rule of thumb, for a business case for a significant piece of work Peter suggested you would probably be looking at around a month: you might spend a week or so on discovery, making sure you’re clear on the problem (maybe having a workshop) and working out who will be the sponsor; once you’ve got the options you’ll probably spend another week or two getting the data to support those options, and then a week or two to write it up.
Be loud and open as you go; you want input from people who have something to add, and you want people to know it’s happening.
Good people to ask for feedback are the people who you will need to support it, for example the people in charge of business operations and the senior sponsor. Talk to people to see how they think the case will be received, and whether the information is presented in the way people will want to see it.
It’s also worth (as with most things) finding a critical friend who is not involved to read through it.
We were not talking about producing a business case for the Treasury, though that’s a lot of what Peter does. Although that is a much more involved exercise, I found it useful to think of the different cases you are required to make for Treasury cases: strategic, economic, commercial, financial and management. It can be useful to think of your problem in those lights, even if you don’t go into all the detail. This guide on assessing Treasury business cases is useful for more information on that.
Your business case should be a narrative. Here’s the problem. Here’s a good solution. It might cost us money, but here are the reasons that it’s the right thing to do.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: