What makes an effective business case?

When an organisation is making an investment decision for a project, they want confidence that the investment will deliver the benefits they are seeking. A business case sets out important information to help decision makers make the right investment decision for projects. However, the decision is only as good as the information that the business case provides. A better business case will lead to a better investment decision. To help your organisation deliver better business cases, in this Blab we discuss the question 'What makes an effective business case?'.

Blab topic: What makes an effective business case

We recently ran a Blab session (find out more about Blab) discussing what makes an effective business case 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? 
• What makes an effective business case? (covered in this post)
• What benefits does a strong business case provide for an IT project? (future post)

This post covers the second question. The recorded Blab is ~13 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: That leads us in probably quite nicely into our next question, which is around the question of what makes an effective business case. And Peter, you had some interesting observations around that, in terms of what is an effective business case? What's a really good business case? What should I be looking for?

Peter: Well, I think a good business case is something that addresses a definite need or definite needs. Not nice-to-haves or whims or the latest...I'm trying to think of a nice way of putting it.

Ray: Shiny objects

Peter: Thought from somebody in the executive team or whatever. But actually, it has got solid benefits that are able to be contested and put to the test and stand up. So that's compelling. That's the most important single thing for me around the business case, is that it's actually about doing something that delivers value to the organisation.

Paul: Yeah. And I guess that raises a really important question in terms of, when we're talking about delivery of value, what do we actually mean by that? Because we have tangible and intangible.

Peter: Absolutely.

Paul: Financial and non-financial. What does that mean and what should we be looking for in that effective business case?

Ray: So on those; I'd add to those measures, that yes, they need to be measured...I mean in effect, we're talking about SMART objectives aren't we? They've got to be...I know, I've got to be the acronym there.

Paul: It's something measurable or time-bound...

Ray: Yeah, exactly. So fundamentally it's...but more than that, I don't think SMART's enough in this context. Because time-bound could still be five years after delivery, so I think it's time-bound on a very small basis and actually measurable intra-deliverable. "So, yes, we're half way through delivery. Has what we've delivered so far provided us the benefit that we're expecting? Should we continue to deliver on this project actually, or should we stop right now and move on?"

So unless we can answer those questions off the back of the measures that we dictate in the business case, I'd say we've not got an effective enough business case to warrant starting the piece of work that we're talking about. Beyond that it's...so for the measures it's just one part of it. You've still got to know what it is that you're trying to achieve. I'm not saying that it should in any way dictate a solution, but to be able to clearly articulate the value the we're expecting to achieve out of the business case once it's realised in some way. And that could be on the vision statement frankly, but something that says, "This is what we're trying to achieve. This is the financial (or otherwise) investment that we're putting into it and as a result, we're expecting these benefits off the back of it and to be able to measure the progress of those benefits during our relatively short-term delivery."

Carl: I think just picking up on what both Ray and Peter have said, Peter mentioned that it stands up. Effectively, I think the more contestable your process is for business cases, the better your business case is going to be if it's genuinely seen as an organisation that can choose a number of options to invest some money. And this is at the time what they see as the best one. You're going to get a better result. And the document shouldn't though just be about...it's not a sales document to get the money and then you throw it away, it's a touchstone for the rest of what you're doing. From the business case, you'll continue to see if that investment of funds is still the best investment choice for your organisation.

You'll be able to guide the people in delivery if you have...picking up on Ray's point; you have to have a traceability. And there's a number of models. There's Impact Mapping, there's Investment Logic Mapping, all things that basically track you from your project outputs through to your outcomes and capabilities that the organisation now has, and eventually to the delivery of benefits.

So if you don't have that, if you don't have that road map of, "When I produced this thing and it looks like this, then I know that I'm on the way to success for my business case." Your project's probably won't be able to make the right choices.

Paul: I was just going to say I guess you raise a couple of interesting aspects there. One is looking at that whole question of whole of life, and quite often, as Ray alluded to before, some of the benefits are not realised until 6, 12, 18 months after, for example, a system goes in. And so, when you're doing the business case looking at that whole of life question, another little maxim that I have is that there's always a price to be paid, it's just when you pay it. And so short-term business cases that just simply look at the upfront cost but don't take into account the operational impact and operational cost post-operation, or post-implementation rather, can be really quite significant.

So it leads to that aspect of, as you sort of said, clearly identifying what the benefits are that you're looking to achieve: both financial and non-financial. Recognising that the business case sets out those benefits that you expect to achieve. Ideally, that's best done when you can triangulate those benefits, so it's not just somebody sitting in a room and coming up with a series of ideas. You've actually gone out, tested them, refined the benefits that you're claiming in the business case, triangulated them where you can. The project is about delivering those benefits, but once the system is in operation, that's where the benefits are actually realised.

So I guess that also leads into that question of benefits management and realisation, which is something we've touched on. And again, that's all grounded in the business case, in terms of that should be your measure that you go back and assess. And like you said at the beginning, Ray, also a situation where you say, "Yes, we are on track against those." You may be accruing additional benefits that you didn't expect, but there may also be other costs or implications. The hardest decision, I think, in many cases is to say no or to say, "Stop, we're not getting what we're looking for."

Ray: Yes, I think there's a lot of assumptions in...there's an overlying assumption that seems to creep into discussions around business cases and delivery, which is that we're talking about once the system goes in, we'll start realising the benefits. Well, that's assuming a delivery model where none of our customers or users see anything until we're finished all the delivery we're going to do.

So in that scenario, yes, it's very difficult to measure what...obviously, there's no feedback loop until the completion of delivery for the entire business case. And at that point, it's very difficult to measure any benefits during that delivery period. So you've effectively sunk all your costs and then hoping for the best. So unless you can set up a delivery model that does allow you to get elements of the...allow you to realise elements or benefits of those business cases earlier by adopting, I don't know what, a phased delivery model, or an instant delivery model, or any of those things allows you to get that user feedback earlier, you're setting yourself up to have that significant business risk.

Paul: And that's probably quite a good lead into the next question that we have, which is around the benefits that a strong business case can provide to a project, and the relationship there. So we'll explore that one a wee bit further in our next question (What benefits does a strong business case provide for an IT project?). But any other observations around what makes an effective business case? Especially from your own experiences and observations and through the projects and assignments that you have been involved with.

Ray: I'll add one thing to that is short. Because we're talking about all the things that we want in a business case, but this just multiplies things out and makes things very large. Actually, in reality, if we're talking about business cases that we want to end up chunking business cases down to smaller things, we want to be able to address benefits more quickly, we want to be able to react to a changing business environment, then actually having to produce a 100-page business case every single time we want to deliver anything very much slows down our ability to respond to those changes into that market.

So yes, get all these things in but in a way that we can do it quickly and effectively discuss it. And that might not be a traditional business case document, that might be other forms. I don't know. And actually, I've only personally produced business cases as documents. So I don't have an answer to this, but I'd like to think there are other ways that we could better communicate within an organisation - the formulation and changing of those business cases.

Paul: I guess that raises an interesting point, in the sense that in many cases, it's about fitting the culture and characteristics of the organisation. And just because you've got a template doesn't mean to say that you need to fill in every box in it.

Ray: Yeah.

Paul: You need to be mindful about...

Ray: Our business case is a good example of that.

Paul: Yeah, and you need to be mindful about what drives a particular organisation. I know, say for example, in the '80s I was working with one organisation where at that particular point in time, a lot of the business cases were predicated on head count reduction, where most of the savings were going to occur. For others, as we talked about before, it quite often is purely a numeric around return on investment. "Is this the best way," as Peter said earlier, "to spend this money," as distinct from putting it in the bank? "Am I going to generate the kind of return?"

For others, particularly if they're in a customer service organisation, it may be around customer satisfaction, customer engagement, and those all speak to some of the different measures. I just wondered, Carl and Peter, if you've got any other observations as well on this question?

Carl: I think something that BBC and other frameworks like that set up is a proper examination of alternatives. You know, quite often, if a business case is traditionally it's a sales document, then you've pretty much got an idea of what you want to do. And you shape the business case to sell that vision. But really it should be an honest exploration of is the problem so big that we have to do anything at all? And if it is, then what are our choices and, applying some objective set of criteria, which one is the best of those? I think that's something that in the past has been quite weak in business cases but is getting a lot better.

The other thing I'd say, and might seem like I'm contradicting my earlier point, but it's important that a business case doesn't overly constrain the delivery. So it's got to be succinct enough so that you know the general direction you want to go in, and how you know when you're heading there. But it shouldn't be so detailed and so trying to predict the future that actually you create a real mess for the people who have to deliver that project.

Peter: Yeah, in other words have some level of trust for the project team and the project manager.

Paul: That's great. Thank you for that.

Peter: Just one more thing. Just to reiterate around Carl's mentioning of options analysis and assessment of those options. I just couldn't agree more. But in a funny way, that serves to emphasise the importance of the business needs, the drivers. Because it's those, well-articulated, that actually serve to differentiate between the various options. So for me, finding that set of compelling needs and the related benefits is crucial.

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.