What benefits does a strong business case provide for an IT project?

In the previous posts in this series we have discussed What is the purpose of a business case and when would you use one? and What makes an effective business case?. In this Blab we address the question 'What benefits does a strong business case provide for an IT project?'.

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

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

This post covers the third question. The recorded Blab is ~17 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:  And we'll look now at our final question. And we'll actually going to combine these two, where we're looking at what's the actual impact and benefits associated with having a strong business case for that delivery project, for an IT project. So how can a business case, for better or for worse, impact on the delivery of, say for example, IT projects? And I wondered, Carl, if you had any particular observations around that. How that's actually grounded and the impact that it has on delivery, as that's something that you alluded to before.

Carl: Well, I think a good business case becomes a touchstone and a bit of a guide for the delivery team. Some IT projects can -- using Peter's phrase earlier -- wrap a bubble around themselves and get a little bit disconnected from the business that they're delivering to. And some of that depends on your delivery methodology. But a good business case, everyone knows why they're doing what they're doing, and what's expected out of that. And so the focus then is not on some atomic level on database tables or, you know, a component in the system. It's actually about the business processes and the outcomes and outputs that you want. To me, it actually grounds everyone in the reality of the business that they're in.

Paul: So I guess just picking up on that question or that point you've raised there, Carl, how do you get that connection when at the time you're developing the business case? What should you be doing, and who should you be looking to involve in that process of business case development?

Carl: Well, I think there's two key roles and some of this is an expression of two key roles you have in a Scrum team. You need to have an investor, who's passionate about the vision that's expressed in the business case and is passionate about getting those outcomes and those benefits that are required. And you need to have a team of people that get a chance to input into the business case. So quite often on a project, the business case is written -- in many organisations, it's considered pre-project -- and there's no chance for people who have an understanding of delivery to provide any input.

So just as in Scrum, you've got that interchange between people doing the work to people investing the money. A good business case will enable that as well.

Peter: That's interesting. In my experience, huge number of projects and their business cases are done completely separately from each other. It's almost like a complete change of guard between the business case development phase and the delivery phase.

Ray: To be perfectly honest, given most business cases, historically, in my experience have benefits that if they're well-articulated they're realisable only after a certain amount of time after all the delivery is completed. It's very difficult to set up an environment...they drive a behaviour which is to...what's the term? To cut off delivery from your business case. It serves as a divider, by defining those measures as only realisable and significant post-delivery. You may well have contracted an external vendor to do the delivery, at which point they're already two years gone. They're onto another project by the time you can even possibly measure the benefits that you've got.

So that to talk to the impact that a weak business case has on delivery, I'd argue even if you've got all those things in place and you've got a vision and you've got all that articulated and you've had the discussion, you've got your measures defined, if those measures are still only measurable two years after delivery, it's still a weak business case from a delivery standpoint. It doesn't help you assess whether you're achieving the goals that the business is trying to achieve with your delivery.

Paul: So, I guess, in some ways what you're saying there, Ray, is really it's about...one of the litmus tests is the actual ability to implement and deliver what's in the business case. And as you say, whether that's evidenced after the event, or whether it can be progressively evidenced during delivery -- and that speaks to some of the delivery and implementation approaches that can be used, especially ones of a more agile nature. I guess it also speaks to that philosophy of if you're going to fail, fail fast. And don't expend an awful lot of time, effort, and money on something that's ultimately going to fail. If you're not sure and you're not certain, test it out and find out very quickly before you spend an awful lot of time and money on that.

I guess the other aspect that you mentioned as well is that disconnect, quite often that occurs. We often describe it as that disconnect between, so to speak, sales and delivery, where sales team go out and promise something and then you as the person who then has to deliver it have to contend with any expectations that are being set at the outset.

And one other little philosophy I quite like is: 'you commit, you deliver'. So if you're involved in making those commitments in the business case, then you're going to be involved in delivery on those commitments. You're going to be an awful lot more circumspect about what you promise in a business case and what can be delivered in a business case, in terms of the actual practicality of it.

Any observations around that, in terms of those aspects of delivery, how they can be better reflected in a business case, and what are some of the challenges that are there as well? Strengths and weaknesses.

Ray: So I think that talks to Carl's point, Carl's observation that Scrum has those two roles to provide that interlink between the financial element and the delivery. I think Scrum does therefore provide a...there is a specific role which does exactly what you're talking about, providing that interconnect, the product owner, ensure there is that feedback loop there between the delivery element and the investment in the business case in the first place.

Carl: If you look at people like Standish, they've said for the last 20 years, that the key determining factor of project success is executive support. The continuing involvement of the investor in the project. Not putting their reputation on the line perhaps with their peers and getting the business case signed off and then effectively delegating it to a vendor and a PM, but continuing to be involved, continuing to understand the decisions that are being made and support them. And really so they're on the journey. They're not, "Here's the thing I want," a little bit, "Off you go," throw it over the wall type stuff. But they're there understanding the difficulties that the team may be facing, and they're making the choices that now that you've got more understanding as you're in the delivery process, we'll deliver the best return for the organisation. And perhaps, they'll also have enough visibility through that understanding to know when the project's not delivering the best value for the organisation.

We've talked about a business case showing you when it's time to stop. If you're not involved in the doing of the project enough and you're getting reports that may to some degree be green-washed by PMs or vendors, you don't have the chance to blow that whistle and to say stop.

Paul: A key point that you've touched on there is that continuity of involvement, especially by the executive and senior managers right from the business case through into delivery. And again, business managers who're involved in development of the business case are going to be a lot more invested in and interested in the achievement of those business benefits if they're going to have to live with the consequences in terms of the system or process that's implemented as a result.

Peter: I think in the absence of some of those things that we've just talked about, there is a set of potentially perverse incentives. The business case the incentive is to get the money and, if you like, almost diminish the challenges, emphasise the benefits. Essentially, sell it as a positive sense. And then the project gets something which is potentially undeliverable, certainly in terms of meeting the claimed benefits. And then the project's got incentives which are around what constitutes its scope, the degree to which it can then de-scope and sort of get something across the line.

And then you have, it's the ongoing business as usual that picks up the tab. As you say, Paul, it's not a case of the cost being paid; it's just a case of when and where the cost is paid. So some of the things we've talked about, that continued executive sponsorship and perhaps the chunking and cycle times for projects, from inception to completion, they help reduce the effective some of those incentives, perverse incentives.

Paul: Yeah, no, I think that's really interesting, too, as you said around...you're really looking for people who are committed to the delivery of the outcome and you want them involved as early in the process as possible. With some business cases, if you happen to be the executive who happened to pop out to the toilet in the middle of a senior management meeting...

Peter: Guess what?

Paul: ...you discover that you're being gifted this particular project, your level of commitment to that is going to be very different from somebody else who has got a strong vested interested in the successful delivery of their project. Who, to put it in the colloquial, 'has their balls on the block', in terms of the successful outcome.

And certainly from my experience, those projects are the ones that are quite often seen to be the most successful, where it has existed right from the beginning through to the delivery and implementation of those systems.

Peter: Agreed.

Ray: Just with my...I have my dev manager hat on. From a business case standpoint, having those measures in place to be able to measure...I'm very much interested in the ongoing cost of operating and supporting this thing after it's delivered. So unless I've got a business case that talks to that, I'm seriously worried because the likely scenario is that the delivery is entirely focused on exactly that delivery and then after the event, I've got a system that's unsupportable or expensive to maintain, all that sort of thing. And my support costs snowball, which as far as my organisation is concerned, they couldn't care less about the support and maintenance. They just want the thing and they want the next feature and they want the value that they can derive from it. But I've got a limited amount of money that I can spend on IT overall, and if I'm spending 90% of it in supporting the last system that was delivered, then I can provide very little value to my business overall. So it's definitely in my best interest from an IT standpoint and from my organisation standpoint if those business cases do talk to the total cost, the cost of ownership and the whole shooting match.

And then from an IT delivery standpoint, that also drives the right behaviours in terms of ensuring that we're delivering a maintainable system and an operatable system or we've got the right admin features in and all that sort of stuff that you need to be able to reduce the long-term costs of having this thing in place.

So I think a weak business case, another element of a weak business case would be not talking about those...that total cost of ownership. And the impact on IT delivery on that is potentially very large.

Paul: I guess the difference there is talking about an idea versus an idea delivered in context. So you can have the greatest idea in the world and that can be reflected in the business case, but it is actually only grounded and made real in its implementation and operation. And so to truly look as you see it at both the operational impact and the true cost of ownership, you need to look at it as the total package as you said there.

And also too, I guess, you allude to an interesting thing there, Ray, is that quite often then the people who have to operate it post-implementation are the ones who then, quite often, have to live with the consequences of that, for better or for worse.

The other thing that you touched on as well earlier on in the conversation was around what I term the ta-da moment, when you pull the covers off and you say, "Here it is!" And everybody goes...

Ray: "Oh shit, that's not what I wanted."

Paul: Yeah. How do you balance that element in the business case as well? What are some of the other things we can do to minimise the impact of the ta-da moment?

Ray: I think that comes back to the chunking. But to be honest, the business case isn't the be-all, end-all. Unless you've got all those other...unless you've got a collaborative relationship between your business and your delivery organisation, it's going to be very difficult to get rid of that 'ta-da moment'. You need the...There's a whole cultural element to that, where you need to ensure you've got that collaboration. And yes, you can have some drivers in your business case to ensure that's the case, but I think there's a bigger organisational question there, and it's not necessarily appropriate to try and address everything in the business case. Otherwise, you end up with a...you get the 300-page business case every single time we want to effect a minor change.

Peter: I agree with you, Ray, and I'd point to some aspects about procurement processes that end up producing a result which in one sense might be the best price, but one of the downsides of that is that it's effectively destroyed the trust relationships. And the parties, the successful party, may well then have gone into a mode which is very low-trust and their upfront price is low, but they'll be looking to address that progressively through change control and other mechanisms. It just leads to - and I think we've all seen this in different projects and ongoing relationships - quite a corrosive relationship between the requester of the services, the payer, and the delivery.

Ray: The credentials.

Peter: But this is philosophical and, as you say, almost structural in terms of how we conduct the process of change and so on.

Carl: There's another aspect in terms of organisation. Typically, what I've seen is systems put in via a large business case gets written, you have a big huge project that goes for a number of years. You put the system in, and you flog it to death for 20 years until it's in a bad enough state that you have to write another business case and start the whole process again.

And this is where the concept of product ownership in Scrum, it's actually not about the system, it's about the whole delivery chain and if we can shift from this once-every-20-year cycle of projects to this system as an asset for my organisation that helps me deliver value, and just as I paint my house every few years, I should be doing things to look after my system. There's fundamental changes required to funding and planning and all sorts of things, but it's asset lifecycle management that we're talking about.

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.