Episode 23 – How to create a business case

Welcome to another episode of our podcast. Today’s topic is about creating a formal business case as part of the change process.

Creating a business case document can be a challenge for someone who has not done that before, and one might think that this is a single-person activity. Nothing could be further from the truth – in our experience, a good business case document is the result of collaboration between multiple people in your organization (and vendors) that happens in multiple iterations until every stakeholder gives the “green light”.

In detail we are talking about:

• Why the need for a business case?
• Where does business case creation fit into the change lifecycle?
• High-level steps to create a business case
• What information do you need to create a business case?
• Who should be involved in making the case?
• Example business case in the context of a value proposition
• Tips & tricks to make an effective business case

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

• In this episode we made some references to previous episodes

• Business case development as part of the lifecycle of change (see the full study here).

• When selecting make them SMART > Wikipedia
• Business case in the context of the overall value proposition

• If you want to learn more about “the greater good”, I recommend to watch “Hot Fuzz“
• For those of you with good hearing, you might have noticed some barking around minute 16 – dear listeners: meet Frieda, our new puppy

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

• CP1 (Welcome)
• Wish You Knew Me (Interlude 1)
• RakeBeatChords (Interlude 2)
• Wurly (Interlude 3)
• South Wing (Outro)

---

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey J-M, how are you doing?

J-M: Not too bad Roland. Not too bad. I’m actually really excited today. We’re trying a brand new recording software for the podcast, so as we mention at the end of every episode, if you like it, leave us feedback. If you hate it, leave us feedback. We’d love to hear from you every time we try and continuously improve our process to make your listening experience that much better. But Roland, today we are addressing something pretty darn cool and something that I’ve been waiting a while for us to talk about. And why don’t you give us a little introduction for today’s episode?

Roland: Well, you’re waiting for a while because it was your idea that we have this show today, so it just took a little bit because we had all those interesting guests beforehand.

J-M: We did. We did. It was really exciting.

Roland: But the topic of today is how to create a business case, and that is something like the Magic Unicorn when your boss comes to you and says, “Oh yeah, you gotta have a business case for your idea and otherwise nobody would approve any money”. So we’re going to talk about what are the components of a business case, or when do you need one? And all those things so that at the end of our conversation (which we tried to limit to 45 minutes this time) you’re strengthened and the person of steel when you go back to your boss and say “sure, boss, I got the business case done for my good idea”.

J-M: Absolutely, and I think that’s the very first section we’re going to jump straight into because I know people are eager to figure out how to make change happen at their organization. And particularly a lot of change has costs associated with it. I mean, listen, people are burning hours regardless. Your human resource costs. And oftentimes change requires something like the purchase of platforms or the engagement of services from an external consultancy or another company that’s going to come in and outsource some of what you do. So change is often costly. But we also know change is incredibly valuable, so the business case is going to help us to really prove that out, to make change palatable, and to ultimately help to see and track whether or not change is effective. So that’s the very first piece of our puzzle today: we want to talk about ‘why do you even need a business case’? And of course, as I’ve been saying, the first thing is to validate the need for change. What do you think about that?

Roland: That’s true, that’s true. And we all know change is scary, as you just said, right? So I think that’s one thing. Describe what the change is, in written form so that people can read it and have their thoughts on it. And you iterate on it and whatnot. But I also think it’s a good way of gaining consensus on those changes. The need for change and obviously (and we’re going to talk about that a little bit later) how you want to implement that change, because this might be threatening for some stakeholders. They might say, “I’m going to lose something here and I don’t like this”, so getting stakeholder buy-in is equally as important as being able to get consensus with everybody who is going to be affected.

J-M: Yeah, and that’s part of what we talked about in our change episode. Change management does involve some sort of courting of stakeholders, but giving them that carrot – the reason why they’re going to be changing and why that’s valuable to them, that’s really important. And a business case helps to try and address that. You’re quantifying and qualifying some of the things that are going to come down the line as a result of change. And you’re going to give them that reason behind it. And that’s the third thing in what we want to do for the change case, or the business case specifically, is to quantify that benefit. So you want to be able to say, “here’s what you’re going to save. Here is how it’s going to do for you and the organization and for the people, our customers, all those sorts of things”. You want to quantify, and in some cases qualify, the benefits of change. Give them that Nirvana that they’re going to achieve once you’ve done the change.

Roland: I wouldn’t say it’s like Nirvana, but I’m happy that you mentioned that it’s also a qualitative component there. Because a lot of business cases that I’ve participated in, they all try to boil it down to dollars and cents, and I think you cut yourself short. But since I looked at our show notes that we’re using for these shows, I know that we’re going to talk about that a little bit later. But I think the last reason why you want to have a business case is obviously you want to get your executive approval. Somebody is holding the purse. And as we learned in one of our Shorts, you need to show which capabilities you create, which capabilities you change, which capabilities you retire, and other benefits that you might see out of your proposed initiative, and then somebody will decide on it. If we’re going forward or not.

J-M: Yeah, talking about that executive approval on project sponsorship. I mean, you’re tying a change and the cost of change to somebody else’s KPIs. We have an expression around here: if I can help you get promoted, then you’re going to buy whatever I’m selling. And so this business case needs to help align the change and the cost with the outcomes that are associated with that role and its metrics. And of course, that will give you the opportunity for great project sponsorship because people are going to want to buy into something that will help them achieve some of their career goals at the organization they’re at. And that’s a really big part of making that case for change and making that business case for change.

Roland: Yeah, but that should be just one side effect. You should not get into the habit of seeing everything transactionally. Because sometimes it’s OK, and it’s better if you do it for the good or the greater good, you know, when you do things.

J-M: I believe they’re very much. The only thing I’ll say here is that I’ve come into a lot of situations (and we’ll talk about this a little bit later, as like a lesson learned) where we have change cases that are built that are a nice-to-have case. And they say that trying to optimize is the death of innovation, because all you’ll do is try to optimize the thing over and over again until it’s gone. And you’ve missed the boat on really making a good change. I think that when you’re talking about taking on the greater good, you want to make sure that that greater good is imminent. That there is something that is measurable, specific and that is visible to people, and so that often ties into metrics and KPIs. That often is something that somebody thought about beforehand. You’re not just going “hey, wouldn’t it be nice?” And “here’s the perfect place we could get to”. I think we address that a little bit in our life cycle of change and I wanted to bridge into that piece of the puzzle. And Roland, I know you and I have been talking back and forth about change life cycles, and can you describe a little bit to me where you see the business case fitting into that change lifecycle / into that whole process? Because I know we talked about Shorts. Where does that business case start to come in? And what are the inputs and outputs that you see in the business case and the different steps?

Roland: Yeah, I think, and you will elaborate a little bit more on the details afterwards, but I think it happens at the very, very first start. You know, somebody has an idea. Now, every one of us has ideas all day long, right? They might or might not have the quality that you might need to articulate and achieve those objectives that we just discussed. It might just be a weird idea, but you haven’t thought about how to implement it in all these types of things. So the business case, as the very, very first step, is basically like the formalization of the idea. And there’s a couple of other aspects that come in, but the main idea that we said before is you want to create alignment. Alignment with your stakeholders, alignment with the people holding the purse; alignment with the people who are affected by change. And then, based on that, when we think about the change life cycle, the next step would then be to go and to define what the change will be. And that’s a little bit more than to say, “Oh yeah, make the world a better place”. You will need to go and you wanted to say, “OK, hey, I want to change this and these are the impact on apps on organizations on roles on processes” and all these things that you and I spoke about when we were defining capabilities many many times. But after that, J-M, what happens then in that lifecycle?

J-M: Yeah, so we got that alignment / that definition, then what we’re going to talk about in tying into our business cases is how we’re going to do that. So the design of the processes, the design of the architecture, the design and how it fits into the strategy and how that’s going to be implemented. So the solutions we have decided on to achieve our designs. So now we have aligned definition, design, and implementation. And then we’re going to try and tie that into realized business benefits. So what is that all going to tie in and lean into? What is this going to give us? And the realization of that is going to come from a lot of different places. We’re going to talk with the sources of value / how the business case is calculated. But once again talking about the impact of people, the impact to process, the impact to technology, the impact to financial, the impact to risk, the impact to customers, all these sort of realized better benefits. We’re going to put that into our business case. And so what we should have at the end of that is an understanding of where it aligns to the architecture, environment, and strategy. What are we defining as our problems? How are we going to solve them conceptually? How are we going to solve them logically? And then, how is that solution going to make things better in quantifiable and qualifiable ways? I think we’re going to put up a nice graphic from one of our friends in the show notes that we’ll give you a picture of what we’re talking about today. But let’s talk about the details and some of these things, because I know that we’ve got a few different aspects we’re going to be considering along the way. So what are we going to do to make these things come to life? How do we fill out these boxes? Roland, tell me a little bit about some of those really important things to remember when creating that lifecycle.

Roland: So there’s obviously some high level steps that you go through, right? So the first one is you need to understand what your organization’s goals are. And that might be a challenge in itself, because I’ve seen organizations who claim they had a strategy, but they never put it somehow in writing or in architecture diagrams, or it’s in the heads of the people. That’s not good enough, right? Because you obviously want to align everything to it. And based on that, when you know where the ship is sailing well then you would go and define the objectives. And the objectives, if you break them down, should be SMART. So specific, measurable, time based and so on. The acronym SMART. Because at the end of the day (and just let me come back to the realization phase that you mentioned), I have seen just a few projects who actually went there. Most projects just stopped and said “yay, we got, we went live. We got our system implemented. Now we all go home. Or you have some post-go-live support phase for a couple of weeks or so.

J-M: Yeah, we talked about that in the process mining episode a little bit about how the idea of tracking back business benefits is a really important part. I feel like that’s the first thing to forget – what happens after we go live. We just sort of drop the pen and go “sounds good, test’s over.” No, no; this is the start of a new tomorrow. We need to live in that tomorrow and figure out how good it actually is because that’s the driver for our next level of iterative process improvement. That is the future state, right? Roland: That is true. I think I said that in another show, but you often have those objectives like “we need to do so and so many trainings”, right? That’s not important. What’s important is can J-M in his new role as whatever, do his job better than he did before?

J-M: So that’s a great point you made there, Roland, and I think that one of the things we’ll talk about when we talk about what our goals are is also to talk about looking at where we are today. So what are we doing right now? Where is that working? We have an expression, you know. It’s like a GPS. It’s very hard to get a GPS and tell you how to get somewhere if you don’t have an idea of where you are right now. You need to have that routing from today to tomorrow. And part of the business case / part of the things you’re defining as part of your business case is: what is that delta? What are we actually going to make with this? And how does that change our current situation? So you gotta get those goals and outcomes, your desires with the organization, the alignment with strategy, and then a current state analysis. And that’s going to give you that view of things and also identify where your current state isn’t sufficient. And that’s a really important part.

Roland: Yes, and all the architects on the call right now in our listenership will say “yeah, wouldn’t it be great if we had everything in a repository that everyone can access instead of doing napkins and whiteboards?” But yeah, I’m with you. But then the next step in the high level things you’re doing is to identify your decision makers and your stakeholders. You know where you are. You have an idea where you might want to go, but then you have to say, “OK. Who’s affected by this?” And that might be like I said before, the purse holder, or that might be people whose jobs might be on the line or changed. It might be a larger reorganization that you have to talk to unions and your HR folks, and whatever might come up. But it’s important that you have clarity about this and that you don’t forget those important people.

J-M: Absolutely. And to those people and for the organization, what you’re going to do is create a kind of mantra / mandate. Things you’re going to say that are all around what you’re doing. So these are ‘declarations of values’. Here’s the thing we’re going to create. Here’s the thing: we’re going to retire. Here’s the thing we’re going to change. Here is the specific value that we’re going to create as a result of this project. And so you’re going through and creating this set of values that you’re going to be passing over to the rest of the organization or the rest of the stakeholders you’ve identified to say “these are the specific values that we look to achieve with this initiative.”

Roland: I think that’s two things. One of what you described is the actual transformation, right? Oh, we’re going to do these and those changes. But I think when you talk about values, it’s more things like, “oh, we’re reducing the data consumption by X”, “oh we speed up our governance process by Y”, or “we increase our delivery rate by X percent”. Those are the value statements that you need to have because those are stakeholder-specific. When you talk to your CFO, he might be a good person or she might be a good person and think about why we should do all those green sustainable things. But at the end of the day, their job is to count dollars and cents, right? So you need to talk to them in their language, which means, “oh, we’re going to have those savings”, or “we’re going to make more money by doing this”. While if you’re talking to your quality management person, he might not think about dollars and cents. He might think about “what’s the efficiency of my process?” “Do I have fewer errors in producing our widgets?” And so on and so forth. So articulate your values and align them with the stakeholders so that you speak their language.

J-M: And also align them to the strategies, right? Because one of the things you’re gonna see in a lot of organizations is that they will put these lofty strategies out there and they aren’t quantified at all really well. A lot of them aren’t. Most of them are just like we want to become a more customer centric bank. We want to become the number one producer in the world of this particular thing. We have a lot of these high level strategic statements. If you can align the value of a change to a strategic statement, let’s say, for instance, we’re going to bring in a platform to do customer journey mapping. Well, that’s going to be perfectly aligned. So we’re going to be able to say the value statement is we’re going to have a tighter alignment between our customers’ experience and our process design. That perfectly fits into a strategic statement that you can now latch onto. An executive is going to love that.

Roland: Well, he loves it even more when you say, “hey, these are the changes that I do. This is the value that I create from then. And by the way, this is how we measure it.” So that you have literally, like I said, SMART objectives, that you have something you can say “OK, we’re going to sell more of this by X percent or we’re gonna reduce the time by Y percent” or whatever measurable thing you have. Because you might have a good idea about the value statement, but if you cannot measure it and people don’t agree on your way of measuring it, it’s not worth anything.

J-M: So as you’re creating a business case, you’re going to say “here’s how we’re going to see those benefits that we’re trying to track”, and “here is where we’re going to measure”. “Here’s what we’re going to look for”. “Here’s what you can expect, and here’s how we’re going to present it to you.” So we’re going to demonstrate that value in these specific ways. And what are the processes, architectures and people we’re going to touch on so that we’re going to be able to see that reflected back on us. And if you can put all those things into place, what you’ve got is a really convincing start to your business case. You know what your goals are. You know what you have today. You understand who you are appealing to. You understand what value statements you’re going to be declaring as things are going to happen. And you’re going to be outlining how you’re going to measure it along the way. That’s a really powerful combination, and that’s going to get you started with the very first step of your value process / your business case development process.

Roland: Absolutely, and maybe to close out this segment, we obviously have a little break. But during that break I’m asking you to think about: what do you want to do in your organization and how have you tried to get people to act on this? What tools have you used in the past and where have you struggled to see actions? So we’ll leave you alone for a few seconds, and when we come back we’re going to talk about how? How do we create this thing?

Musical Interlude: “Wish You Knew Me”, Jeremy Voltz

J-M: Alright, folks, I’m really glad we got these little musical interludes. I think it gives our brains a break between trying to make all these things happen and particularly around building business cases. I’m really excited to be talking about this today because a lot of people I know and love very dearly have really excellent ideas, but they get left on the shelf because they can’t prove how excellent their idea is. And that’s the biggest shame of all. Knowing that you’ve got the right idea, but feeling crazy because no one else believes you.

Roland: Yeah, J-M, that’s true. But obviously that’s the ultimate question: what information do you need to create a business case? So how do I get started with putting ink on paper?

J-M: Yeah, that’s a really good point. So I’m going to go into these three categories that we’re going to talk about as part of the business case. It’s information you can kind of gather along the way that you’ll want to take a look at. We’re going to talk about quantified benefits. Some examples of quantified benefits. You can get some examples of unquantified benefits, and some examples of costs. Because, remember, the business case is always going to be offset by the cost of achieving some of the goals you’re trying to get to. So let’s first talk about quantified benefits, and these are usually things like risk-adjusted present values. You usually have time periods over which you’re going to be measuring this like a three year or five year analysis, but that’s going to go into making this business case really stick in a specific time box. So here are some examples of things that you might find for quantifiable benefits. So the first thing is talking about people. So one of the really quantifiable benefits is reduced time spent on tasks. A perfect example, and often we talk about architecture and process tools, you might think about a reduced time spent on business process analysis. And then to quantify that you simply multiply the cost of your human resources by that time differential that you’re predicting as a result of bringing this in. So you’re trying to predict what that change will be in your overall spend on people. And that’s something that you can usually do. As a perfect example, you can do things like test the amount of time required by doing a POC or POV to see how long it takes to do things like create an architecture diagram? How long does it take to create a business process model? And in case that’s something that you do all the time, you can get a rough sense of how often that has to happen. The velocity as a result, multiply that you create the time as a result, multiply the cost. You create the overall value of a reduction in time. And the second thing is, when we talk about transformations, one of the things that organizations are going through a lot is they’re trying to evolve. This is part of what your business case might address, and particularly in architecture and business processes, we see a lot of people trying to introduce new processes to transform the business, and that can take quite a long time. Those projects have a very heavy burn in terms of dollars. Once again, a lot of human resources. Projects often have things like service resources that are required, so if you’ve got an SI who’s supporting you, that might be an external cost you can factor into that. If you have systems that are supporting you, you might be reducing or eliminating certain systems. The transformation process is very expensive and if you can reduce the time to transformation by introducing a platform or introducing a practice, those sorts of things can really add up in terms of actual dollars saved throughout the process.

Roland: Yeah, and maybe the other thing that you might want to think about is obviously when it comes to the execution of your implementations. You want to have better speed and quality of your implementation. So think about having clarity, with having a good blueprint that ideally synchronizes with your implementation tool. So not only faster in designing your solution, but when it comes to scope change or open questions that come up during the implementation, well, you have something to look at and it synchronizes back to your architectural tool or to your implementation tool, which basically increases the quality of your implementation. There are no loose ends at the end of the day, and you still have articulated where the journey should go and how those changes align to it.

J-M: Yeah, exactly. And I feel like we’re talking a lot about business cases in the context of architecture and process tools. That’s kind of where we come from, and I think that that’s a really good sort of proving point for how you create a business case. And that particularly ties to the fourth idea, which is all about the effect of your implementations on end users. And that’s going to be talking about whether or not those people who are doing their jobs after an implementation can do their jobs faster. Whether they have the productivity improvements you’re looking for. So for example, RPA. RPA business cases are all about giving end users productivity improvements, and you can see a huge amount in both directly realized benefits (in terms of you need fewer people to do the same jobs) or opportunities, as in you can do more with the people you already have and so you can use those people to be able to have more innovation, to handle more cases, to be able to pivot the business. Lots of things. You’ve got optimization of processes and execution at the end of the line if you will. Those are quantifiable benefits that you can at least predict, and then you can track back.

Roland: Or to talk in architecture speak, you’re improving your capability. But when you think about your business case, that also could mean that you take a capability and you outsource it. Or you buy another company that provides that capability for you. So like you said, business cases are not only for architecture and process scenarios. Business cases should actually be used for all of those decisions that you want. Business cases also have another benefit that you should keep in mind. Because what you’re doing is you’re not only defining what the new world should be, you should also do some rationalization and some strategic alignment with your as-is. And when you talk to IT departments, it’s not uncommon to hear that they say, “oh, we’re going to spend 80% of our budgets just to keep our lights on.” So if you can reduce legacy infrastructure, if you can reduce the amount of apps that you have, you reduce costs, right? And that cost savings then can go into innovation. And hopefully the CFO will not take away those savings from you. You know, so that you’ll just have a smaller budget, but you actually can use it for something that brings the company forward.

J-M: Yeah, and I know a lot of organizations that actually have rationalization targets, and sometimes they really struggle to meet those targets. If your business case involves helping them achieve their targets, you’ve achieved that strategic alignment! It’s perfect, because now you’re hooked into something that people have already committed that they want to do. You’re putting into your business case how you’re going to help them achieve their goals.

Roland: Agreed. But J-M, this is just one aspect of things that you want to look at when you create your business case. And unfortunately, I’ve been in too many situations where business case development has ended now. “How many transactions do I save?” “How many, whatever you know?” So you’re starting to bean count. I think there’s an additional set of benefits, J-M, that are not quantifiable. Can you talk a little bit about that?

J-M: Yeah, absolutely. This is something that we struggle with all the time. And the very first one is the business benefit (and that’s really hard to track) of not being fined. Really difficult one. Well, here’s a question. How big is the fine? How likely was it that we were gonna get fined? You know, there’s a lot of regulatory compliance. There’s a lot of risk management. There’s a lot that goes into the cost of doing business for a company. I’ve seen so many companies in the news who, because they didn’t make a change, they got hacked or they had significant negative public exposure that reduced their business reputation. There are so many costs that could come up as a result of the failure of process and architecture and practices and people, and the transformations in the business case you’re trying to build might remove or reduce a lot of those risks and governance needs. And maybe you’re not going to lose your certification in ISO. Maybe you’re not going to fall out of SOX compliance. These are all things that are unfortunately really hard to quantify, but we know they’re there. And like all the architects on the line are going “of course we know!” We know that this matters, and it’s important to include those unquantifiable benefits because really, it truly is not quantifiable. You don’t know what the FCC would levy is a fine against you. You’re just trying to say as part of the reason for this project moving forward / the case for this project, I’m going to outline things you don’t want to happen that we think we will prevent from happening.

Roland: And I don’t want to burst your bubble, but I’m pretty sure that there are people in banks who do that calculation. Like “in the past, we got fined that dollar amount on this, well the probability that we can find the same amount is very high.” What’s the project cost? But yeah, I’m with you. And I think risk management is the topic that we’re talking about. Things like you said, like reputation. Do I want to buy from this shady company? For example, if you are a bank that cannot handle money well…

J-M: Oh my goodness, no. And the other thing we want to remember is that we’re in the time of (depending on what you call it) ‘the great resignation’, ‘the great shuffle’, the “nothing, nothing’s wrong at all”, as some people would put it. Employee experience is incredibly valuable right now. A positive employee experience. And particularly we look at very poor tools and platforms people are using – like everyone hates their expense reporting tool or everyone hates to submit deals to their deal approval system. Everyone hates the pricing tools, etc. These are people who are complaining about the tools they use in their daily lives and that can lead to a really poor employee experience. Bad processes, constant workarounds and negotiations. And it’s really hard to quantify that. But I did a study earlier where we did a rough back-of-the-napkin cost of employee attrition, and we came up with the estimate that this company was burning about $10 million a year in just one department, this one business unit. $10 million a year in unnecessary training and employee onboarding because of it. A lot of people were leaving and all the exit interviews were citing the same problems over and over again. Had they solved those problems, we estimated, they could have saved $10 million a year in the HR and onboarding costs of new employees. It’s unbelievable. And you can do that by making better processes, better technology come to life that can be part of your business case. We’re going to make it easier to work here.

Roland: Yeah, that makes sense, but I guess a big factor was also people.

J-M: Isn’t it always?

Roland: But on the other hand, after you’ve had that inward-looking perspective, there’s obviously the outward-looking perspective. What is the customer experience? And I think that we as consumers / we as customers are now a little bit spoiled. You know, we expect instant delivery from our favorite online shop. We expect our meals to be brought to our front door. All those wonderful things that unfortunately, thanks to the pandemic, became more normal. But I think it’s very important to go and say “OK, what is the impact on the customer experience?” “How do we improve our processes and how do we improve that customer journey so that we’re more sticky or more attractive to our customers compared to our competition?” J-M: And you might complain that customer expectations are too high, but that really doesn’t matter, because that’s the expectation. Roland: Yeah, get over it.

J-M: And if you don’t meet it, it doesn’t matter how hard it was. There’s a plaque over my mother’s desk that says ‘don’t tell me how rocky the seas are, just bring the ship in’. If you can’t satisfy your customer, it doesn’t matter that their expectations were too high. You weren’t good enough.

Roland: Agreed. And [those expectations] are always changing. It’s those situations where you don’t go to work for 40 years and do the same thing over and over again. There’s always something new, and at the end of the day, don’t blame the customer. They pay your bills. Speaking of which, bills would be paid in money, J-M. So one of the big aspects that we have in a business case development is obviously cost. We were speaking all about the benefits and how much money we save or how much money we make or how happy our customers are. But obviously somebody has to pick up the bill, right? What are the cost factors that are part of your business case?

J-M: Yeah, absolutely. So you have to account for all the things because you want to make sure that you’re comprehensive. There are no holes in your business case. That’s a really important lesson learned. If people can poke holes in the business case, it doesn’t matter how accurate everything else is, you’ve lost credibility. And one of the big things is cost. And the first cost you can pretty easily put out there is internal resource costs. So obviously you’re going to have to have the cost of the salary of all the people who are going to be working on bringing this project to life. And so add that salary cost. Remember, there’s also kind of the hidden cost of the opportunity cost of not doing other things. So if they’re doing your project, they’re not doing this other project, and so you have to fight to make sure that your costs are appropriate and that the value is above what they would be doing if they could do something else. And so remember that those costs on internal resources are important, as there are also both internal and external costs there. So human resources are a big part of things. Sometimes you’ll have contractors who you have to call in, and those are actually pretty easy costs to calculate because you have quotes or existing service agreements with contractors. So essentially whatever your team is going to cost, you will know that. And if you have a project timeline, then you’ll have an understanding of how much you have to engage that person. You sometimes also have FTE calculations, like how many FTE equivalents am I going to need for how long, and that will give you an overall human resource, costs both internal and external if you’ve got contractors.

Roland: Yeah, and I think the second big bucket in this chapter of your business case is also technology costs. Because everybody says “oh yeah, I wanna build this new thing” and you’re talking about licensees and hosting and all those other things. But what they typically forget is, there’s obviously migration costs, right? Your data migration. Or there might be penalties that you have to pay because you break your contract with your legacy vendor, right? And they say “oh, that’s great, but pay me for the rest of my period that I’m under contract with you.” So it’s not only just the boxes and cables and whatever the hardware and other things that you have, but it’s also those hidden costs that you have. You know, maybe you had that wonderful idea of, oh, we can reduce those applications and then we can take it out and then we get rid of that data center and blah. But you forgot, because you didn’t do your homework correctly, that there’s this old legacy system that somebody in that furthest corner of your organization is still using, and that means you need to keep your data center and all those wonderful things in place and your business case just crumbles. Because you don’t have the savings that you would have expected.

J-M: Exactly that’s true. And remember that when you talk about migration, that leads me to the other cost. This is an external cost, but there are lots of services that end up getting engaged in these sorts of projects. I mean, I came from working for a management consulting company. It wasn’t just a contractor that I could call up, and I know his hourly or her hourly. Unfortunately, it’s a whole organization. I might have to go through an RFx process. I might have to select a vendor of choice like an implementation partner or SI to go do this for me and there’s costs to running that process. Then there are the external service costs that they will have during the execution of the project, so it’s not just a human resource cost; it’s actually a service cost you’re paying. And then remember, after go-live (remember we talked about how you forget that), there could be a new ongoing maintenance cost for tools. A lot of technology vendors will stick you with a huge yearly bill, not just for license costs, but for the services required to operate that new platform. And so you could have ongoing service support center costs of millions a year that you have to account for in your business case. Because that’s going to be something you’re going to have to absorb as a result of this project.

Roland: Yeah, and as we’ve spoken multiple times and we definitely should have an episode about this, the other way could be that the knowledge works out of the door. You have projects, the team will be disbanded, people will go their merry ways, and you lose that knowledge. So in summary, your information that you need is not only the phases that we have in the change lifecycle. Your designs and all these things. But obviously it’s your quantified benefits, your unquantified benefits, and the cost. But now, J-M, we have all that stuff assembled. Who do you need to involve to make your business case? You’ve put ink on your paper. It looks all good. People might have vetted it. You know your significant other looked through it and said “J-M, good job”. But who would you involve in making this business case, in producing it, and then obviously getting it approved?

J-M: So what you want to have is the weight of authenticity. And the weight of authenticity comes from bringing the right people to the table to contribute to this whole exercise. And that starts with subject matter experts. It really does. You need to have your numbers validated by people who know how much things cost, and you need to have their names on the page to say “here is where I got my numbers from. Here is who contributed to this.” So first, involve those subject matter experts early on. Know what your architects or your enterprise architecture team or your IT service team has got in terms of their architecture, how much they’re paying in license fees, what their external service costs are. Have that all very clearly laid out and involve them and say “listen. I’m making a business case. Can you give me these numbers?” And that’s not just your subject matter experts in architecture, but also in human resources. You can get rough numbers from them, but also your architects to say what is my architectural impact in this case? What is it going to touch on? So can you pull up your application library? Can you pull up all of the interfaces that you’ve built and what am I going to do if I do this project? How am I going to change things? What is this going to impact? And that’s going to add a lot of more detail to your as-is and to-be landscape (as we’re going to talk about in a couple of seconds) so that you have a full picture of what you’re going to talk about. The third thing is, of course, is you want to start talking, if possible, involving as you’re making this business people who own strategy, who own the parts of the strategy. And oftentimes you’ll find strategy owners in specialist teams or business units that are focused on delivering a specific capability. They’ll have a strategy ownership role. And if you’re going to touch on that capability, if you’re going to help them prove it, you need to have both their buy-in (so maybe you present them with a partially created case) and their insight to say “hey, listen here is where this capability actually is struggling.” And so they put their name on the page. So when you end up presenting it, the sort of the fourth level of a business case is presenting it to your key stakeholders in management. People who hold the purse strings. So you should involve them. And remember, when you present your business case, you’re not presenting it once, ever. That would be crazy. This is intended to be iterative, so the first time you present it, maybe it gets sent back, it says, “listen, there isn’t enough here”, or “we need more details on this.” So involve your management collaboratively. OK folks. Maybe this wasn’t working for you. Where am I struggling? How should I improve? What would you need to see to make this business case compelling? Great. If you can get some feedback – usually it’s in the form of some written feedback, or maybe you have a session with them where you’re standing up in front of the room and presenting and they give you questions and they sort of test and improve your business case. Great, take that feedback, develop using it, because now you’ve got all you need. They just told you what they wanted. So you use them, and that’s how you make the best and most watertight business case.

Roland: Yeah, and just to have it said, when we’re talking about management, we’re not talking about your IT department that needs to approve the acquisition of boxes and cables. We’re actually talking about the business units, the people who should get the benefits of what you’re doing here. But J-M, we’re at the end of our second segment. So what I would love to do for our listeners now is to send you in the second break of our little show here. And I would love to have you think about how you created business cases in the past. Did you create business cases in the past or was it a napkin that your best buddy signed upon? What was included in those business cases and how did they get approved or died on the vine? We’ll leave you alone for a couple of seconds and we’ll come back with the third segment of our show.

Musical Interlude: “RakeBeatChords”, Jeremy Voltz

J-M: Alright, that was a great little moment to think about your successes and struggles in the past with creating business cases. But now we’ve come to our third section. We usually call it the meaning / the value / the example. We’re going to sort of go into the practicality and walk through (and I think we’ll have another graphic as an example) of how to build a business case, particularly in the context of a value proposition. So Roland, let’s start over here with the process of creating a business case. Walk me through how you do it as an example.

Roland: Well, first of all, creating a business case is not, in most cases, a one-man or one-woman show. It involves the team, which first and foremost means it’s a coordination effort. We spoke about which people should be involved, in the previous segment, which is great, right? But then you’re looking at things like a timeline. Is that person available or do I need to go to the other person and ask them? We also need to think about the components of my business case. What do I actually have to create? And then you assign obviously those people that you just identified to those components. Let’s say we’re talking about qualitative measures and you’re talking about, for example, the qualitative outcome of using a certain tool in the context of an SAP implementation. You might need some extra expertise to get to the details of what’s being described. So that means you have more time to plan for it. And then the last part of that process is obviously you need to make sure that these components are connected correctly. And that means, on the one hand, from the story’s perspective, does it flow? But it also means, from an editorial perspective, do we write with the same language? And my recommendation for that is to have individual contributors contribute their parts. If you’re the project manager for that business case, obviously read through it while it’s being created, but at some point in time when the individuals have given their input, take it away and have one (maximum two) people to the final edits. Because what you want is to have a single voice that talks and describes the business case to the audience.

J-M: One of the really important things to think about is the business case in the context of the value proposition. I know that we talked about business cases as quantifiable and unquantifiable. So there’s a value statement that you’re going to put in there. But it does fit into the life cycle of a value proposition. That’s something you will create overall to make that case and to bring all that context into the business case as you present it. So this is going to fit into it. And there are really six components to a value proposition that I see, and we’re going to talk about each of them in a moment in detail. But laying them out, it’s to catch your business initiatives, your as-is landscape, the obstacles, your to-be landscape, the enablers, and the business case itself that emerges from those five. So let’s walk through them one at a time. We’ve talked about this a little bit, but if you take this as a guide for you, as you’re thinking about the information you might need to capture should you want to make a change, let’s talk about the first one first. So ‘business initiatives’ is going to be talking at that strategy level we spoke about before. What am I doing today in this organization to change for the better? What are the initiatives? What are my goals? What are my strategic statements and mandates? And essentially, what is the business attempting to do to achieve its ideal state or a better state?

Roland: That is one part of it, but it’s also, what do you have currently going on? Because J-M, you might have the greatest idea of the world, but that is the complete opposite of what you’re currently implementing exactly. So the logical sense (if you are able to convince everybody that your idea is the better one) would be to stop the running project. I’m pretty sure you won’t make so many friends.

J-M: Well, that’s when you have a lot more costs tossed in your business case because you’re gonna have to kill a running project that’s already just going to be a sunk cost.

Roland: Yeah, but if you’re doing the wrong thing, and then you don’t do the wrong thing, it might be worth sinking that money in.

J-M: Yeah, one of the quantifiable benefits of a really good architecture and IT program portfolio management tool is to avoid the cost of doing bad projects. But that’s a separate conversation. So the next thing you’re going to do is capture your as-is landscape. So what technologies, what processes, what people do you have in place today that you are attempting to use to achieve your business initiatives? And when I say “attempting to use”, of course, that belies the fact that I’m going to say the next word, which is ‘obstacles’. Because in some way, the way you do things right now / what you have right now needs to not properly satisfy your business initiatives. That’s going to go into one of the tips we have later, but if things are working well, you shouldn’t try and focus your efforts on improvement of those things that are working well, because they’ll be a lot harder to justify. Because your as-is landscape is achieving your business initiatives. Find out where you have obstacles to your success.

Roland: And don’t forget that landscape does not necessarily mean just people, process and technology. The example that we had before on the topic of risk management, intangible things comes in here as well. So don’t forget, for example, your risk people. Have a look, as you should, at your architecture. How is it structured? What views do you have? And then when you create the business case, go through each view and say, “is that relevant for my business case?” Yes/No? And if it isn’t right, don’t take it, but do that sanity check and say “oh yeah, there’s that one thing, like risks or projects, I need to take that into consideration.”

J-M: Yeah, and that leads me to this idea of the to-be landscape. So what you’re going to say is “today we’re doing something. It does not allow us to achieve our business initiatives. Tomorrow, here is what our company would look like to allow us to achieve our business initiatives.” And that to-be landscape, as Roland said, it’s views, it’s content, it’s people, it’s process, it’s technology, but it’s also just a lot of other components that go into what the to-be is.

Roland: And don’t forget, ‘to-be” – I’m not a big fan of that term. I love to use the term ‘transition states’ because there’s so many dependencies. To stick with the example of the running projects, maybe you have to wait for the result of the running project before you can go into another. So does that mean you don’t start your project until they’re done? Waterfall-ish? Or does that mean you have different transition states? So you do a little improvement in your first phase, and then when the other project is done, then you go into the next phase and reap the full benefit. So ‘transition states’ are also obviously a key factor in your to-be thinking.

J-M: Absolutely. And when you’re looking at those transition states, let’s call them that. Let’s talk about what they specifically enable. So what does this change? Because remember, we talked about the obstacles, so we really should be pairing the obstacles we see with some of the enablers that we’re making with this to-be state or the transition state. Don’t try and solve everything, though. That’s another tip, trick and best practice. Don’t try and solve everything all at once. Those Big Bang approaches tend to fall very flat. But your enabler should cross some of those things off your hit list from the obstacles.

Roland: And most importantly when you combine it with transition states right, you need to be able to articulate what is the value that you create by putting those enablers in place by transition state. Because that might have a big impact on your plan. If the purse holder says, “well, I should pay you X for that infrastructure”, and he says, “but I don’t get anything from it”. You might shift your approach in a way that you create the value that this person wants to see earlier. And obviously, since resources are limited, other things go to the back of the list, but that is also very important. Not just take it as a flat list, but also have some prioritization. Have some time aspect on those things, because that allows you to articulate the value.

J-M: Absolutely, and so then what we’re doing is we’re taking that enabler crossing off the list of our obstacles, tying it to the business initiatives, taking all the costs associated with this, and we are assembling all of that into the business case that we will be presenting. What is the financial impact of change? What are the unquantifiable benefits of change and listing those and the costs of change? Listing all those out in that business case and presenting it back to the people who control the business initiatives. And that’s the cycle over and over and over again. And once again, it can be iterative. We’ve seen (Roland, I’m sure, the same as I) many times where we present the business case back to the business initiative owners and they say “your obstacles are incomplete or incorrect”, or “we have a different view of things”, and maybe your enablers that are hitting those obstacles, “they’re not crossing things off our list. They’re crossing things off your list and our list is the one that has the money, so maybe you should come back.”

Roland: Or your stakeholders smelled blood, you know. And I had that in one project where we were developing not only a new system but also a redefinition of a business scenario and product offering that we wanted to go to market with. And we said, “OK, we’re going to deliver it in these transition states.” And we were happily working on it, and it was eleven countries in that organization that we were working for and we said, “OK, this is what we’re going to do.” And then our sponsor came completely out of the blue (while we’re still in transition state one) and said “when can I roll this out to the other countries?” And we said “no, we’re going to do that for the first three, because those are the most important. And then the most mature and whatnot, and the others have to wait.” And he was not happy with that. So that was obviously a failure in communication. A failure in expectation management.

J-M: Yeah, and I think that’s one of the tips and tricks we can take forward, Roland. Never forget that you are presenting business cases to human beings and humans are flawed, and humans have bias, and humans are selfish at times. Humans have the desire for recognition and acknowledgement and glory, and sometimes the business case you’re presenting needs to have a human aspect to it. Understand what this person wants – maybe they don’t want an optimized company. What they want is for them to look like they’re making good changes. OK, so let’s bend it to them.

Roland: Yeah, and maybe some people have some issues with reading project plans, but that’s a different story.

J-M: So now we’re in the tips and tricks section. And one of the things we talked about earlier that I want to hit on very hard is the unquantifiable benefits. I can’t stress this more. I can’t reinforce this to you enough, friends. The unquantifiable benefits of change, well, they might be harder to justify; never forget that they’re so important. And this is particularly important in what we talked about earlier – employee engagement. If you have bad processes and bad technology, people are going to find companies to work at that have better technology and better processes. And I’ve had friends and colleagues I’ve worked with and people and companies that I’ve worked with who have said to me, “listen. I don’t know where I’m going next, but I can’t stay here.” And I’m like “that’s crazy.” In one of my clients, I was talking to somebody that was leaving the job and I said “listen, you’ve been pretty successful – why are you leaving?”. And he said “well, yeah, but I hate it. I hate what I’m doing right now, not just the job. I hate the fact that the company that I’m working at is still using technology from 10 years ago and the processes are so outdated and I have to do all these work arounds and I can’t fix it.” And that kind of hopelessness is letting people walk out the door, and you think about the great resignation it really is. A lot of people aren’t going to come back, and so if you can make your organization work better, that’s a massive, unquantifiable, but very real benefit to what you can do.

Roland: Yeah, and that’s the next tip. Speaking of the unquantifiable, when you come up with your objectives and what you put in your business plan, avoid the ‘nice-to-have’. Focus on what’s really important, or in architecture or speak, look at the capabilities that you wanna build up. Is the thing that you propose to do really needed for it, or is it nice to have? So have a clear perspective / line of sight to the objectives that you’ve laid out in the beginning, that you might have been dictated by your organization. You need to do this in this, or you need to accomplish this and this and this. And focus first and foremost on these things. Try to avoid the ‘nice-to-have’ – oh, my office needs to be painted and whatnot, which is nice to have, but that might not be mission critical. You’d rather they take the money that you save by not having the nice-to-haves and invest it into the next initiative that you have.

J-M: And that’s actually kind of a touch point for this whole process, because I think that this brings it around really nicely to a conclusion. It’s really important for businesses to recognize what’s valuable in change. The business needs to recognize that value, and to do that, there needs to be a value to that thing, to the business. And it feels weird to say that. But the truth is that if you can’t justify your change with an effective business case, then you really shouldn’t be making that change, even if you really want it.

Roland: Yeah, and to stick with the example that I just mentioned, that large project that I worked on there were people within our own IT organization, they articulated where we have that hidden agenda. We want to migrate every project, every organization or org unit in our firm. We want to migrate them to a certain stack of technology. That was completely not part of the business case that we had. And that was a ‘nice-to-have’. Of course it would be nice to have for them if everything was standardized and whatnot, but they never thought about if it was what the business folks wanted. And in the end it was more a stumbling block that we had because we had to overcome this, then it was a help.

J-M: Roland, I think that’s an excellent cap-off to the episode. And back to you friends. I want you to take a couple of moments as we leave you with one more music break to think about an idea you have for process, architecture or structure or whatever in your organization. How does that align with the example we brought up of a value proposition and a business case? What business initiative does this fit into? How does it change things for the better in the organization? How do you do it today? How will you make it better? And what value will that change specifically give the business? We’ll leave you for a moment and come back with our final thoughts, conclusions, and the end of the episode.

Musical Interlude: “Wurly”, Jeremy Voltz

Roland: Welcome back. I hope you enjoyed Jeremy’s wonderful music, and we’re coming to the end of the show. So, just to do a little summary of what we spoke about, so we in our first segment spoke about OK, what’s the need for a business case? Why should you have it? And we put it into the circle of change / the life cycle of change. And also spoke about the high level things you’re doing. And then we moved on to actually what is in your business case. What information do you need? How do you articulate quantified benefits / unquantified benefits, costs and who should you involve in it? And then we closed out the show with a process, and like J-M said, I will put graphics into the show notes, with the process of how to create the business case. The six pillars of the value proposition.

J-M: Wow, that’s a good summary Roland, and thank you so much. I had a lot of fun chatting with you today! And you know what, I’d have even more fun chatting with… our wonderful audience. And thank you to everyone here for listening and loving and sharing What’s Your Baseline with everyone else. Please continue to like, subscribe, share – all the good things on all of your podcatchers and things like that. And you know you can find tons more information at whatsyourbaseline.com or for this episode specifically at whatsyourbaseline.com/episode23. Well, for now I’ve been J-M Erlendson.

Roland: And I’m Roland Woldt.

J-M: And we’ll see you in the next one.