By

2 Comments

Starting points for the quantitative CIO: downloadable basic tools

Much as in any field, IT executives constantly have to seek a balance between idealism and pragmatism. Given a particular problem and the range of possible solutions, do we insist on “doing it right”, or do we buckle down and “just get it done”, even with gaps?

There’s obviously no single right answer, which is what makes IT consistently so fun and frustrating at the same time. Over time, though, my own approach has typically been to focus on the continuous improvement aspect of “doing it right”: whenever possible, get something going as a start, then hone it over time as you learn more about the problem and your situation.

Using spreadsheets as a management tool definitely falls on the “just get it done” side of this spectrum of approaches. Spreadsheets are seductively easy, omnipresent, and usable by people with a variety of skill sets and technical savvy.

But there’s a host of downsides: spreadsheets are frail creatures. Errors can creep in fairly easily, even for experienced users, as data and circumstances change, and spreadsheets are especially prone to the incursion of silent errors and omissions when undergoing revision.  And once implemented, in all their imperfection, spreadsheet-based solutions can broaden and become large-scale, long-term systems (I’ve seen this happen again and again).

Yet, I feel that every technology executive should be maximally fluent in spreadsheeting: simple tracking, analyzing, modeling alternatives, understanding costs and risks. The technology provides a readily available, easy way to knock out quick and dirty models that can clarify one’s thinking and approach enormously. They work well, as long as you keep in mind that the spreadsheet is usually a stop-gap, for those times when you are faced with a glaring need and you don’t have time, budget, or staff to implement anything deeper right away.

In an early blog post, I listed the seven areas where a quantitative approach is especially necessary for the technology executive:

[Read more…]

Filed Under: Financial, Metrics, Process, Role definition, Tools
By

8 Comments

Business impact and transparency: expressing system availability

“System availability was 99.83% last month!  That’s up from 99.75% the previous month!”

Sounds kind of good, no? I mean, that’s a high number, right? Right?

Actually, no.  It’s not a very useful number, in and of itself. In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a presentation of an alternative focus providing much more business value.

So, what’s wrong with a time-honored metric like “the system was 99.83% available”?

  • The number is deceptive. Few people can mentally translate “99.83% availability” into a more meaningful real number, such as “system was down for 1.3 hours last month.”  Even fewer can tell you the real difference between 99.3% uptime (also sounds pretty good, right?) and 99.8% uptime.  Both 99.3% and 99.8% look (to the vast majority of business people) at first glance like pretty good numbers for uptime, but the first represents more than three times the number of “down hours” of the second.

[Read more…]

Filed Under: Metrics, Performance, Pillars of Purview, Top 25 posts
By

4 Comments

Financial metrics for IT: the holy grail of ROI and how it misses the point: Part 2

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.

[Read more…]

Filed Under: Financial, Metrics, Pillars of Purview, Process, Tools
By

2 Comments

Financial metrics for IT: the holy grail of ROI, and how it misses the point: Part 1

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?

[Read more…]

Filed Under: Financial, Metrics, Pillars of Purview, Process, Projects
By

Leave a Comment

‘Rithmetic: quantitative approaches necessary in the CIO/CTO role

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.

[Read more…]

Filed Under: Metrics, Role definition
Mastodon