How to Make a Strategic, Value-Driven Business Case for Your DevOps Initiative
Did you ever hear the story about the organisation that continued to meet their customers’ expectations and then went under? No? Me neither.
DevOps is a way of enabling enterprises to keep pace with change and continue to meet customer expectations and deliver business value. The business case for DevOps is utterly compelling; all the more reason why any DevOps initiative needs to be articulated in a way that means it will get approved.
There are many articles and blogs out there that describe the ‘business benefits’ of DevOps, but these typically are written from a largely technological view of the ‘business benefits’. However, the business case is at the intersection of strategy and operations. It should lay out a tangible way forward for a project or programme to achieve one or more strategic objectives. DevOps business cases that focus on tactical (technical) achievements rather than attaining the strategic enterprise objective will not fare as well as those that focus on business or customer value. The technical achievements of a DevOps project or programme is of course important, but as we deconstruct and rebuild the business case in subsequent paragraphs, you will see the value of focusing on strategic enterprise objectives and delivering value to the business and customer.
In this article, I will give the business view of the DevOps business case as someone that has been involved in the writing, reviewing and approving of business cases.
I’ll cover the following in some depth:
- Preparing the business case
- What is business value?
- What is a (good!) business case?
- Are you aiming for change or transformation?
- Where does the board come in?
- Writing the business case
- Basics
- Identifying problems
- Numbers and statistics
- Key considerations
- Metrics
- Cost
- People
Preparing the Business Case
What Is ‘Business Value’?
I will refer frequently throughout the remainder of this article to the elusive ‘business value’, so it is worth qualifying what it means.
Business value might be qualified as a net positive return on investment (ROI) where we divide net profit by investment. Whilst this is fine in principle, it is a little overly simplistic and outdated. However, a large number of enterprises still qualify business value in this way. What is missed by a simple calculation of ROI is that the time required to recognise the increased cash flow is not factored in to the calculation and the fit of the proposed initiative with the broader enterprise strategy is not considered.
Unfortunately, business value is not a straightforward concept and it does not have universal applicability. Business value, like the business case itself is open to interpretation by individual enterprises depending on their particular strategic objectives, capabilities and constraints.
That said, for the purpose of this article and for making the link between business value and DevOps, business value will be understood as:
- Increased speed to realising cash flow for technology products and services
- A source of competitive advantage in the age of the ‘application economy’
As a final thought on the concept of business value: given that there is not a consistent definition, it may be considered a straightforward solution to ask ‘the business’ to define how they understand value. Alas, this is unlikely to yield the outcome hoped for. Understanding how business value is measured and how it is delivered do not necessarily follow on from each other. This means that the most important job of your DevOps business case is to communicate how your proposed initiative will deliver value to your business.
What Is a Business Case?
I think most of us would be comfortable with the concept of a business case. But it should be noted that within the term ‘business case’ is loaded with an enormous amount of situational context. Put simply, organisations have different interpretations of what a business case means to them. The content mandated and the process then followed can vary significantly. One organisation (a large retail bank) had nine approval ‘gates’ to walk through even before the case could be submitted. Another organisation mandated that the business case qualify the effect on society and the environment, which my team and I were not prepared for. We had to start again and lost a great deal of time and momentum.
The first step in producing a business case is to understand the process that your business case would need to follow and any content that is mandated (including supporting documentation). Getting rejected for not following a process is incredibly frustrating.
The Goal of a Business Case
90% of organisations state that the main purpose of the business case is to secure the project budget. This seems reasonable, but it ignores the competitive necessity of a business case. When looked at through the lens of funding, the real purpose is to secure budget over another request for funding. The business case landscape is competitive. Organisations have limited funds and resources and are required to control their spending (this includes internal investment). The result of this is that your DevOps business case should explain the reason why your initiative should be funded over others. This competitive landscape has a tendency to promote negative behaviours, with c. 40% of organisations openly admitting that they overstate their purported benefits to obtain funding. This short-termism is particularly dangerous to long term enterprise profitability and stability and in my view, is completely irresponsible. It also encourages a focus on the wrong question. The objective is to outline how your idea will improve the enterprise. Funding should be a secondary consideration.
Why Produce a Business Case?
To answer this question, we need to examine the finance process.
The simple answer is: because you must produce a business case to get investment for your DevOps initiative! That’s how it works. Yes, it’s bureaucratic and overly engineered. Accept you will need to traverse the bureaucracy to achieve your objective.
The expanded answer is as: IT shops are almost always thought of as cost-centres in enterprise IT. This means that their budgets are assigned to them via projects, normally in the following way:
IT portfolio directors are asked to accurately predict the projects that will be completed within their portfolios over the next twelve months (a Ouija board and magic wand are useful with this task). The portfolio managers are asked for a level of cost granularity that it is impossible to predict with any significant level of accuracy. Baked in to these plans is the enterprise vision and long term, strategic objectives. This prediction becomes even more complex when each separate component (development, testing, operations) of the IT function is embedded in its own cost centres and forces what should be co-operative, complementary services to compete further for limited resources.
The simple fact is that if you are required to complete a business case proposal, the initiative was not deemed to be a priority during the last funding cycle. Wily portfolio directors will normally keep a small allocation for new projects, but it is worth noting this is a small amount and will also be used as a ‘buffer’ in the event of project overspend. This is the reason for manic end of year spending, to ensure that budget cycles are not cut for the next year.
It is important to determine where the investment is likely to come from in advance of producing the business case. For a reasonably small change, funding may come from unallocated portfolio spend, but for something more significant, it’s likely that funding will come from a different (central) source altogether.
Are You Aiming for Change or Transformation?
When I work with clients to put together a strong, coherent business case, the question of whether the goal of the business case is ‘change’ or ‘transformation’ is one that we circle back on repeatedly. ‘Transformation’ is one of the most over and incorrectly used terms in the enterprise. It’s particularly significant for the business case: if a transformational endeavour is to be undertaken, multiple business units stand to affected and benefit.
Assuming your business case targets enterprise transformation, ensuring strong business sponsorship will have significant benefits. Business support can be obtained in advance of even submitting the business case. A DevOps transformation requires business change as well as change on the technical side, even if the main focus of the change is confined to the IT domain. A business sponsor who is willing to engage and support the endeavour is critical. It is also particularly useful to have a happy sponsor to champion the future initiative.
There is little doubt that DevOps in combination with public cloud that results in the ability to deploy continuously can be transformational for an enterprise. But it is not the capability that is transformational, it is how the capability is utilised by the enterprise to deliver business and customer value that determines whether the focus of the business case is transformation or change.
There is an entirely legitimate (albeit less compelling) business case for ‘we will build it and they will come’, but the objective of the DevOps business case is to demonstrate how the enterprise investment will result in increased value to both the business and customer. A business case of ‘to achieve the business objective, we need to invest in this…’ is far more potent than ‘we should do this because it is a good idea!’
A word of caution on the ‘build it and they will come’ business case: if an elegant Continuous Delivery pipeline that harmonizes Development and Operations and continually checks its own health by feeding back from production is approved, designed and built, what exactly has been accomplished? It depends on what business needs are pushed through that pipeline, and what business value results from that. DevOps is form without content until the question of what goes in the pipeline and what happens when the product emerges at the other end.
The engineering excellence of Amazon and Netflix is well documented and often the focus of envy for IT organisations the world over. However, it should be noted that the engineering excellence does not stand in isolation. I do of course, like most, use the Amazon app for the convenience. I like the way I can sign-in with my finger, find what I want quickly and easily and purchase with a single swipe. But would I continue to use it if I could no longer find what I wanted, at a price I was willing to pay and have it sent to me in timescales that were acceptable? Simply, no – I wouldn’t. The same with Netflix. I like the fact that I can use the service across devices and that it always works. Would I continue to pay my subscription if Netflix stopped be the single source of House of Cards? Definitely not! Engineering excellence is an enormous enabler of providing value to the customer, but it does not exist in isolation. It is important to keep this in mind when preparing a DevOps business case.
An additional, important consideration of whether your DevOps endeavour is a ‘change’ or ‘transformation’ initiative: a transformation will (and should) impact the business model. The impact of ‘disruption’ and digital technologies has had profound effects on organisations’ business models and is not the focus of this article. However, the effect of the proposed DevOps initiative on the business model should be qualified explicitly. That’s because changes will need to be communicated up the food-chain, potentially to the very top.
The Role of the Board
My personal belief is that the board get a rough time. They’re up against it! Executive and non-executive directors mostly acknowledge that the world is changing around them and that ultimately, the buck stops with them. They are also under a great deal of pressure: as Professor Richard Foster from Yale University estimated that in 2015 life expectancy of companies had dropped to 15 years, a 50-year decrease on what they had been in the 1920s. I don’t think anybody particularly wants to be at the helm when the iceberg is hit!
Why is the role of the board relevant? Well, assuming that your organisation has the ambition to outlive Richard Foster’s quite glum prediction above, it is likely that you have deduced correctly that a DevOps initiative will drive the innovation of your business model in terms of the way in which value is delivered, the key activities that are performed, the customer and market segments that the enterprise currently engages with and the impacts on cost and revenue. These changes (albeit positive changes) are something that the board is accountable for.
The board plays an important role in providing strategic oversight. The Organization for Economic Cooperation and Development (OECD) states that one of the primary responsibilities of the board is to “ensure the strategic guidance of the company”, but the manner in which they are expected to do it is less clear. Strategy development, and the subsequent operational programmes that are executed to achieve that, is the job of management. To discharge their responsibilities effectively, the board are required to verify that the business model (that you are proposing to amend) will translate into shareholder or stakeholder value. The board should evaluate proposed changes to the business model for logical consistency, realism of targets, and statistical evidence that the relationships between performance measures and stated goals are valid.
The size and complexity of the enterprise and the huge number of projects that are undertaken will likely mean that your business case will not make it to the level of the board that has ultimate accountability for the business model (although it could happen).
Responsibility for ensuring strategic programmes is normally devolved to investment boards or committees. These devolved board have responsibility (but not ultimate accountability) for ensuring the business model will create long-term value and meet the corporate strategy. It is therefore reasonable for questions to be asked along the lines of how the request for investment results in:
- Improved customer satisfaction?
- Repeat purchases/subscription renewals?
- Increased sales?
- What statistical (not anecdotal) evidence do you have? (Primary is better than secondary)
- What metrics will be produced to measure progress?
Along with the following questions:
These are all entirely reasonable questions, but in large enterprises, they can be extremely difficult to answer. Crucially, the IT function is not able to answer them all. The IT function must work in a collaborative manner with other enterprise functions (finance, sales, marketing) to be able to answer them. IT must lead the charge on this and act in the largely unfamiliar role of facilitator.
Those familiar with the DevOps vernacular will be familiar with the term ‘shift left’. Which refers to a practice in software development in which teams focus on quality, work on problem prevention instead of detection, and begin testing earlier than ever before. The goal is to increase quality, shorten lengthy test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle or, worse, in production. The principle of ‘shifting left’ is as valid for the business case as it is for software development. It means the questions detailed above should be answered during formulation of the business case.
It is particularly valuable to keep in mind that the ‘customer’ of your business case may be an individual or group of individuals outside the IT function. This should steer the tone and content of the business case. There will likely be a requirement to translate both the problem and the proposed solution to the problem in a digestible format for those who aren’t technical experts.
Writing the Business Case
Get the Basics Right!
In law, it is said that ‘an individual is innocent until proven guilty’. For a business case, you should assume that an idea ‘is a bad one until it is proven otherwise’. If you believe there is value in an enterprise DevOps initiative, it is your responsibility to convince others of that value. Too often, value is implied. I’ve witnessed a number of instances of terminal comments whilst participating in business case presentations. My favourites:
- “Come on! How can you not get this?” – because senior people (or people at all for that matter) love to be made to feel stupid.
- “You know the cost of everything and the value of nothing!”
Change programmes do not exist in a vacuum and it is important to understand the context in which your proposed initiative sits, both internal and external to the enterprise. I once worked with a large organisation that had six ‘digital transformation’ programmes all going on at the same time and no-one really knew what the difference between any of them really was. It is also important to look at the wider factors external to the enterprise and consider forces that (could) shape your business now and in the future.
Do You Know What Problem You’re Trying to Solve?
Focus on the customer segments. I actually start business cases with a focus on a customer problem, and it’s entirely reasonable to focus on internal customer segments as well as external. For example: a well-documented benefit of moving to a DevOps way of working is a reduction in cycle time. But is there benefit to reducing cycle time? You may target reducing the total time taken from the start of development through to release, which it would be hard to argue is not a reasonable thing to do. But this is where framing the problem is of vital importance. Is the cycle time actually too long now? See below for an example:
Fair
Good
We will reduce our cycle time by 40%
Our Product X cycle time is currently 4 weeks. Our competitors (A, B, C) are releasing in 5, 4 and 11 days respectively. We have seen sales of Product X decline by 9% over the last quarter, which has resulted in lost revenue of $XX.
Much like the tree that falls in the forest that may or may not make noise depending if there are people present to hear it – if an organisation reduces it’s Mean Time to Recover (MTTR) by 35% and there are no customers to benefit, does the MTTR actually reduce at all?
It should be noted that the example above works well if the problem is already known and defined. But what if the problem is not known yet by those who make the decision whether to approve your DevOps business case? In this situation, it will be necessary to do some analysis. Consider analysis of the list detailed below at the current point in time, in 1 year, 3 years and 5 years. It may not be necessary to do all three points in time, but you get the idea. The list of focus areas to forecast is as follows:
- Customer requirements (forecast market demand)
- The operating environment
- Your current solutions
- The solutions of competitors (industry competition)
- Your position in the market (perception and market share)
- Sources of competitive advantage
Completing the above is a time-consuming activity, but it should make a compelling case for investment if the problem that you are drawing attention to is not known or has not been defined.
There is quite obviously an investment to be made in the business case itself and there is very good reason for IT to be inclined to make the investment as business unit expenditure for external IT increases as business units grow increasingly impatient with enterprise IT’s inability to deliver value. Failure to make the appropriate time investment in your DevOps business case will almost certainly lead to failure to secure investment for your DevOps initiative.
Make a Simple, Succinct and Coherent Argument
Try to keep your business case to eight slides maximum. A 40 page, nuanced argument will just lose people. How will a DevOps initiative solve the problem that you have outlined at the start of your presentation? There is a simple strategy to determining the content: does this slide, this piece of the puzzle explicitly support my argument? If the answer is ‘no’, change the content or bin it! The kitchen sink approach can be particularly damaging. I’ve seen quotes from fictional TV characters, pictures of people’s dogs and all manner of things, somehow tenuously linked to the business case. They rarely have their intended effect.
The final element to watch out for is the role of the ‘story-teller’, some people when presenting their business case, shall we say, over estimate their skills as a story-teller, delivering what they believe to be a compelling tale of overcoming struggles and new found heroism. It can work and I’ve seen it work, but mostly…it doesn’t. Keep it simple, make your argument clearly explaining why the enterprise will benefit from investing in DevOps and use evidence to support your conclusion.
Do Your Homework: The Numbers!
As I wrote that headline, I mopped the sweat from my brow. Enterprise financial data is a minefield. Traversing it is time consuming, difficult and requires huge amounts of patience and skill. Without exception, every time I have either tried to quantify run costs or usage volume, I have had to unpick the black-box logic of a system that sits in an architecture that went live in 1984 with no documentation. The complexity is normally compounded by the fact that the one person who knows how it works is on holiday in the Bermuda for six weeks. Sound familiar?
Whilst working on a particular business case for public cloud investment for a large Financial Services organisation, to quantify the new cost of run, we had to forecast new usage volumes. We simply weren’t equipped in terms of the size of team or time to engage with individual business units (on a global scale) to produce the necessary application decommission roadmaps to complete the business case.
The business case, however was successful. How did we manage to do that under these circumstances? The important thing to do when engaging with a large and complex data set is determine what the data can tell you as early as possible. We used the available data to prove the following:
- The cost of running the global IT estate was increasing year on year and had been for the last five years
- Current investment to date had slowed the cost increase, but not stopped or reversed it
- A move to public cloud and a one-off usage volume and sustained reduction of 6% (flat usage volume) would see the organisation recoup the investment cost in four years.
Obviously, the above has some quite significant assumptions baked in, but the assumptions were deemed to be reasonable. Sharing the method we used enabled us to overcome the problem of not being able to qualify the exact return on investment (ROI). A common mistake that is made when producing a business case is that people use numbers to make the argument. My suggestion is to make the argument and use the numbers to support where possible. A further suggestion is to share the method you’re using to calculate your numbers with a friendly member of the finance function and to reconcile your final numbers with them. When producing the business case detailed above, our numbers were way off the first time – it turned out that we had missed off an entire continent (because their numbers were held in another system because of a poorly-integrated acquisition). It was important that we caught that before presenting the business case. Also, knowing that your numbers are as accurate as possible gives you (and everyone else) a huge confidence boost as to the validity of the business case.
The other reason, and far less tangible reason that the business case detailed above was successful was because it aligned broadly with the strategic themes the enterprise wanted to pursue. I like to talk (or write) tangibly about what a DevOps business case should aim to achieve, but a great business case must appeal to both the heart and the head!
Key Considerations
Get Some Numbers of Your Own
My colleague, Dan Williams, recently wrote about the benefit of lighthouse projects. I won’t recap on the benefits articulated in the article, but wanted to link their benefits to the business case. A lighthouse project should generate some tangible metrics for inclusion within your business case. I mentioned above, the benefit of engaging a business sponsor at the earliest opportunity. The choice of project is crucial to doing this:
To maximise the benefit of the lighthouse project, the metrics collected are absolutely critical. Selecting those metrics is easier said than done and we often must balance the metrics we can measure with the metrics we should measure. As illustrated by the Contino Metrics Universe:
The diagram above illustrates that the business objectives and customer requirements change. As they change, the project must continue to track them by adapting the metrics collected. It is important to measure what is used, not produced. I’m somewhat of a metrics enthusiast, but I’m also a pragmatist. Collecting metrics should not be overly onerous. There is a happy balance to be struck between the usefulness of the metric collected and the overhead in collecting it.
I have made the point numerous times that the success of a DevOps business case is based on its ability to demonstrate business and customer value. It is for this reason that 25% of the effort in collecting metrics should be allocating to measuring the business and customer value delivered by your pilot project. Including tangible metrics of improved customer or business value in a business case is pretty much as good as it gets! Even if a ‘proxy’ customer from the business is used.
It Doesn’t Have to Be Expensive…But It Probably Will Be
There are two main reasons why a DevOps transformation will be more expensive than it needs to be. The first is as a result of the way that we, as humans, process and understand the world. There is no correlation between a program budget and its strategic importance, but there is a feeling within the enterprise that a large programme budget means a program is more likely to meet its strategic objectives; it’s more likely to be taken seriously and those that work on the programme are more likely to be the top performers. It’s not true. It is, however, understandable – executives will often boast that their organisations have committed to a “£20m digital transformation”. There are a great number of implicit premises wrapped within that statement.
The second reason that a DevOps transformation is will be costlier than it needs to be is altogether more interesting. As organisations that are mature in conducting change initiatives will know; transformation endeavours require a blended set of skills. Deep technical skills complemented with business-orientated focus and experienced generalists with technical depth and business savvy to keep everything moving in the right direction. The challenge for large enterprises is that as enterprise roles have become increasingly narrowly defined and specialist, the skills and knowledge to achieve a successful transformation are spread across a larger number of people. This causes an additional complication called the Ringelmann effect:
Simply put, as a result of the Ringelmann effect, having more people in a team (and therefore, the higher cost) does not result in higher productivity (per person). The central premise to the Ringelmann effect is that as teams get larger, people find more room to hide and slack off! A larger team size also increases communication overhead, which means that it takes longer to get things done! External consultancies can help reduce the overall cost. The right skills in a smaller concentration of people will result in increased productivity and project velocity. It is reasonable to conclude that as a result of a reduction in the two largest sources of project cost (people and time) and appointing a small, external team that has the right skills will result in overall reduced costs.
Deciding to use individuals external to the organisation to deliver your DevOps transformation is not the most strategic course of action, it is more a question of ensuring the right blend of skills to compliment your existing team. External consultants will leave, the good ones plan for that to happen in advance.
Beware the Intangible Bolt-on
I was asked by a client to provide Quality Assurance on a business case that was about to be submitted. It was brilliant in so many ways. Aspirational, forward-thinking and progressive. The plan was to redesign a monolithic app as microservices in a global technology, media and telecoms organisation. It was so good until the last part, when the team stated:
“We’re going to do all this awesome microservice stuff and by the way, we’re going to dramatically reduce recruitment costs”
I am not saying that having the best tools and DevOps ways of working won’t reduce recruitment costs, but if something is stated in a business case it should be something that is tangibly delivered by the programme. The planning for the delivery of business benefits by IT programmes is extremely poor - only 31% do it and the majority of IT and business leaders believe this is the area where most improvement is needed.
Whilst the majority plan in detail for the implementation of the technology, only a minority plan for the process and organisational changes required to deliver the main benefits enabled by IT (40% and 22% respectively).
If you put something into your DevOps business case, you should commit to being able to deliver it. This has implications for the resources you include and ultimately the total cost of investment. You absolutely should include changes to the organisation and process as part of your DevOps business case, but don’t do it at the end as an afterthought. Identify those changes that need to be made and present them upfront. Qualify how the changes will be made and how progress will be measured.
Conclusion
In conclusion, the business case for DevOps is utterly compelling. However, for those of us tasked with the relentless pursuit of improving the IT function there remains significant challenges. Most significantly in mapping the benefits of DevOps to the definition of business value subscribed to by the enterprise and then communicating that value in a way that decision makers (and budget holders) recognise.
Finally, if you are reading this because you’re about to write a DevOps business case – you’re in a great position. You’re about to put down on paper a way for your organisation to very successfully traverse the unpredictable and difficult times ahead!
