[Excerpt from my book, Data Protection for Virtual Data Centers – www.DataProtectionBible.com]
Chapter 2, Data Protection by the Numbers (click here to download Chapter 2) covers among other things ROI and TCO. One of the formulas discussed is the “Cost of Downtime”:
Sometimes, the best thing that can happen when you present your methodology and resulting BIA/TCO/ROI justifications for a project is that the business/operational/financial stakeholder challenges your formula (in a constructive way). When working with your business leaders and establishing the formula that you will use in your process, here are a few key ideas to frame the conversation around data protection TCO/ROI:
- Working backward, ROI is just a comparison of BIA to TCO.
- TCO is simply a prospective invoice, along with some simple assumptions of fixed costs. Likely, any challenges here will be minor tweaks to the fixed values, not wholesale changes to the math.
- BIA is where challenges occur—your business stakeholder(s) don’t agree with how you calculated the cost of downtime (see above, earlier in chapter). This is great news because then you can collectively decide why the formula doesn’t apply to a particular business unit or technology resource.
If your discussion circle can collectively agree that when the database server is down for up to a day, employees can catch up on email, or vice versa (and thereby reduces some variable by half), then the collective team has turned your formula into their formula.
If the HR person can provide more specific hourly dollar (Hr) values across a large department (though you are unlikely to get a list of individual salaries), your team now has much more accurate fixed values that both the IT management and the operational management will agree on.
In short, every pushback that can be discussed or refined brings buy-in and agreement by the other parties. When you have five variables to work with, the formula may seem academic. But if you get more accurate modifiers, and the dollar variables are filled in with real numbers, you are only left with the technology numbers, such as:
- How often does the server go down?
- What is the cost of replacement hardware?
- How much do tapes cost?
These numbers are usually easily accessible by IT management and complete the equation. From there, you now have a new BIA that is even more defensible and that now has credibility in the eyes of the other stakeholders. TCO comes from the invoice and projections. ROI is simply the mathematical comparison of the BIA and the TCO.
But now, because everyone has weighed in on the financial values and the relational impact of the formula, everyone believes the ROI, no matter how big or small. Going back to the concern that we had around presumed credibility of the ROI formula:
If the ROI is less appealing (e.g, TCO is 50 percent of BIA), at least everyone was involved in understanding the legitimacy of the numbers, and you have a greater likelihood of them agreeing to the project.
If the ROI is too appealing (e.g, not emotionally credible), you have the simpler problem of working with the vendor through side meetings to educate your stakeholding peers as to the legitimacy of the solution and the higher potential of being that hero by spending $10 to save $100.
Either way, having the initial formulas and variables challenged turns the project from yours to theirs and will help you pay for what you already know you want – or discover what you really need or don’t.
As always, thanks for reading.
Blog post cross-posted on ESG’s Technical Optimist .com.