DevOps Application Release and Deploy for Managers: Returns from Making the ROI Case
Peter Spung 270002C3XF Visits (12872)
[Note: This is the fifth blog post in a series intended to collect, discuss and refine the emerging management practices and guidance in the fast growing DevOps application release and deploy segment. The previous post is here. Blog edited.4]
“All I want to do is buy a business outcome. I want to invest in an IT project, and have it pay back. Unfortunately for many application development (or other types of IT) projects, that pay back is illusory, and ROI difficult to measure.”
-- Jane or John Executive, representing nearly every IT executive or CFO I have ever met
Unfortunately many struggle to quantify the financial return on investing in IT projects; those focused on DevOps Deploy are no exception. This doesn’t have to be the case. For automating application deployment or release management, the Return on Investment, or ROI, is easily described and straightforward to calculate. Before getting to the punch line of the bottom line, I’ll take a step back and set some context…
In my previous two blog posts here and here, the payoffs to implementing DevOps application release management and deployment automation were described using several client examples. IT organizations typically evaluate implementation decisions about whether to proceed with a project using ROI. ROI can be a complicated topic1; here we’ll take it simply and conceptually which is all that's required for DevOps Deploy. Then, we'll dig in to the line items and calculations of returns clients typically use. Based on your comments to this post, we can go deeper wherever needed. My next blog post will cover investments.
The payoff to implementing a project, or its monetary pay back, is the return. The cost and expense to implement something is the investment. So the ROI is how much will be paid back on the investment minus its cost. In other words, it is the return less the investment. It is typically bounded to a time period: an expected ROI by a forecast date for example, or over an agreed period of time. Implementing DevOps generally, or application release and deploy specifically, has a cost which will be explored in the next blog post.
Before taking on additional cost or expense, organization leaders want to know why – what is the purpose? (See the 2nd blog post in this series for more on that subject.) They also want to know if it will pay back; and if so, how much, and how quickly. All of those figures need to be “monetized” -- described in dollars or local currency, and include other factors that effect costs or returns1. If taking on additional cost has a positive payoff, often it may be reframed as an “investment” by the CIO or CFO. Another attribute of an investment is that it persists over time. Either there is ongoing cost or expense, or ongoing payback or return, or both. This is the “meat” of ROI discussions with senior managers who lead organizations sponsoring or implementing DevOps projects. They want to understand the period returns over time, the period investments and ongoing expense, and associated underlying assumptions and risks. This is the essence of an ROI business case for an IT project.
So how do you make an ROI case to senior managers and executives? Your goal is to convince them that implementing a release management or deployment automation solution is worth it. My client and personal experience suggests an open discussion about the investments and returns is critical. Investments and returns have perceived risks, uncertainties, underlying assumptions, priorities, and prior organizational & personal experiences when viewed through the eyes of senior managers. By discussing these openly and eliciting input & requirements from organization leaders and other stakeholders, you can begin to understand what will “make the case” and convince them to go forward. Some view the organizational and culture change is a key element; others the technology solution; others the change in process and related roles, responsibilities, workflow, or the related IT SOPs / Ops “run books”; still others the improved operational or software delivery performance. You won’t know until you ask – forewarned is forearmed, as they say.
To manage faster releases and application deployments, you must automate. Adding more people typically introduces more communication and coordination overhead, actually slowing delivery throughput (as Fred Brooks so aptly described in his enduring classic, The
High performing organizations deploy code 30 times more frequently than their lower performing counterparts, and more frequent app deployments are one of the primary drivers of pursuing DevOps (see
Thus far we have factored in the efficiency gains from automation, and the gains from avoiding rework from errors, rollbacks, and critical situations. Studies have shown that a 6-month delay in release to market can reduce by 33% the lifecycle profits from a new product or service; in economics this is called the opportunity cost of the delay. A one-month delay can hit the bottom line 5-10%. These are broad industry averages. You should be able to fine tune these to the market in which your company competes, and for a particular customer facing application. The key question for this part of the calculation is, “How much are delays costing you in the market?” There is additional revenue opportunity that flows to the bottom line from reducing the economic impact of delays, which enhances the revenue opportunity. You can see this enhanced revenue fine tuned for a typical client ROI case in the table of Speed Factors.
If this seems complicated, that’s my fault for trying to be thorough in explaining and showing you everything at once. It’s not complicated at all, and we have additional tools, information, and people to assist you!
The first resource is an ROI calculator, a guided dialog on our web site. You’ll receive a complete ROI report after answering some key questions about the factors illustrated above. When you sum up the returns from automating manual processes, reducing rework, and reducing delays to market, you’ll likely be amazed at the summary of benefits, as illustrated here:
An additional resource is our ROI whitepaper, which describes in text a comparable approach to the ROI calculator web site. This allows you to do it yourself when crafting the various line items, assumptions and calculations -- essentially rolling your own ROI report. It will be more work than using the ROI
You can take
Finally, we have people who can work directly with you face to face. For example, we have a workshop during which we assess your current as-is and desired to-be state for DevOps application release management and deployment automation (or broader DevOps initiatives or aspirations). We suggest a roadmap to improved outcomes, and calculate returns like these to help you make the business case to senior managers and executives. Also, when revi
The payoffs and monetized returns to DevOps application release management and deployment automation should now be clear. If not, please comment on this blog. This information and my story telling only improves with your feedback. (Otherwise I would have written it better to begin with! ) Next, we’ll explore making the “I” or investment in ROI. The investments are the changes required in your people, process and tools that yield these compelling returns. Caveat: what comes next is all subject to your input and our interaction, of course. Please comment.
Peter Spung, Integration Executive, UrbanCode, IBM Rational Software. @paspung on twitter
2I'll explain the types of automation and how to lead automation in your organization in a future blog post. For a good introduction and overview with profound implications, see
4Made terms among ROI Factor tables consistent, and fixed arithmetic error. Added additional video to note 2.