Several years ago I was developing a business case for a DevOps transformation, when my company's CEO told me I needed to focus on the benefit to the business—not the technology. This has stuck with me over the years, and as DevOps has turned its focus toward culture over technology, his advice has proven correct. The technology is actually the easy part of a transformation.
Let's roll up our sleeves and build the business case you'll need to start your DevOps transformation.
Discovering business need
Transformation is really hard. This makes it essential that you can answer the following question in a clear and satisfying way: Why does your business need DevOps? If it's just because you want a particular tool or you prefer the DevOps culture, you're going to need more reasons to convince decision makers (unless you're the CEO and/or board chair, of course). You'll need to find and explain what's missing or lacking in the company today that DevOps can fix.
Here are a few signs that your company should consider transitioning to DevOps:
- Does it take a long time to deliver features?
- Are features underutilized?
- Do you not know the utilization of features?
- Do you have downtime during maintenance or deployment windows?
- Do your customers tell you your site is down before you know it?
- Do outages occur repeatedly for the same reason?
- Are customer feature requests implemented in a way that doesn't actually fulfill the customer's needs?
Notice none of these questions asks about change management burdens or operational inefficiencies. You probably see these every day, but that's not the problem the business sees. They see the customer losses, opportunity costs, and strategic impacts. In order to solve this problem, you also need to understand your company's strategy.
Your company strategy may be listed clearly in a document from the CEO or board. That's a good place to start, but it likely doesn't tell the whole story. You'll need to reach out to different business leaders and learn their strategy as well. I'm an extreme introvert, so if I can do it, you can too. People like talking about themselves and their ideas, so you won't even need to do a lot of talking. Invite them to lunch and ask them questions about their strategy so you can better understand their direction and the pain points they have today. You'll be adding these to the benefits section of your business case.
Once you have a better understanding of the overall company strategy, you've probably also figured out who is really making the decisions or who is influencing the decision maker. Here's a good list of areas you may not have thought of as decision makers or influencers. When crafting your business case, you'll want to highlight their issues as solved or mitigated. Assuming lunch went well, you'll also want to build that relationship and trust. Don't do this disingenuously, or it's likely to backfire.
Putting DevOps research to work
Now that we've gained more context and better understand the business problems, we can start gathering content related to how DevOps might solve them. There are several really good resources with data that can help sell this type of transformation. The best collection is from the DevOps Research & Assessment (DORA) team. Nicole Forsgren has led DORA's State of DevOps Report in partnership with Puppet Labs since 2014. DORA's research is open and published for anyone's benefit.
The 2017 State of DevOps Report contains a lot of valuable information that will likely interest executives. For example, high-performing teams were more than twice as likely to exceed their goals of profitability, market share, and productivity. They deploy 46 times more frequently. Their lead time for changes is 440 times faster than for low-performing teams. Their mean time to recover is 96 times faster. And they're one-fifth as likely to have a change fail. When we map these back to the business needs, we can begin bolstering our argument for why DevOps can help solve these business needs.
What if you could also give your company more time from employees? The study shows that high-performing teams spend 21% less time on rework and unplanned work and 44% more time on new work. That's like increasing your staff by almost half for free!
Another DORA research paper, DevOps ROI Whitepaper, contains even more information specifically about what you might want to include in a business case. It talks about not focusing solely on cost savings aspects of transformation. I wholly agree with this, and my former CEO also agreed. You'll want to focus your business case on the value-driven categories. This paper provides a great calculation to determine the value created by just saving time on rework:
(technical staff size) x (average salary) x (benefits multiplier) x (percentage of time spent on unnecessary rework) = Cost of unnecessary rework avoided per year
An example for a small company might be:
150 (technical staff) x $105,000 (average salary) x 1.5 (benefits multiplier) x 7% (rework for low performers) = $1.7M in annual savings
That's a massive savings in time alone. But what can this found time be spent on? New work! We can now calculate the value added back to the business.
(time recovered and reinvested in new features) x (revenue-generating features) = Potential revenue from reinvestment
First, we need to discover how to calculate revenue-generating features:
(frequency of experiments per line of business) x (lines of business in the organization) x (idea success rate) x (idea impact) x (product business size) = Revenue-generating features
Here's an example using the same small company from before:
7% (time recovered) x 2 (experiments/year) x 3 (lines of business) x ⅓ (success rate) x 1% (impact) x $100M (product business) = $140K return
The document walks through some additional calculations to determine the expected ROI and the expected payback period that will be helpful to include in your business case.
Another great resource is Carnegie Mellon's SEI Insights blog. It has quite a few articles on DevOps, and it is a known quantity among executives. One article discusses how DevOps can reduce deployment risks, thus increasing agility. It also discusses compliance concerns, which are critical to understand when presenting transformation within regulated entities. Another SEI Insights article points out that security has become a top business priority and represents real business value. This will be important to document—and in today's environment, this can be all you need to get buy-in. You'll want the chief security executive to be on your side first, though.
Now that you have a strong business case, you can revise it by surveying your associates. The previous calculations rely on you having already accurately assessed your company's current state. It's best to invest a little money upfront to perform a survey so your numbers will be more accurate. You can also save some money by doing a more informal survey on your own. The goal is to determine your company's current level of performance.
Finding partners to prove success
Now that you've developed an impressive business case with lots of numbers describing how you'll save the company a bunch of money and provide more time for innovation, you need to prove it. Your company will likely have a specific methodology it follows, and it's impossible to cover all of those variances in a single article. No matter what your company's process, you will need to prove success before the company decides it was the wrong investment. In my experience, this is between three and six months.
To do this, you will need to find a team ready for change. Remember all those lunches you had? Who was the person most excited? Who has kept in touch with you? That's probably a good candidate. You'll want to work with them to ensure you have time on their schedule. This is also a great time to use free and open source software (FOSS) and cloud environments, as you'll want to keep your costs low and your agility high.
Implement small changes and measure their effects on the team and the product. As the team evolves, you should be able to see the benefits described in your business case. It's best to prove out as many of the metrics in your business case as possible. You'll then want to present this data.
You should follow up regularly with the executive sponsor who approved the business case. These can be informal meetings, but they need to convey the wins and keep the sponsor positive. Meeting with the sponsor's superior is also a good way for you and your sponsor to promote the good work being done.
Of course, this isn't just about changing a single team. You'll also want to schedule regular meetings with others in the company. I often leave these as open invitation meetings where everyone is welcome, and we record them for sharing later. Use as many avenues as possible to spread the word. You can't over-communicate success.
Now that you have one team proving out your business case, you're well on your way to executing on the business case for the entire company. You'll want to repeat these steps and move incrementally as you take your transformation to every part of the company.
Comments are closed.