All Posts in Leadership

|In: Industry Commentary|Last Updated:

Service levels, you’ll recall, are two-part measures. They define a minimum threshold of acceptable performance and tally how often a service provider meets or exceeds it.

Enter the Pew Research Center for the People & the Press. In an excellent example of service levels in action, it defined a minimum threshold of acceptable knowledge of current events –getting two thirds of a questionnaire right (sample question: Who is the current Vice President of the United States of America?).

Then it tallied how many of those surveyed met the threshold.

Pew found, perhaps unsurprisingly, that those who watch The Daily Show and The Colbert Report on the Comedy Channel tied regular newspaper readers for top honors (54%). Those who watch Fox News met the standard 33% of the time, outperforming only watchers of network morning programs. Draw your own conclusions.

It’s tempting to blame this mess on intellectually lazy Americans, Katie Couric, Roger Ailes, or all of the above. Temptation being what it is, I will.

Underneath the symptoms, though, is a challenge you and I face every day as we deal with vendors, staff, managers, vendors, information outlets, colleagues, and vendors in the workaday world of information technology: The challenge of seeing what isn’t there.

To illustrate the point, go back to last week’s column, which described Factcheck.org’s critique of a current U.S. Chamber of Commerce ad. The ad provides an alarming statistic — that lawsuit abuse costs your family $3,500 per year.

I received quite a few e-mails challenging my statement that the U.S. Chamber … well, I said it was lying. The e-mails pointed out that the Chamber’s math was perfect. Lawsuits did cost $235 billion in 2005 and that this does come out to $3,500 per family, if you assume an average headcount of four (bad assumption, by the way).

The problem with the ad isn’t what it said. It’s what it left out — what isn’t there. It left out:

  • How the Chamber defines “lawsuit abuse” (apparently, it’s “filing a lawsuit for any reason at all”).
  • What fraction of all lawsuits falls into the “lawsuit abuse” category (close to 100%).
  • How those who paid the legal fees and fines managed to transfer their costs to your family (and wouldn’t that make for a popular seminar?).

It’s far easier to deceive through omission than through falsification. Omission is far harder to spot.

In your professional capacity you’re inundated with product specifications and performance statistics, staff reports and recommendations, project proposals and justifications, all trying to persuade you to do something or other. If you’re like me you’ve become adept at skimming them to get the gist of what they’re trying to tell you.

Gist is a useful substance, right up there with beef jerky and Maxalt. It has its limitations, though, and top among them is that gist doesn’t help you spot what isn’t there. Quite the opposite. Gist is for understanding what someone is trying to tell you. As a result, it helps them conceal much more than it helps you reveal.

If there’s a magic formula for spotting what isn’t there I’m not aware of it. I do have favorite examples. Here’s one:

Imagine you asked a vendor if HP supports Vista for its 2840 color laser multifunction device (to take an example at random — that I happen to own one is sheer coincidence). Imagine the vendor answered in the affirmative.

The answer would be true. It would also be seriously deceptive. You can get a 2840 driver on HP’s website … which works for USB-attached devices but not network-attached ones. You can also download HP’s admirably conceived Universal Print Driver (UPD). It lets you print to the 2840 through either a USB or a network connection.

But only in black and white, and it doesn’t support the scanning function.

Phrasing your question to be in a position to accurately evaluate the product is something of a challenge.

How do you spot what’s missing? First, don’t skim — read carefully. Second, apply your experience. Think about all the ways you’ve been deceived in the past, look for parallels, and ask about them.

And third, don’t try to be clever. This question isn’t at all clever: “Here’s what I’m trying to accomplish. How will your products help me do it? Tell me step by step.” It might not be clever, but it gets the job done.

Of course, to ask this you do have to know what you’re trying to accomplish.

Comments

|In: Leadership|Last Updated:

The IT industry has not approached the subject of service and how to measure it with much subtlety. Quite the opposite — we simply established service level measurement as a sort of tradition, to be respected and adhered to whether or not it fits the situation very well.

Service levels originated in the telecommunications industry, where customers needed some way beyond “I hope the lines stay up” to define and manage vendor performance. From this modest beginning sprang more consulting fees than you can shake a stick at, if shaking sticks at consulting fees is your idea of time well spent.

Service levels never strayed far from their origin, though, which means the hidden assumption that providers are vendors and users are customers is not very well hidden. But as long-time readers of Keep the Joint Running know, when internal IT defines itself as a vendor to its internal customers, it stops delivering the advantages to be had from working with internal IT and replaces them with the disadvantages of working with a second-rate outsourcer (the first rate ones being, by definition, in actual for-profit business with multiple clients).

Service levels are, if you aren’t familiar with the concept, two-part measures. The first part defines the minimum acceptable level of performance. The second tracks how often a provider meets or exceeds that performance level. It’s the reason I’ve been skeptical of their usefulness when you aren’t a vendor providing contractual protections to customers: You should be trying to improve performance while reducing variability — goals measured by entirely different formulas (for more, read “Measuring service,” Keep the Joint Running, 2/16/2004).

Service levels do have their place within internal IT. They are, as it turns out, just the ticket for whatever isn’t important enough to continuously improve. More precisely, they’re the right measure for every parameter of a system that isn’t an optimization target.

You can’t optimize everything. The reason is well known: There comes a point in any optimization process where trying to further improve one system parameter — say, cycle time — can only come at the expense of another system parameter, such as defect rate (unless you change the game by instituting an entirely different methodology or process design that is — if you do, all bets are off).

That isn’t necessarily the wrong choice to make. It should, however, be an informed choice. That’s where service levels come in. First you choose the one or two system parameters that matter most — whose performance you’ll work to continue improving. Then you establish service levels for the rest to make sure you don’t kill them in the process.

An example, to illustrate: You institute a standard software quality assurance methodology. The goal of the process is, unsurprisingly, to reduce the number of software defects that make it into production (that is, the goal is to improve quality). That’s the most important optimization parameter. And, you decide, you want the process to have a short cycle time, to the extent you can do so without jeopardizing quality.

That leaves four process parameters unspecified — fixed cost, unit cost, throughput, and excellence (which in this case means adaptability). And since they’re unspecified they’re likely to get out of hand, because …

The easiest way to improve quality is to increase the number of test cases. That, however, increases cycle time. To avoid that outcome you’d have to add staff. But that increases unit cost. Is that acceptable or not?

The answer to the question is defined by a service level — in this case, the maximum acceptable level of spending per deployed module, or some similar measure.

Or, you decide to improve quality by implementing some testing software. That lets you explore more test cases, and to automate regression testing and stress testing, without adding staff.

The software isn’t cheap, though, so up goes your fixed cost. Is that okay? It depends on the service level associated with fixed costs, sometimes referred to as the capital budget.

In IT we face these trade-offs over and over again. Tune servers for performance and they fail more often. If performance is your goal you need a service level for reliability, or vice versa. Tune servers for performance while improving reliability by adding redundancy and up go your costs. That’s right — your budget is just another service level.

It’s really pretty simple. Decide what matters most and improve it. Set boundaries on everything else so it doesn’t get out of hand.

We sure do make a big fuss over it all, though, don’t we?

Comments