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“

We’ve established the importance of targeted reading and writing for the senior information technology executive. I’d like to turn my attention now to the third R, ‘Rithmetic. Even though the “soft skills” of management are probably most crucial to a successful executive, IT is one area where quantitative skills are a regular (and, sadly, often ignored) part of the job.

I’ll have a lot more to say on each of these subjects in future posts, but for now, let’s outline the seven major arenas in IT where quantitative measurements and analysis need to be part of your arsenal. Some or even all of these will seem obvious and maybe even unavoidable; yet, some, astonishingly, have rarely (or even never!) been touched or attempted in more than one company I’ve seen. In fact, sometimes it seems that even established companies go out of their way not to be quantitative in several of these areas, running instead by “seat of the pants” and gut feel.

• Budget

Getting budget forecasts right is 90% of the battle here, and the only way to do that is through unswerving attention to detail, making sure, for example, that you don’t miss whole categories of expense (remember that system you purchased just before end of year? It’s going to cost you maintenance in the following years). Budgeting systems can help, if you’re lucky enough to be in a company that uses something more sophisticated than spreadsheets and elbow grease for its budgeting process. A great percentage of non-labor corporate expenses tends to flow through the IT function, so shepherding these expenses carefully is a key role of any CTO.

• Return-on-Investment (ROI) analyses

Are all the projects you do (development and infrastructure-related alike) based on a solid, quantitative, brutally honest assessment of whether there’s a financial return to the company on the necessary investment? Yes, some projects are indeed simply “strategic” or dictated by regulatory constraints, but I’ve seen the ROI analysis skipped more often than not, with executives somehow preferring instead to let emotion and gut feel dictate the decision. And, in your ROI analyses, are all the likely costs taken into account? A well-scrutinized and fair-minded ROI analysis process will expose any tendency that you or others may have towards “wishful thinking”, which leads to bad investments. Lots more to follow on this topic, including covering negotiation with providers.

• Project estimation

“Oh, that’ll take about two months”: the toss-off estimate that too often rules the day (and then sinks the ship). Instead, do you have a process and a model for breaking down a project and coming up with more than a seat-of-the-pants estimate? Are you constantly honing that model and evaluating how well it’s performed for you? There’s lots more involved in this category, extending to your overall project methodology and development process, but the estimation aspect (breakdown of tasks, amount of time, level of resources) is the one where ‘rithmetic comes most into play.

• Resource allocation

Cousin of the area above, resource allocation is, as I’ve discussed, one of the main functions of management. Again: is yours seat of the pants, or based on quantitative factors? What’s the capacity/throughput potential of your “factory” (development and infrastructure-related alike, once again)? Are you filling, underfilling, or overstuffing that capacity with the projects currently on the docket? Do you have a repeatable allocation process that is subjected to regular examination and scrutiny as you strive for continuous improvement? Some IT departments swear by specific project management tools to do this; others have developed spreadsheet allocation techniques for a “squint across your thumb” way of making sure you know where the large chunks of resource are needed and being allocated. Again, lots more to follow on this topic.

• Capacity forecasting

Servers, system memory requirements, disk space, network, database: all of these are finite resources, and all of them tend to get filled up over time, by the nature of our business. Are you awake at the wheel on how full (or empty) the tank is on each of these? Are your plans to upgrade them based on quantitative and demonstrable growth curves and system installation/upgrade assumptions? I stepped into one company where the operations director had simply decided to purchase major server CPU boards twice a year, with no quantitative studies supporting that need.

• Performance metrics, operations

In a nutshell: what metrics are you tracking (and how are you summarizing and publishing those metrics for your own use and for scrutiny up the management chain) to let you know how your systems are performing (e.g., response time, stability, throughput)? A distressingly large percentage of internet companies, in particular, that I’ve gone into as an employee or consultant have been unable to show me any methodical tracking and publishing of IT operational metrics beyond the merely financial.

• Performance metrics, development

Aside from just meeting the targeted delivery schedules and milestones (a feat that by no means should be undervalued), how are you measuring development and QA? Is your factory functioning as well, better, worse than it was last year? Examples here of possible mechanisms include velocity charts, function point counts, test case management, bug counts over time.

‘Rithmetic. It’s your friend. It definitely beats mere “table thumping” when you need to explain just what your department is up to and how well it’s doing.

Lagniappe:

• Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)), by Steve McConnell
• Testing Computer Software, 2nd Edition, by Cem Kaner et al.
• VersionOne, “Velocity“.
• “FAQ – IT Investments – What is ROI and How is It Used“.