Everything and the Kitchen Sink
By Lisa Smith
As I discussed in “Introduction to ROI”, determining what to include or exclude in your ROI analysis can be tricky. What if you leave off a metric that ends up being materially very significant and eats up all of your savings when you begin to implement? Shouldn’t you just include ALL of your related costs, just to be sure? Sometimes it feels much more comfortable spending many hours in “analysis paralysis”, just to be safe.
But I am jumping ahead of myself. Let’s start with the mechanics of how to figure out the scope of your ROI Analysis.
Setting the Scope for ROI Analysis
The guiding principle is pretty simple: Model the stuff your solution is going to impact.
Step 1 – Create a Capabilities List
Create a list of all the capabilities your project is going to deliver in a single column (I like to use Excel, even for a text exercise like this).
Step 2 – Create a Benefits List
In a second column next to this list of capabilities, draft the benefits that are going to be delivered by these capabilities. To do this you need to answer the question, “So what?” with regard to every capability you are delivering. The lens for these benefits should be focused on what the company is going to achieve from the successful implementation of the project you are requesting funding for. Don’t get caught up in how you are going to measure these benefits just yet. Don’t judge what will be considered big savings or small savings. Just free flow – write them down.
If this exercise is really hard then it might mean that you need to get a better handle on your desired future state. If you have a great vision of where you are trying to get to with your project, a list of high level benefits should flow easily.
Step 3 – Refine Your Value Drivers
After you have your list of capabilities and benefits (I will refer to these items as “value drivers”), share that list with your peers who are familiar with your “as is” state and your “to be” state. You might be given a few more value drivers to consider, or you might decide to drop a few value drivers. If your project includes benefits or services consumed by other teams or end customers then you need to spread your wings, leave your nest and start talking to other people. The conversation would sound like, “If we could provide, ABC Service, what would the benefits to your team be?” This “voice of the customer” data provides a great insight into how well adopted your project or service would be; evidence that wider spread gains would be achieved beyond just your team.
“If you build it, they will come” may work in the movies, but the success of any technology project hinges on internal adoption. Many internal cloud projects failed to get the adoption levels they were expecting from other lines of business. They built it, but no one is coming. Quite often these missteps could have been avoided if they had a greater understanding of their consumers’ needs and desires, and used those to fuel the short list of the cloud services provided.
Step 4 – Create a Value Model
Let’s create a value model using an example from VMware’s product vROPs, Capacity Management benefit statement:
“Capacity management helps identify idle 1 or overprovisioned2 VMs to reclaim excess capacity and increase VM density3 without impacting performance. “
Reclaiming excess capacity is our “So what?”, or benefit statement. We need to draft a model to calculate the financial impact of reclaiming excess capacity. The model should include the before and after depiction from our three new capabilities:
- Removing idle workloads
- Reducing assets provisioned per workload
- Increasing VM density or consolidation ratio
The net effect of reclaiming excess capacity refers to expenses associated with server and storage infrastructure capacity. If that was the scope of your analysis, the capital expense associated with the server and storage savings would be all you needed. You might also consider expanding the scope, to include the operating expenses also tied to that hardware. Those operating expenses would cover the power and cooling of the hardware, the data center space overhead, the administrator labor needed to install, maintain, support and refresh that gear. This technique is often referred to creating a “total cost of ownership” view, considering the acquisition cost as well as the ongoing operating cost of an asset.
Try grouping the value drivers into themes such as reducing computer hardware infrastructure, reducing incident management processes, or reducing time to market for application development. For a single theme it is best to create a single value model for all of those value drivers. This is most helpful in providing a single depiction of the “as is” costs or process effort of today compared to a view of the future “to be” state – comparing apples to apples.
So where do we draw the line on scope?
If your value drivers are a pretty short list, feel free to model every aspect of those benefits. If your value benefits list is lengthy and your “so what” list has over 10 items, please consider scoping to only key and material items.
While I am going to be applying a bit of circular logic here for a minute – if any one line item in your TCO analysis is less than 10% of your total savings, you might consider dumping it from your model. The savings does not support the effort to QA your math or the effort to socialize the savings. Secondly, if your savings is considered “soft savings” you might want to consider dropping it also. Especially if you have plenty of hard dollar saving to justify the investment. Don’t gild the lily. If you are not familiar with “hard and soft dollars” concept, I will be covering that in a future article.
==========
Lisa Smith is a Business Value Consultant in the VMware Accelerate Advisory Services team and is based in New York, NY.
