Building a DevOps platform business case

Lauri (00:00):

Hello, and welcome to DevOps sauna. My name is Lauri and I am the Chief Marketing Officer of Eficode. Today, we are talking about business case, in particular, building a business case for the DevOps platform. You as an IT or software development professional, you must have been in a situation where you have made a technology review and you are delightfully convinced about the technology and the benefits it could bring for your team. But once you start making the business case for it, you may run into a predicament, and that is how to convert the value that is, so obvious to you into numbers and specifically the numbers for somebody else that is going to make the financial decision for you.

Lauri (00:50):

When it comes to investing in a DevOps platform, it is not only that you should understand yourself how this investment is generating value, but you also need to be able to explain the value of the DevOps platform and the software development tool chain to somebody who doesn't know a thing about DevOps. But unfortunately for you, they are the ones that hold the key to the gold treasure vault. The challenge here in particular is that when organizations have multiple projects they could finance, it is not only sufficient to explain to your higher ups, what benefits would this investment bring and how much would this be worth. In order to wrap them around your little finger, you also have to be able to argue that your investment is a better investment than somebody else's. And it is likely that you know very little or nothing about the other options that your decision makers have on the table.

Lauri (01:58):

In these cases, it helps you understand how your decision makers, how your financial audience think. And as the organists say, which stops you need to pull to loosen the purse strings. The good thing is that investment decisions can be made a little comparable and whoever has the money can look at the options without needing to know the dirty details. I am letting you in on a secret to learn how your decision maker thinks about investments and how you should build your story to talk their language. First, I'm going to explain to you the four important factors in layman terms. Second, I'm going to unpack the DevOps platform financial impact to different metrics. And finally, I'm going to talk to you about what's to expect from a business case calculator to do all this easily. The business case model that I am explaining has been built for and based on our experience with ethical route DevOps platform, but the logic applies practically with all DevOps platforms.

Lauri (03:15):

So let's start by looking how your financial decision makers think. I am going to leave a lot of uninteresting details out of this, but everything I say is bread and butter for your decision maker. And that's a good thing. When you adopt this view and you use these terms, you come across as somebody who has done your homework. So let's start with the question, how does this investment compare against other alternatives? I have €1000 and I have to make a choice where should I put the money? That's the question that your financial decision maker is thinking. And they are looking at practically four factors. The first term is net present value. And you don't have to remember this term. What is important is you remember, and you realize how the thinking is behind what's called NPV.

Lauri (04:09):

The logic with net present value is that you take all the costs and all the benefits over the period of the business case. And then you estimate how much this investment would be worth if it all happened here and now on this very day, instead of let's say over a period of three years or four years, because €1 spent today carries a different value than €1 spent tomorrow or €1 spent one year from here. So that's why it's important that you pull up all the costs and benefits, and then you value them on today's money. The second metric for your financial decision maker is called payback time. Payback time is simply how long does it take for them to recover the amount of money that they have invested before that investment begins to generate profit or net savings.

Lauri (05:10):

The third one is called return of investment, which is simply if you invest €1, how many Euros you're going to get back? And finally, the fourth metric sensitivity, which basically tries to estimate how well the business case have been constructed, how well you have been able to estimate all costs and all of the benefits, and how would this business case change if there was, let's say a 10% increase or decrease in costs, or if there was a 10% increase or decrease in benefits. So with the sensitivity analysis, you will be able to evaluate the impact of imprecise factors in the business case, and look at would it still make sense even if we didn't deliver as much savings or as much profit as anticipated. So that's to put simply how your financial decision maker thinks.

Lauri (06:10):

So let's look at the categories of benefits. So you, of course, somebody who puts together a business case needs to think, how do these metrics and categories match up with DevOps? What should you be looking at in DevOps to evaluate net percent value or return of investment or payback time? We look at this through four different categories of benefits. The first category is to be able to reduce nonproductive time of software development personnel, and also improve development productivity. So what does this mean?

Lauri (06:52):

When you think of software development experts, they spend their precious time on maintaining and tinkering with individual solutions in the tool chain. This is not their primary job. Their primary job is to develop new features that sell more or payback technical debt. But because they happen to be good at some of this offer development tools, they end up in an acting role as an IT specialist. And this is an opportunity cost for getting more and better software done, and it may result in disruptions if the software development pipeline is used by multiple people and for a reason or another, this one person is not available to maintain a particular tool in the tool chain.

Lauri (07:40):

When you adopt a DevOps platform, the DevOps platform will be always available and up to date because your provider offers you a serviceable agreement according to which they will operate. Those up-to-date software development tools enable successful and on-time builds, tests and deployments. And because requirements become deployable more quickly, your teams deliver more features and address more technical debt in the same time. So in other words, you will reduce the downtime in your development tool chain, and you will remove ancillary work from your developers table.

Lauri (08:20):

The second category is transitioning to higher value in work and improving cycle time. What is cycle time? I would like to use Nicole Forsgren's definition from the book Accelerate. The time from code starting to be worked on by development, to code in a deployable state. Now that you have people who have been dedicated to maintaining and improving the software development tool chains, these people are like main chefs and bottle washers. So they do anything and everything, and they don't always have time to focus on their code as we discussed.

Lauri (08:58):

But there's also the other aspect is that you have dedicated people who have been assigned to maintain and improving the development tool chain. Now that they will be able to focus on improving automation, looking at the higher level of the DevOps platform, they will offer more opportunities for other people to be ready on time or ahead of time. So in other words, because of time spent maintaining tools is reduced, people focus on improving automation and fewer of them are required, which is a good thing for you because then you can offer people work that they love.

Lauri (09:41):

The third category is accelerating revenue from software. So up until now, we have been talking about benefits that are measured based on peoples' salaries. The lead time, however, is based on the value of your code. And again, according to Nicole Forsgren's definition, lead time is the time that it takes to go from a customer, making a request to the request being satisfied. So why would lead time behave differently than cycle time? And I'm not going to digress on this too much, but let me just say that your software development function exists for the purposes of creating new features and paying back technical debt. And they wouldn't do that unless that would add into revenues, or it would optimize your cost base.

Lauri (10:32):

So now you could say that because your deployable code reaches your customers faster, you will be able to generate that revenue from that new software faster than anticipated. I would encourage you to look at the first question, which is the value of your software development function, which is the value of an individual release, and how much would it be able to recover or accelerate revenue generation if you accelerated your deployment, let's say by one day?

Lauri (11:04):

Finally, we come to the last category, which is ability to recover from disruptions more quickly, which is mean time to recovery. I agree that it feels terrible when production is down, but imagine how terrible it feels when the production is down and the software development pipeline that you plan on using to fix the glitch that brought the production down is down as well. Generally in the DevOps world when you ask a question, how to improve your mean time to recovery, the general answer is shift left. And here we should say the same, but we should also say that you get immediate value by always having a DevOps platform available. And if you have a glitch to fix it is there for you and you don't have to spend your time fixing your development environment first, but you can go right on to the problem and deploy a change before you thought.

Lauri (12:11):

That is very much the recipe for building a business case for a DevOps platform. So what should you expect from the tools you use to build the business case? So first, the tools that you use need to connect the facts about your organization in the DevOps metrics. That's the only way for you to evaluate the business case reliably to your organization and not just some aggregate organization. So examples of these facts are fully-loaded salary costs off an individual software developer, the total revenue of your company, or the value that your company is expecting to generate from its software R&D function, your current DevOps metrics, such as cycle time, lead time, or a mean time to recover.

Lauri (13:05):

What's more, it's not only enough to capture these facts, but more importantly, to model the relationship between different inputs to these metrics. Building investment proposal isn't easy. Building an investment proposal calculator is harder by an order of magnitude. And I would advise against trying to build an investment proposal calculator yourself. Oftentimes one R&D software or ops person builds business case only every so often, where we as a solution provider, we build business cases all the time. Well, I have no means of proving you, but it takes a lot of cases before the model has been asset tested.

Lauri (13:55):

The good thing is we have this model. The business case calculator that we have models your development teams through your DevOps metrics and estimates your savings potential, revenue impact, as well as costs involved in making the investments. It then presents that business case in the three metrics we discussed, net present value, return of investment and payback time. And finally allows you to evaluate the sensitivity of net present value given how accurately you have been able to estimate your benefits and costs.

Lauri (14:33):

I would like to invite you and your business to a business value workshop, where you can experience all of this yourself. We discuss through all of these and much more, and we build a personalized business case based on your company's situation and characteristics. I should also say, we offer a free calculator at our website that allows you to estimate your business case for the DevOps platform, with as little as seven metrics, your company revenue, number of software development personnel, current downtime per month in a software development tool chain, a number of tool chain specialists if it's measured as a full-time equivalent working time, current cycle time, current lead time, and current number and length of unplanned outages of your software production. Out of this calculator, you will get a full-fledged calculation that is based on estimates, built on our experience with other customers. And we can use that as a basis when we start refining those numbers with you later in the business value workshop.

Lauri (15:40):

So let's wrap up. You need to be able to quantify your business case to financially-savvy people using their own jargon so that they can compare your business case with other business cases they have in front of them. They are going to use net present value, return of investment, payback time, and sensitivity to evaluate your business case. And the business case for a DevOps platform is based on productivity improvements in your R&D team, the elevation of abstraction level of work for tool chain and automation specialists, the acceleration of cycle time and lead time, and the mitigation of frequency and recovery time on unplanned outages. And that's pretty much it.