As I promised in my previous post on this, and along the lines of the “intensely practical” goal of this blog, we’ll now take a look at the financial cost analysis for a specific project. This is only an example, with details changed or obscured, but it is based on a real proposal from a few years back, analyzing whether to swap out an existing infrastructure element (a storage array) for a newer and more capable unit.
As I’ve argued before, any proposal like this should really analyze and present several alternatives – e.g., sticking with the status quo, changing to vendor X, or changing to vendor Y. This example covers only one of those analyses, but I think you’ll get the point. Here’s what I see a lot of IT people forget: your goal here is to analyze and communicate and recommend the best choice for the organization, not just to justify what you already want to do in your gut. You need to be your own devil’s advocate in this process. If you can’t clearly understand all the benefits and outline all the costs, you’ll make poorer decisions, no matter what your gut tells you.
So let’s dive into the practical. Here’s the process: if you’ll recall, we want to look at hard benefits and hard costs of the proposal, and look at these over a five-year time horizon to get the big picture. On the benefits side, we talked about how benefits break down into increased revenue and decreased costs. Of course, the notion of actually increasing the company’s revenue based on an infrastructure change is unlikely, so we’ll leave that aside in this case. The whole purpose of this particular example proposal is to decrease costs, both in real terms and in terms of making personnel more productive. So let’s look primarily there for the benefits that will result from the proposal.
An infrastructure change doesn’t happen for its own sake: the idea is that it will increase productivity and/or provide greater features and capabilities, freeing up personnel to do other things or to do more with less work. Your job is to try to quantify the increased productivity appropriately, using some assumptions.
Basically, figure out how much time you think your staff will save (how many people, with what percentage of productivity boost). If two people today are spending ten hours a week each on manual maintenance of something that will be eliminated by the new infrastructure element, then you’ve just boosted two people in productivity by 25%, because that’s how much of their job will be eased by the new equipment and tools.
These assumptions are collected up front for the proposal, including an estimated labor cost per hour:
Now, sticking with the notion of envisioned benefits, we look at what direct costs will go away with the implementation: in this case, we will avoid having to pay maintenance on the current (soon to be former) SAN. Equally, we identify that we’ll save space and power in the data center and we quantify that appropriately. Remember to be conservative! Your case will not be improved by being cavalierly optimistic about the benefits you envision. Especially if you’re claiming enhanced productivity of your staff, be aware that eventually you will be asked to show concretely that this increased productivity has happened, either by accepting a staff reduction or by taking on whole new arenas of responsibility with the same staff.
In the end, we see the following table of benefits over the five years. Items in blue are entered as inputs; items in beige are calculated using the assumptions plugged in appropriately.
Now let’s turn our attention to the costs of the implementation. Recall that there are two species of these: one-time costs (acquisition and implementation), and then recurring costs for maintaining the new equipment. In addition, you’ll want to delineate which of these costs you can capitalize versus what must be expensed; consult your finance department if you are unclear on which is which.
In the case of this example, the cost of the hardware, plus implementation (using both internal and external resources) are clear and capitalizable costs. In this example, the hardware is set for a multi-year lease, so portions of the expense show up in each of the five years. We also identify through brainstorming that you will need to have work done at your colo facility to accommodate the power needs of the new equipment: a one-time fee. What about your maintenance costs for the new equipment? The first three years are baked into the purchase in this case, but you’ll need to allow for the maintenance cost you anticipate in years four and five. Don’t forget the associated software license fees (one-time or recurring), and for heaven’s sake, don’t leave out shipping and sales tax if applicable (sales tax alone, if forgotten, will punish you with a 8-9% instant overrun against your proposal).
Here’s what falls out for the table of costs over the five years. (Note that all costs need to be entered as negative numbers):
In other words, out of all this input and assumption-gathering, hopefully intensely brainstormed and debated (did we leave anything out?), comes a full one-page picture of the entire cost and benefit horizon for the proposed infrastructure change. Its assumptions are there in the open, ripe for the challenging, and this is how it should be. Open scrutiny of your plan makes for a better plan.
Takeaway here: all the hard work here consists of figuring out the assumptions on costs and benefits over the time horizon. Now that you have gathered all that input, the associated recaps and financial metrics fall out through simple spreadsheet calculations. Now, at a glance, a CFO, COO, or CEO can get a view on how much this will all cost and where/whether the payback is there. Presenting your proposal to management just got a whole lot easier. When you lay things out in this fashion, you’re playing the game as a businessperson, not just a techie who wants to spend money.
For example, let’s show the resulting breakdown of expense versus capitalized dollars over the five years:
Now let’s look at the resulting financial metrics that will let you weigh project against project:
And finally, let’s look at a resulting graph, showing the proposed cash flows and the payback timeframe:
See the Lagniappe section below for a link to the example spreadsheet in full, licensed under the Creative Commons license. Feel free to adapt and use this spreadsheet for your own proposals, and please let me know any feedback you might have.
Lagniappe:
