Here’s an alarming statistic that I read recently: 81 percent of everyone surveyed thinks their IS organization is average or below average. If “below average” translates to “below the mean,” only 20 percent of us are in the top 50 percent.

Since human perception is a pretty dull scalpel, “average or below average” may not be quite as precisely defined as “worse than or equal to exactly half the total number.” Let’s try a different interpretation. Figure anything within one standard deviation of the mean counts as average. In round numbers about two-thirds of any sample falls inside one standard deviation. The remaining third splits in half, so one sixth of any sample is above average. The remainder – five sixths, or just over 83 percent, are average or below.

Mystery solved! The 81 percent who figure their IS departments are average or worse are almost exactly the number who ought to think so according to the inviolable laws of statistical sampling.

The authors of the paper reporting this statistic made no further comment, so we don’t know if its absurdity escaped them or not. That three college professors who specialize in business metrics resorted to this kind of number, though, speaks poorly of the state of the art in IS measurement. I certainly didn’t do anything like that in my new book, Bob Lewis’s IS Survival Guide from MacMillan Computer Publishing (nor would I ever stoop to shamelessly plugging it in this column).

As we found last week, we have plenty of measures to choose from, all internal ones that tell us how good our processes are compared to internal baselines or external benchmarks. What we lack are external measures that assess the value we create for the enterprise. The measures we have tell us, to borrow a phrase, whether we’re doing things right, but not whether we’re doing the right things.

We do have one external measure at our disposal. The cost of technology is depressingly easy to measure, and our detractors gleefully proclaim it during budget season. But the value we create? That’s a lot tougher.

The purpose of any measurement system is improvement (ignoring its important use in political self-defense). The point of calculating the value we deliver to the enterprise is helping us increase it. How do we create useful measures of value? It’s tough. At the highest level, the formula for calculating value is Bang per Buck. We know how to measure the buck part, which leaves the bang as the part we need to measure. Start by listing the major categories of benefit we provide:

  • Capabilities needed so the company can achieve its strategic goals.
  • Capabilities needed for effective marketing efforts.
  • Fully automated (and therefore high-efficiency) processes.
  • Capabilities needed by redesigned processes.
  • Capabilities for improving communications with customers and suppliers.
  • Capabilities for improving internal communications.
  • Capabilities that allow individual employees to be more effective in their jobs.

See a trend? Except for the rare situation that allows for complete process automation, the value we deliver is capabilities. They’re enablers – necessary but not sufficient conditions for success. To measure the value we deliver, we need to understand how to measure the value of a capability when that capability may or may not be used effectively.

How will we go about that? In principle, we need to list every contributor to success in each of these categories, then assign a weighting factor to each of them that reflects its relative importance or contribution.

Great theory. Can we turn it into practice?

Oh, gee, we’re about out of space. Too bad … you’ll have to tune in next week to read the next installment.

Bob Lewis’s IS Survival Guide (MacMillan Computer Publishing) will be on the shelves by the time this column appears. For everyone who reads this column and wonders whether it’s worth buying I have only one thing to say: My kids need new shoes.

If you do buy the book and like it, tell your friends. If you don’t like it … pretend I’m your boss. Act like it’s the greatest thing ever, even though you know better. I have plenty of reality in my life already, and lots of friends and colleagues who minimize any risk of ego-inflation.

Of everything in the book, the chapter on measurement was the hardest to write. Measurement doesn’t lend itself to lively prose under the best of circumstances, and even among IS professionals the plague of innumeracy is rampant.

Worst of all, the state of the art when it comes to IT measurement is dismal. A recent conference in which I recently participated reinforced that conclusion.

The good-news part of the story is that we know how to understand the performance of data center operations. We have well-developed measures to help us understand how reliable our systems are, how well they perform, and how much they cost to operate.

Not only do we know how to measure operations, several professional benchmarking companies have extensive performance databases, so you can compare yourself to the rest of your industry, or to business as a whole. If you’re sub-standard, you can set up improvement programs to make yourself better. If, on the other hand, you’re ahead of industry averages you can … well, you can still establish improvement programs, because you always want to improve, don’t you?

Benchmarking really doesn’t do a lot for you, unlike baselining, which does. There are only two reasons for benchmarking, both of them social. The first is to defend yourself against executive-suite attacks (“We’ve just undertaken a benchmarking exercise and are ahead of industry averages, so QUIT YOUR GRIPING, FRED!”). The second is to break through internal resistance to change. It’s as common in IS as anywhere else for employees to figure they’ve already done as much as possible, so a benchmarking study that demonstrates sub-standard performance can help break through this resistance. (So can establishing a baseline and saying to employees, “I don’t care if we’re good or bad, we’re going to be better next year than this year.”)

Internally, we know how to measure operating costs. How about our contribution to the rest of the business? Well …

We do know how to measure how much process-improvement projects increase productivity. If anyone is willing to go through the effort, they can perform a before-and-after productivity analyses of the process being improved.

This doesn’t answer the question we’re asking. Process-improvement projects include not only new technology, but also process redesign, culture change, usually a new business model, and sometimes a new philosophy of leadership. What part of the productivity increase comes from information technology? It isn’t a meaningful question — technology is integral to the new process, not a bolted-on automator of activities you’d otherwise do manually.

Assessing the contribution of technology to productivity is what we’re best at and we don’t have an adequate framework for that, only a way to measure the impact of a specific process improvement project. We have no idea at all of how to measure the value information technology creates. Instead, silly notions like the Gartner Group’s Total Cost of Ownership and weak analyses like Paul Strassmann’s The Squandered Computer (both critiqued extensively in this space) still get a lot of attention.

It’s time for us to get a handle on this issue. If measurement of the value we create is important, it’s time to get on with it. If not, it’s time to formulate a clear-headed debunking of the whole concept.

Either way, we need to do better. Next week, we’ll start exploring how.