How often does someone in your company (often the CIO, or the CTO, or the head of infrastructure) end up running through the halls, waving a purchase order that “has” to be signed off that very day, or else key systems will allegedly go dark? Maybe you’re in the fortunate situation of being in a company where this frenzy doesn’t happen, but in my experience, that’s unusual.

I’ve written before on the importance of technology carefully shepherding its fiduciary responsibilities. Nothing contributes to the IT stereotype/stigma as much as a loud demand for a major purchase, at the last minute, justified solely by dire predictions of doom, and topped (often) with acronym-laden technobabble. Amazingly, it’s not that hard to avoid this situation, if you exercise a little forethought and planning.  The benefits of doing so are indirect as well as direct: you can change perceptions of IT into being viewed as a partner of business concerns, rather than as a troublesome, risk-fraught, and confusing cost center.

It all goes back to Management 101: plan the work, then work the plan. Surprises are a bad thing. Not only do you need a solid plan, but then you want to diligently track actuals against that plan. None of this is exactly a radical idea, yet I’ve served as an executive now in at least three different companies where none of it was happening before I arrived, with respect to capital expenditures.  To the extent there was a capital expenditure plan for the year at all (as opposed to just one big CapEx number!), it had been thrown out the window by February. Sure, this can and does happen in fast-paced Internet companies in particular, but the rankling thing was that no one really was tracking the changes against plan, or could envision how funds were shaping up for the year. Even if a plan has undergone radical changes, there still needs to be a current plan. Walking in, any executive (not to mention any auditor!) should be able to see one or two core documents that detail that current plan, as well as the progress against it.  If that’s not there, then the technology area (and by extension the whole company) is just operating by the seat of its collective pants, and that’s not acceptable.

Here are the minimum elements of responsible CapEx stewardship, in my view:

• Construct, as part of the annual budgeting process, the CapEx plan for the year, project by project, with anticipated months for each expenditure.  When the budget is finally approved, this CapEx plan becomes the Plan of Record.
• In addition to the expense grid, compose an initial outlined description/justification (at least a paragraph, definitely not just a vague phrase) for each project, assigning that project some kind of arbitrary ID for tracking.  This description needs to be signed off by the finance department for Sarbanes/Oxley purposes, and to ensure that the appropriate corporate guidelines for capitalization are being adhered to.  Note that often, a given project will end up having its cost split over several expenditures (e.g., multiple hardware purchases made in different months, so assigning each project an arbitrary but immutable ID is useful to help track back to the original plan.
• As a project gets actually kicked off during the year, there needs to be a deeper analysis and planning phase, during which the expected costs and timing get solidified and, of course, written down.  Here, it’s critical to document the alternatives to the proposed CapEx expenditure, including the risks and cost of staying with the status quo rather than going with the proposed approach.
• A regular process needs to be instituted and expected by all: a monthly formal review with the CFO, using the following tracking document: an itemized list of expenditures planned for last month, expenditures actually incurred,expenditures deferred, expenditures cancelled, expenditures upcoming for this month.
• The purchase order mentioned at the beginning of this post? That PO should come to the signing executive with predictable standard attachments: the analysis document for the project, the CapEx plan of record, and the current monthly CFO review showing the expected expense. What, this is an emergency and we don’t have those? OK, but emergencies had better be rare and explainable as exceptions.  In any case, the PO should appear at least a week before it “has” to be signed. No surprises.

Side notes:

• The analysis document for each project? That’s an excellent place to make sure that all the costs are taken into account, including non-capitalizable elements such as maintenance.  Again, “no surprises.”
• Any CFO or CEO who is being presented the justification for a technology project that lists and analyzes only one proposed solution has a right to be intensely skeptical: astoundingly, that single-minded approach seems to be typical at many companies.
• Here’s a key and often misunderstood basic tenet: just because a given expense is “in the budget” doesn’t mean that the amount is right or that the purchase should be made at all.  A budget is simply the bare bones of a plan, made with limited information at the time; for nearly all projects, a detailed investigation with multiple vendors is necessary to get true pricing and timing. The annual budget, your initial “plan of record”, should be regarded as a mere best-faith estimate.

If I were walking into a company, as a new CIO, CTO, or CFO, I’d immediately want to see the current CapEx plan, and the solid record of monthly reviews occurring as plans gel and change.  What, that isn’t all there? That tells me a lot.

And if you’re feeling that doing all this is a lot of work?  Well, if you want to be able to spend the money, you should be more than willing to put up with a certain amount of due process in order to get it.

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:

• Full sample investment analysis spreadsheet

Let’s talk some more about one of my favorite topics, project portfolio management (PPM). A lot of literature on PPM tends to focus on evaluating risks and returns. An excellent article on IT governance last week in The Wall Street Journal had the following sage advice:

“Create an IT portfolio by evaluating risks and returns. Just as an investor balances risk and returns in constructing a portfolio of investments, management should analyze the costs, benefits and risks of all IT projects to determine how to get the most benefit from the dollars invested in technology.”

I can’t argue with that. But I also like to talk about another major part of IT portfolio management, which focuses on juggling which projects can actually be resourced. It’s unfortunately easy to come up with ten distinct projects with positive return on investment (ROI), for example, in a situation where it’s really only feasible to do one or two of these a year. In some companies, the pressure to do any positive-ROI project becomes enormous, even if it means the company is biting off too much at once. So what to do?

One way to think about it is that there are two major categories of “disciplined decisions” about projects: CAN we do it, and SHOULD we do it? Both disciplines are needed; organizations tend to struggle with both, and decisions on both are often made by the seat of the pants.

• “CAN we” has to do with resources and capabilities, and whether the ones needed for the project fit in the scheme of everything else that’s going on. The results are usually expressed in manpower loading charts, as well as needs analysis papers that cover the trade-offs involved in bringing the proposed project to fruition.
• “SHOULD we” has to do with strategy, risk, cost, and expected return. The results are often expressed in financial metrics such as ROI, NPV, IRR, and so on. Note that there can often be projects that we “should” do (in a metrics-based view), but which we can’t (resource-based). That seems obvious? Well, believe me, it often isn’t.

If your organization is just starting out along these lines, it doesn’t make much sense to try to instill both the “Can we“/”Should we” disciplines all at once from scratch. If you have neither discipline well-entrenched in your organization, I recommend trying to establish the “Can we” discipline first: figure out ways to estimate manpower loading, assess project needs, and conduct executive-level project prioritization, so that you can collectively “right-size” what you take on as an organization.

What if you’re lucky enough to be in an organization that clearly understands that there’s a need for both disciplines, and already has some semblance of this “Can we” kind of careful resource allocation? Then I recommend for all envisioned projects (of sufficient size), the “Should we” aspects deserve to be evaluated first, simply to determine project eligibility (and assistance in prioritization) for further consideration in the portfolio. Evaluating the “Should we” aspects without a firm grasp of the “Can we” side of things? That’s a recipe for frustration and eventual failure. So, this post and (especially) the next will cover the “Should we” aspects, in detail and with specific tools recommended, while a later post will go into more detail on the numerical sides of “Can we“.

Just to get quantitative for a moment: here are some sample financial metrics for a project; by all means, you want to get to the point where you can reliably calculate, present, and make project choices based on such concrete metrics:

For detailed explanations of the meaning and suggested interpretation of each of these financial metrics, please see some of the references contained in the Lagniappe section at the bottom of this post.

In this day of spreadsheets and canned financial functions, though, the basic calculation of all those metrics is almost too easy, really just a few formulas away. My belief is that metrics are hugely important for decision-making, but that the data that goes into calculating the metric is what matters most of all. Specifically, what are the assumptions? What’s the analysis behind the numbers? Are you taking all the project factors into account? Have you brainstormed through all the costs and hammered on what benefits are truly achievable?

The point is to get as complete a picture as possible by soberly laying out the costs and the benefits, over time, taking everything into account. This is what I’ve seen few organizations do at all, and even fewer do well. In fact, many organizations will simply spout that “we base all project selection on demonstrated ROI,” without actually having a rigorous process in place for ensuring that they capture all the costs and all the benefits that go into calculating that ROI. A nice-looking ROI number comes out of the process, but the assumptions behind it aren’t well thought-out, so it’s fairly meaningless.

So as I discuss ROI, NPV, and other “Should we” metrics, I want to deemphasize the metrics themselves, and focus on what should be meticulously and methodically gathered in terms of those core assumptions.

Hard benefits tend to boil down to two major categories:

• increased revenue
• decreased costs (less personnel required, hardware or software that can be decommissioned, etc.)

Similarly, costs boil down to two categories:

• One-time costs (cost for acquisition of software and/or hardware, implementation costs)
• Recurring costs (annual maintenance fees, dedicated personnel needed for support, etc)

Each of these major areas should be the topic of intense “devil’s advocate” brainstorming with your team and with business stakeholders, as appropriate.

• What really are the prospects for additional revenue? Are you perhaps fooling yourselves and being overoptimistic? Is the business stakeholder willing to stand behind these estimates, on the record? And, if you think you can reduce costs and/or increase productivity, would you actually be willing to have those dollars removed from your budget at a defined point once the project is implemented? A dose of conservatism should reign here.
• What really are all the costs, both one-time and recurring? Have you thought of everything? Are you counting in costs such as shipping, or sales tax on equipment or software (an instant 8.8% budget jolt, depending on what state you’re in)? What about the full time frame? Are you thinking out the costs and the benefits for five years, and taking into account possible cost increases during that time?

In a subsequent post, we’ll examine a specific project example, showing the assumptions, the careful analysis, and then (almost secondarily) the “Should we” metrics that result.

Lagniappe:

• Gary Anthes, ComputerWorld, “Money’s tight? ROI to the rescue“
• Scott McCready, CIOView.com, “TCO, NPV, EVA, IRR, ROI: Getting the Terms Right“
• “Project Evaluation and Selection Analysis Techniques“

As I discussed last time, everything you add to your environment (hardware, software) costs money in recurring fees. Part of the job of the CTO/CIO is to sign dozens of invoices, each and every week, that approve payment for the various elements in your infrastructure that have come up for renewal. And hey, we’re all busy. Anyone who’s been pestered by the company’s usually indefatigable accounts payable department knows the perils of not having signed off an invoice in a timely manner: in other words, you can’t afford to let them languish. Problem is, it’s relatively easy to fall into a “rubber stamp” mode, scribble a quick signature, and move on to the rest of your busy day.

Multiply that by dozens of invoices a week, 52 weeks a year. A few thousand dollars here, a few thousand there: as the saying goes, pretty soon you’re talking about real money. Careful scrutiny of each and every expense takes time and effort, but my view is that it’s one of the major responsibilities of the job. The amount of company expenditures that flow through IT places an important onus on you, the head of technology, to constantly be thinning the carrots, so to speak.

And, especially if you’re new to the company and this job, chances are pretty good that you’re inheriting an essentially unweeded garden. At least, that’s been my experience. Your first year will be one of constant discovery, to put it charitably, as invoices land on your desk and you steadfastly resist the Rubber Stamp Syndrome.

Here are a few real-life examples. I’ll leave the names of the vendors out of these little anecdotes, although your guesses will probably hit pretty near the mark.

When I had just taken over as CIO at one company, a portion of our database licenses came up for renewal. As I pored over the perhaps intentionally inscrutable invoice, I discovered a couple of items that seemed questionable. It turned out that as part of a database software deal several years before, this vendor had included, with the consent of an apparently very optimistic but certainly very gullible head of IT, a few “free” licenses for one of its applications packages. Free, hmmm? Well, free except for the ~20% annual maintenance fee, which had been charged, and paid, for three consecutive years, with no implementation of the package and no plans to implement it. The Rubber Stamp Syndrome had struck. You can bet two things: one, we immediately stopped paying the maintenance fee; and two, we had a pretty unpleasant meeting with the very defensive, “hand caught in the cookie jar” vendor.

Similarly, at another job, I learned that various additional “modules” had been sold to the company years before as part of the company’s ERP solution. Vendors seem to sense when a buyer is susceptible to the “such a deal” sales pitch that I also refer to as “buy five of an item, shrink-wrapped, at Costco when you really only need one.” With software, it’s because those deals have incredible legs, with year after year of Rubber Stamp renewals. In this case, we had never used several of the modules in question, and had no plans to, but yet had been paying thousands of dollars in maintenance every year on those licenses.

Finally, to give a smaller example from a dollar impact point of view: I discovered that my infrastructure staff needed to make regular purchases of back-up tapes. We had been using the same vendor for this for several years, paying about $65 per tape. “Have we compared prices elsewhere?” I asked. Um, no, these are really low-cost items, I was told, and besides, this vendor gives us great service. Well, when you’re buying 50 or 100 items at a time, and can get the same product for $30 per tape cheaper (as it turned out), it’s definitely worth switching vendors.

In a nutshell: it behooves you to ask the following standard and basic questions regarding “legacy” renewals of maintenance and support:

• Are we happy with this vendor and its product(s) in general?

• Are we right-sized in terms of the number of licenses, now and for the foreseeable future?

• Do we really need and use this support? What are our other options? Is per incident support available? You don’t buy the extended warranty (I hope) on every major appliance you purchase; don’t buy it on absolutely every element in your infrastructure either. Don’t buy 24×7 support if a lesser level will suffice. That’s obvious, you say, and perhaps it is: except, of course, if people fall prey to the Rubber Stamp Syndrome.

If you find yourself becoming a rubber stamp, it’s time to get re-energized. Remember, the C in CTO or CIO needs to stand for Cheap.

What does IT do, anyway?

Well, among other things, IT spends money. In many modern companies, the expenditures made through IT are among the highest in the company, second only to salaries and marketing.

What does that mean? It often means that when cost-cutting time comes around (as it tends to do, in cycles, at most companies), there’s a particularly harsh spotlight that shines on IT expenditures, and a vast amount of pressure emerges to reduce these, quickly.

Unfortunately, the “quickly” part of that last sentence just isn’t realistic. A lot of IT expenditures can’t be turned off (or down) at a moment’s notice. In many or even most cases, the company has already signed (and paid for) maintenance agreements with hardware and software providers that typically last a year, if not longer.

It turns out that it’s nearly always harder than I expect to get my senior management peers to intuitively understand what I call the “substrata” of maintenance/operations. By “substrata”, which you’ll recall is another word for “foundation or groundwork”, I mean the ongoing “keep the lights on” expenditures that most of IT spending falls into. Once you’ve purchased a software license or a hardware product, you basically have to pay maintenance in order to protect your investment in that technology. While you can certainly choose to no longer pay for support/maintenance, or to even abandon your use of a product altogether, those decisions tend to come at discrete juncture points (once a year or maybe twice a year for each product or service), not every month. Stopping the payment of maintenance on a product or service is possible at those juncture points, but often pretty risky, since mission-critical systems often depend on it. Equally, completely stopping use of a product or service is often fairly thorny and long-winded in its practical implementation.

This all seems obvious, perhaps, but do believe me when I tell you that this reality doesn’t always penetrate. At various points in my executive career, I’ve been asked, after a bad quarter or two for the company, to “cut IT spending” by a given percentage. On the face of it, it’s not an unreasonable request, of course; it’s only fair that IT be asked to do its part in corporate cost reduction in times of need. Yet, other than through cutting labor, or by reducing planned future expenditures, it turns out that cutting IT spending in the way that’s really desired, at the drop of a hat, effective immediately, is very difficult indeed.

What can you do, then? The best approach is to remember your charter’s third prong: reduce costs. In other words, cut costs all the time, not just on demand. Every time you renew a product (hardware or software), it should be regarded as an opportunity to examine closely whether your expenditure on that product can somehow be reduced or even eliminated.

Secondly, remember (and constantly remind your fellow executives, because quite honestly, they tend to forget) that everything you add to your environment (hardware, software) costs money in recurring fees. The corollary of that is that the timing of those recurring fees makes a lot of the IT spending (practically speaking) non-discretionary, at least in the short-term to medium-term sense. Essentially, you’re creating a portion of your budget that simply can’t be cut. And it’s best if everyone gets on the same page about that. Of course, if you’ve been consistently cutting costs throughout the year, that should buy you a lot of good will when the belt-tightening begins.

Next time: how to avoid the “rubber stamp” maintenance renewal syndrome, with some real-life examples.