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:
Peter,
This is a good “techie” example of translating technbabble to bizspeak. However, it is also the type of example that, while it allows a CIO to present at the strategic table, does not garner him a seat there.
I believe better examples would show the advantages IT can bring to the different departments in a company. For example, a CRM system provides limited (if any) benefit to IT, but could be a huge advantage to sales and marketing.
Advanced analytics on a company’s internet presence has payback to marketing. Enhanced forecasting has a play to operations and logistics.
However, in many companies, these departments come to IT asking for these solutions. Instead, IT – as a strategic partner – should be listening to the business needs and opportunities then proposing these solutions.
When IT’s focus is ITcentric – that is focused on cost savings and productivity enhancements within the scope of IT – then it is the beginning of a vicious cycle for IT, as they are continually asked to do more with less. When IT’s focus becomes aligned to the company, then IT becomes a means to an end.
The question then becomes, is IT a service organization, providing what is requested within the constraints of budget and resources and pushing back on items that SHOULD be done, but CAN’T be done now. Or instead, should IT be a strategic partner, working with the other departments, and ensuring the right technologies are available at the optimal time to facilitate the objectives of the business.
For the companies I work with, it is the later. But the CIO/CTO/consultant job becomes much more difficult, as they must stay current on technology while also having more than a surface understanding of the functioning in the other departments and make recommendations for opportunties before they are common knowledge in business.
Thanks for commenting, Tim. This post was one example of what I consider to be “table stakes”: a CIO/CTO simply must be adept at navigating the world of financial impacts of what they propose, and many aren’t. I certainly don’t disagree that there are many other things for a senior technology executive to focus on besides just these sorts of “techie” examples.
I don’t agree with the dichotomy of your question: is IT a service organization (and yes, it is), or is it a strategic partner (and yes, it has to be). And either way, financial savvy is a critical basic skill. It’s not the only thing that one has to be able to do well, but it’s indispensable.
Possibly I was not clear in expressing the dichotomy. When I go to Chick-fil-A, I expect someone to take my order and promptly fill it. When I go to a 5 star restaurant, I expect the waiter to present options – such as the special of the day, a wine that pairs well, etc.
The former I see as a service organization – IT waiting for requests to provide service to the business. The later is a partner, actively engaging the lines of business to understand their goals and opportunities, then proposing technologies that can assist in achieving those goals and opportunities.
This is not to say that it is an either/or. A strategic partner in IT is also a service provider. But a service provider is not necessarily a strategic partner.
I of course don’t disagree, Tim; in fact, it feels to me that you’re setting up a straw man here that I don’t come close to supporting. I’ve actually written frequently about the need for IT organizations to avoid “just being order takers” (my shorthand for this is, “you want fries with that?”). It’s getting ever rarer, in fact, for people to argue that IT should be a service provider that just takes orders. I also speak out here against the views along those lines expressed in one surprisingly well-received book.
Thanks again for commenting.