Too often, leaders think of a business case as a one-time checklist item. But the best practice — which will increase your likelihood of success — is to think of a business case as a lifecycle, an iterative process that involves many stakeholders and steps. This lifecycle has five phases:
“A recent Forrester study commissioned by Pivotal which analyzed the benefits PCF customers see when adopting the platform found that developers gain 50 percent more coding hours a week. How? The automation and self-service features of Pivotal Cloud Foundry decrease manual and mundane deployment tasks. Wait times for environment setup and code to be prompted to production are also significantly reduced… That 50 percent gain in coding hours led to more releases per year, speeding up release schedules from once every two months to once a week — and sometimes even daily. Forrester estimates this increase in productivity equates to more than $31 million over three years, while the reduction in DevOps time allocated to provisioning, patching and scaling across multiple clouds at almost $6 million.”
Also, Rackspace has a managed Pivotal Cloud Foundry service.
Original source: How Companies are Saving Millions with Pivotal Cloud Foundry
“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?”
Original source: How to build a business case for DevOps transformation
Stacey says that, even with IoT projects, starting small is good to prove long term ROI. She also describes the problem with doing transformational ROI when the work might just be doing improvements, like adding in more safety to industrial things. This doesn’t measure the creation of a new business ahead of time, innovation, which is an area that up-front ROI/business case stuff is obviously of little value, in trying be precise, at lease.
Original source: Don’t dream big when taking on industrial or enterprise IoT
Pretty good check-in on current studies showing productivity and ROI from using PaaS.
Original source: Building the convincing PaaS business case
“private cloud can be a less expensive option for enterprises than public cloud. Forty-one percent of 150 IT decision-makers surveyed in February 2017 as part of a custom 451 Research project for VMware claimed to be operating their own private clouds at lower unit costs than public cloud.”
Link to original
“direct expenditure on serverless can be cheaper than on VMs, but only where the number of times the code is executed is under about 500,000 executions per month”
Link to original
Last year I wrote several columns for FierceDevOps. Nancy Gohring was the editor there and graciously asked me to do so (she’s moved over to being an analyst at 451 and is doing awesome work over there). The FierceEmpire has shifted their stuff around and now it’s either impossible or impossibly tedious to find those pieces, so I moved them over to Medium. I’ve got to get my URLs to be my overly self-referential self, after all!
Here they are:
Over the last 40-odd years, something like 40-60% of IT-based (that would be data, or technology – since they can be different!) initiatives are subject to a methodical ROI analysis; the rest of the IT investments tend to be faith-based or shall we say, “part of a broader strategy.”
He goes on with a good example of doing end-to-end ROI for IT spend.
Many IT professionals believe innovation in IT pays for itself. But a surprising number of companies I visit aren’t in a position to prove this hypothesis. They typically don’t know what it costs to provide their IT services and can’t quite put a figure on the benefits of IT innovation projects. Without these key data points, they have a hard time quantifying the ROI or payback on any IT project—making it difficult for IT to compete internally with other departments for scarce business funding.
The rest has many considerations for planning our ROI, plus contingencies to muck about with.
For much more detail, see Mindy Cancila’s write-up over at Gartner from earlier this year.
Here’s a summary/excerpt of the three ways of thinking through it:
1.) Bottoms-up ROI: We know everything and have put it in this spreadsheet
…if you have a good handle on the costs during some period of time where you were doing DevOps, and the gain that resulted from that period of time, you could come up with a bottoms-up ROI analysis. I think it’ll be somewhat dicey since it’s so hard to attribute costs and gains directly to DevOps but hey, it’s better than either telling people they’re asking the wrong question or its mute cousin: nothing.
2.) Were the efforts to change worth it? That is, DevOps is all cost
…if you want to run the numbers on something like “they tell me it will take three months and $50,000 in training and consultants to ‘do the DevOps'” this might satisfy your ROI craving. Again, you’ll need to have a pre-existing ROI at hand to simply plug your DevOps costs into.
3.) Pain avoidance and remediation
In the “DevOps is all cost” ROI scenario, we avoided ascribing gain to changing to DevOps. Again, while this is overly simplified, the deliverables of DevOps are to provide a continuous delivery process for your product and ensure that your product has excellent uptime. How could you account for the gain of those two desirables? You could create a way of assigning value to the knowledge you gain from weekly iterations about how to improve your product. You could also calculate the savings from avoided downtime.
Check it out, and tell me how you’ve been answering that question.