What is the purpose of a business case and when would you use one?

Business cases are used in may organisations to seek approval for investment in a project. Often the business case will be approved when the benefits of proceeding with the project outweigh the costs and risks. In this Blab we address the question 'What is the purpose of a business case and when would you use one?'.

Blab topic: The importance of a strong business case for change

We recently ran a Blab session (find out more about Blab) discussing business cases in a New Zealand context, where we worked through these questions:

• What is the purpose of a business case and when would you use one? (Covered in this post)
• What makes an effective business case?
• What benefits does a strong business case provide for an IT project? (Future post)

This post covers the first question. The recorded Blab is ~15 minutes long and there is also a transcript of the discussion below.

Blab presenters

Our presenters during the Blab presentation were:

• Pink / purple shirt: Paul Ramsay, Principal Consultant, Equinox IT Wellington office
• Blue check shirt: Carl Weller , Senior Consultant, Equinox IT Wellington office
• Dark blue polo: Peter Smeaton, Senior Consultant, Equinox IT Wellington office
• Black shirt: Ray Cooke, Lean and Agile business transformation coach, Equinox IT Wellington office.

Transcript of conversation

Paul: Welcome to this particular blab. We're looking at the question of the importance of having a strong business case. And today, I'm joined by Ray Cooke, Carl Weller, and Peter Smeaton. And I'm Paul Ramsay.

So this is a series that we're going to be doing, looking at questions associated with governance and assurance. And what we wanted to do with this particular blab was to focus at that very first step in the process, where people are looking at the question of the business case. And what we're wanting to do there is explore the question of actually when do you actually require a business case. What's the purpose of that, and when should you look to use one? So I'll open that for discussion.

Ray: The point of having one at all. Well, if you don't have one. Well, I suppose a business case itself is...in terms of what we're talking about, it's the intent behind the business case rather than the piece of paper itself. The intent of having a clear understanding of whether what you're exploring is a viable business opportunity, whether it's one that's worth progressing with. So it's asking those initial questions about, if you're in the business of producing cars, do you really want to start building telephones? And so, have those questions asked and if you do decide to go into the telephone building business, then make sure you know what it is, whether you're being successful at it or not.

Paul: Yeah. I think that's a really good observation in the sense of it's almost like having a bit of a benchmark for delivery. Just in the same way we as consultants have a terms of reference or statement of work, the business case is really the rationale and the benchmark for delivery for a project. And I guess the other thing that you were touching on there, Ray, and it's alluded to in the BBC business case model that is quite widely used within the public sector, is that you're looking at those different elements of strategic fit, economic benefit, whether you can actually afford to do the project, the actual aspects of delivery, and even things like commercial viability. Perhaps people would like to comment a wee bit on some of those aspects in terms of business case development.

Carl: I think just picking up what Ray said, it's quite important not to see the business case as 100-page document, because then it's something that gets wheeled out for a big $20-30 million project. When actually any time you're trying to do anything, spending any sort of significant money -- and significant depends on your organisation -- you should be able to answer the basic questions: "What am I going to do? Why am I doing it? How does it drive my organisation forward? How will I know along the way that I am still being successful?" Because a fundamental thing of the business case is telling you when you should actually stop doing the project, as well as how the project should deliver, and what you expect. The counter fact was, "I'm not doing that anymore. Perhaps I should stop and invest my organisation's money in something else."

Ray: Especially in today's volatile markets and...yeah, volatile's perhaps the wrong word. Too financial. Very mobile environment. No, damn, that's loaded as well. The point being, in the markets we're operating in today, there's an awful lot of movement, especially in the technology sector. So having a business case, like you say, Carl, where you can recognise when actually it's no longer valid anymore. It's no longer applicable, because the environment that it was originally intended to work in is no longer true. So it's being clear about what those boundaries are, I guess, that define that.

Peter: Yeah. I'd just like to touch on the difference between a government and private companies, for-profits. That has a huge effect on, to some degree, the ease and the shape of the business case. For a for-profit situation, the business case has a pretty well...greatly simplified by a very simple test and that is: is this the best use of the company's money? Whether money is cash in the bank or it's going to be borrowed or whatever, it comes down to a fairly simple return on assets.

Ray: Return on investment.

Peter: Rate of return. Return on investment, that's it. With government, it's often very, very different from that. And while there are some government projects and business cases that are very clearly based around a return on investment, there are many, I would say almost a majority, that aren't. And the compelling need, the reason for being tends to take quite a different shape.

Paul: Yeah, I was just going to say, it raises a question doesn't it? About the different kinds of projects that you might be doing. Even public and private aside, the different characteristics of some projects may also be a factor as well. So there might be a service delivery project that has a very clear cost benefit analysis, return on investment. And then there may be other projects, the infrastructural projects, the pipes and wires, the supporting systems that probably have quite a different business case. Any particular observations around that?

Ray: I'd say, well, yeah, just to add to that as well especially in the public environment, those ones that are purely there for legislative reasons or for political reasons. So there's a lot of intangible benefits that it's very difficult to stick a dollar value on.

So I guess they still fall under your return on investment, Peter, but I guess they're harder to measure. They're obviously still a return, they're just not assets. You could guess that are...there's a $20 million benefit in rolling out a portal to the public that makes life easier for people to fill in their tax returns or whatever. It's very difficult to assess what the actual value to a person would be.

Peter: Yeah, agreed, Ray. Maybe, I think similarly as Paul mentioned, infrastructure, plumbing type projects or business cases are similarly hard to get a tab on. Because the benefits are realised over an extended period of time, and, if you like, diluted across a large audience.

Paul: I guess that also raises the other thing about business cases. Is that in many situations, it's actually about predicting the future and about what is known at a given point in time. How have you seen that addressed, and what sort of issues do you see associated with that in preparing a business case, for example?

Carl: I think the fundamental thing is appreciating where you are in the lifecycle of your project or your product and expecting plus or minus 5% from a business case when you haven't really even got a delivery team on board who've started to look at problems; it's just not going to happen. It's about understanding that earlier on and there's a model that some of us agree with or disagree with, the Cone of Uncertainty. You're right at the start of that cone, and there's going to be just a big span of uncertainty that all your estimates are based on.

Paul: And I think that's a really good observation as you say, because there is that relative uncertainty depending on where you are in the process. And I guess one of the other risks that goes with the business case as well too is that -- I use the phrase "a figure becomes a fact" -- and as soon as you mention a number, it becomes, as we talked about before, that benchmark for delivery.

And when you're talking about aspects of uncertainty as Carl mentioned before, you obviously need to be able to cater for a range. So that lends itself more to questions of probability and likelihood. So not having a fixed reference, but potentially things like Monte Carlo and other forms of simulation of probability, for example.

So what about those aspects of projects?

Ray: All of those come back to...it comes back to your previous point, Paul, about the fact is you're trying to predict the future. So to do that, to have any confidence in your ability to do so, you've got to have a model that you've put together that represents the market that you're delivering into. So in some respects, that's more understood in the financial sector, even if the odds aren't that much better. But in the public sector, having a model that if the intent is to affect public perception, for example, then coming up with a model that might be able to predict people's responses to your change that's effected by that business case.

But then it all comes back to if you want to be able to predict the future, frankly nobody's very good at predicting the future. So unless you have the feedback loops in place to know whether you're doing a good job of it or not as you go along with the swirl of feedback loops, the better, you're just building up your risk.

So that's not to say that you couldn't address that at the business case level, but then it's looking at, "So this is my guess for the future," and then having those measures that we were talking about earlier, to be able to say, "Okay, great. So as soon as we possibly can, I need to know whether my assumptions that I've built this business case around are valid or not." So be able to test that public perception, being able to test that, "I'm getting the return on investment that I'm expecting." Be able to test any of those measures that...those benefits that you're expecting for your business case are actually being produced. Which means having one that's five years down the line, doesn't really help. You kind of need one a lot earlier than that.

Peter: This leads to interesting directions in terms of carving potential single large business cases into more manageable portions and more time bound portions, Ray. This also helps address one of the things that I was going to mention, which is about prediction of the future. My observation is that a lot of business cases, especially somewhat larger business cases, get somewhat disconnected. They create a little internal bubble of belief and so on and get carried away, and really do get quite disconnected from an exterior or an external perception of how things have changed and the future.

Ray: It's very easy to get caught up in that delivery cycle.

Peter: Absolutely, and so some process - whether it's a governance process around the business case development, or as you say, chunking business cases into smaller business case then delivery or, I don't know, collision with reality, etc. Chunking. Chunking. And iteration. Those things can help to avoid that disappearing down the rabbit hole.

Ray: Yeah, just to take your little chunking analogy a little further, effectively we're talking about an extension of business strategy and vision. You've got various levels of abstraction and your business case is just a realisation of a very small part of that strategy or that vision you're trying to achieve as a business. So just taking that, how low you take that level down to...well, the lower you can take it down, the better for you to be able to measure your ability to deliver on that strategy and that view.

Paul: So I guess there's a couple of observations there as we wrap up this particular question. Is obviously catering for a number of different factors, catering for uncertainty, looking at incremental or chunked development -- not only of the project or deliverable itself, but potentially of the business case. And I guess that's one of the other things in that BBC model is the incremental development of the business case through to a fully formed and well-developed case.

So you may do a provisional business case, where you just look at the questions of strategic fit and alignment, and then move through to the actual practicalities of delivery. And that's also where you have that ability to break down a project into more realistic aspects.

I guess the other thing that was in that mix as well too that you alluded to in some of those responses, was around change and the rate of change within organisations. And trying to predict and deliver and contain a project in an environment that's potentially subject to quite significant change. So my little maxim is if it's over a year and it costs more than a million dollars, you can probably halve the chances of success. It's not to say that it isn't successful, but it makes that project that much more of a challenge and you need to have the processes and procedures around that to manage that delivery.

Any other concluding comments, anything that you'd like to add, Carl, just around that aspect of the need for the business case and when you'd use one?

Carl: I think if you...you've got to contextualise this stuff. And if you think about a lot of organisations, the pace of change is increasing, we all see that. But particularly in government, you're seeing more control being applied, more longer-term planning. Your agencies are now doing four-year planning. That doesn't really facilitate the nimbleness that we're talking about, where you may have an investment pool of money that is for small initiatives that...this chunking that we're talking about, that's got to be funded somehow. And there's always a challenge for organisations when they've got business unit-based budgets and quite often that's just an incremental of what you had last year plus or minus x. 

Ray: So the question there is whether you're funding on a business case for a business case basis, or whether you've got a pool, as you say, that you're then allocating out of two business cases that are current.

Carl: Yeah, I mean the way that the whole system is set up is for large initiatives with your stage one and stage two business case. That's effectively a new pot of money that comes into an organisation. And it's quite challenging for the organisation itself to find small amounts of money to fund small initiatives that could lead to really big change.

We'll be doing more Blab-based content in the future covering other common Agile and IT questions. Please let us know if you have any IT questions that you would like us to address.