All Posts in Organizational Design

|In: Industry Commentary|Last Updated:

CIOs are, according to many in the business punditocracy, supposed to run IT as a business. Yet in spite of all of the ink smeared on crushed trees advocating this thought process (not to mention the miniscule magnetic domains that have given up their freedom to store it) I’ve yet to see anyone define what they mean by “business.”

It might seem too obvious to bother with. We all know what a business is, don’t we?

That’s the problem with this sort of thing: We all do know what a business is, only we don’t all know what one is in the same way. Depending on the situation and who is doing the talking, businesses can be:

  1. Non-human, amoral organisms that have an existence independent of the people who make them up, and which, like any other organisms, consider self-perpetuation their first and most important goal.
  2. Mission-driven entities that exist to provide goods and services that have value to someone.
  3. Product generators that exist to deliver items for which customers will pay more money than was needed to provide them.
  4. Profit generators that exist to deliver a stream of money to their actively-involved owners.
  5. Ecologies — environments in which individuals compete, and sometimes collaborate to obtain resources.
  6. Assemblages of processes that connect to transform inputs into outputs.
  7. Places of employment that exchange work assignments for money and non-cash compensation.
  8. Social fabrics that provide a space for people to interact and form connections.
  9. Personal “force multipliers” that increase an individual’s ability to achieve goals.
  10. Opportunities for investment, to deliver a lump of cash to a passively involved shareholder.
  11. Commodities to be bought, sold, aggregated or dispersed for profit.

And more. This isn’t a complete list by any means. Nor are the items on the list alternatives on a multiple-choice test. Many can be simultaneously true.

When a CIO is supposed to run IT as a business, which definitions are supposed to be part of the formula?

Certainly not Definition #1. If you work in IT you might like it, as it makes Definition #7 a more enduring possibility. But even ignoring the pundits who also recommend disbanding internal IT in favor of outsourcing, self-perpetuation isn’t something you can sell to a board of directors.

Which also means you can scratch Definition #7 off the list.

Definition #2 is a certainty. In its simplest form, IT’s mission is to provide working information technology to the business. This, or something like it, is IT’s mission whether you run it as a business, a department, or a hobby, so scratch Definition #2 off the list as well. The same logic applies to Definitions #6, #8 and #9.

Definition #3 is a distinct possibility. Never mind a mission. A Definition #3 IT business would deliver products and services to internal customers in exchange for money, through the magic of transfer pricing (the practice formerly known as charge-backs).

Except that it doesn’t work that way. When companies engage in transfer pricing they put controls in place to make sure internal departments break even exactly. If they didn’t, the business as a whole would be an ecology (Definition #5, as are most companies that engage in transfer pricing anyway). Scratch this one off, too, and Definition #4 for the same reason.

Definition #5 is a good representation of a marketplace as well as a jungle, and in fact, marketplaces are near-perfect parallels to ecologies. It’s bad enough when a CEO turns a whole enterprise into an ecology. Another description of this sort of environment is “political quagmire.” One presumes “run IT as a political quagmire” isn’t what the pundits have in mind.

Definitions #10 and #11 make no sense either. It might be fun to sell shares in IT to various business executives and might even lead to beneficial results, in much the way the Green Bay Packers benefit from having 125,000 fans as the shareholders who collectively own the team.

Somehow I just don’t see it working very well in practice.

So there you have it. Eleven different definitions of “business” and not one of them makes any sense for IT. Which leads to a question: If IT isn’t a business by any reasonable definition of the term, what might it mean to run it like one?

I’m left without an answer, and with only one possible conclusion — that I don’t know what the pundits are talking about.

I suspect that’s something they and I have in common.

Comments

|In: Industry Commentary|Last Updated:

In the beginning was Deming.

Deming introduced measurement to industry in the 1950s. A statistician, he relied on sophisticated multivariate techniques. He encouraged those who didn’t understand sampling theory, analysis of variance and multiple regression to stay away and let the experts handle the data collection and math.

American industry ignored Deming and his theories — I can’t help but suspect America’s enduring cultural distrust of the intellectual — but Japan did not, turning itself from a defeated military power to a fierce economic superpower in the process.

As a culture we are nothing if not adaptable, and so “metrics” happened in (to?) America. Sadly, we aren’t so adaptable that we were willing to actually learn, for example, statistics.

Which might explain why most of the metrics stories I hear are horror stories, not successes.

I’ll be the first to admit to flaws in my sample. I’m sure it is non-stationary, biased, suffers from heteroskedasticity and perhaps the heartbreak of psoriasis as well. I’m nonetheless confident in this conclusion: Call centers are the most mis-measured function in business, and IT Service Desks are the most mis-measured type of call center. Which brings us to this week’s anonymously provided tale of woe:

At the Help Desk where I currently work, they like to measure First Call Resolve (FCR).

What I am finding out from longtime tech support people is they like to game the metrics. Here’s how it works:

First, the system defaults every call to Resolved whether it really is or not.

If a user never calls back to say “That didn’t fix it”, you get a freebie. If, on the other hand, the user does call back to say, “Yep, that fixed it,” and the tech on the line documents the call in the system notes, you just lost an FCR. Why? Because you weren’t the LAST person to talk to the user. Yep, the last person to talk to the user on a call gets the FCR. It’s as if the relief pitcher who comes in with two outs in the ninth, a five-run lead and the bases empty gets credit for the win.

So potentially someone else could make you look bad, just by creating the last entry in a call log. And after five days, a ticket goes from Resolved to Closed and there’s nothing you can do about it.

You always open a ticket on a new call, find out what the issue is, then decide if it’s your queue or not. If not, you transfer it. However, the queue you transfer to will never get an FCR on that call even if they solve it immediately. Why? Two people have talked to the user, that’s why.

Some tech guys get around that by opening up their own ticket and documenting it for an FCR, leaving your ticket out to hang. And that can ding YOU just as badly since it’s been presumed you abandoned it. If you get a call where no one handles it but they actually need to call outside of tech support to, say, Financial Ops, you document it but those calls are not counted as FCR. They are deducted from your score.

Strangely enough, some of us were talking about this the other day — about how to increase FCR legitimately. Some of them had researched suspicious FCR standings (which are posted for individuals) and found that some of the lumps were posting gratuitous FCR calls (in other words, fake calls). You could tell by the shortness of the ticket and the vague incorrect answers that were in the notes.

The best way to find the lumps? Not the FCR metrics — they’re worthless. Instead, just ask the other techs. Most tech people are fairly honest in appraising their fellow co-workers. It’s not that we don’t like them. It’s idiotic management playing games with our stats.

So, like the plaque says, “Be careful what you measure. You’ll get it.”

The culprit here is clear: Simplemindedness.

A Help Desk is neither simple nor solitary. It’s one part of a system that should: Work on what’s most important first; resolve incidents quickly; and prevent recurrences.

Assessing the system’s outputs isn’t all that challenging. Assessing the engineers and technicians who create the outputs is tougher.

They have to resolve what they can, properly refer what they can’t, accurately document their work, and escalate underlying systemic defects. That requires: Intelligence, judgment, technical skill, diligence, and collaboration. It’s a multivariate situation.

Just ask Deming.

Comments