George Will is catching up to me.

Two weeks ago he caught on to something I covered 21 years prior — that the average American is more affluent by most measures than the wealthiest of historical figures.

Then, last week he wrote about Baumol’s disease a mere 16 years after yours truly wrote about it in this space.

Do you think Mr. Will is mining the KJR archives? Are you? Please do. There’s good stuff in there, if I do say so myself.

In any event, Baumol’s disease is why sometimes you can’t increase productivity no matter what you try. It’s because, to use the classic example, the number of musicians Beethoven needed to play one of his string quartets back when he was composing is exactly the same as the number needed today, when he’s decomposing.

Baumol’s disease is an example of “market failure” — situations where a marketplace fails to efficiently allocate goods and services.

Which has what to do with managing IT?

I’m glad you asked. The answer is, nothing at all, if you’re among the enlightened IT leaders who have rejected what used to be considered best practice: Running an IT organization like a business — like an independent supplier delivering goods and services to its “internal customers.”

But like it or not, sometimes IT is stuck in the role of internal supplier. If you’re among the stuckees, and don’t have a clear path to unsticking yourself, you have little choice but to treat the rest of the enterprise as the market you trade in.

If that’s your situation, it’s worth a bit of your time and attention learning some of the better-known causes of market failure, figuring out whether they might apply to your internal market, and if they do, what you can do to mitigate the effects.

Market Failure Cause #1: Baumol

Since I brought up Dr. Baumol and his disease, it’s worth thinking through how it might apply to IT. It probably doesn’t have much impact on application development, or at least, not yet — most app dev shops have a number of opportunities for improving productivity.

It probably doesn’t apply to IT operations, either: Few have taken full advantage of all opportunities to automate infrastructure management and administration, and that’s before the cloud comes into play.

But business analysts and relationship managers are a different story. A lot of this work is person-to-person, and there’s a limit to how much you can compress conversations without losing the point.

Market Failure Cause #2: Monopolies

Market economies rely on the effects of competition to achieve efficient allocation of goods and services.

But internal IT isn’t supposed to have competitors. In this it’s like modern-day power companies, or perhaps urban cable service providers.

In the world at large, society deals with monopolies by establishing regulatory bodies such as public utilities commissions, which establish rules, regulations, and rates that give consumers roughly the same prices and quality of service they’d get if it was possible to avoid having monopoly providers.

Traditional IT has used much the same approach, setting up IT steering committees to allocate IT services.

It’s possible to avoid this path to unpopularity through the use of charge-backs, also known as transfer pricing. Whoever has budget can use it to buy IT services from the IT service catalog. Which seems much better, except that all this really does is move responsibility for IT resource allocation upstream to the corporate budgeting process, which achieves the near-impossible feat of being even less popular than IT’s governance processes.

IT can de-monopolize itself, though, by encouraging what’s usually called “shadow IT” — information technology implemented without engaging IT’s services at all. This increases the number of information technology providers in the company, creating true competition.

This doesn’t have to become a free-for-all, either, although this characterization comes up just about always when I recommend promoting shadow IT.

What’s needed is what happens in non-monopolized marketplaces. Take, for example, the construction business. There’s plenty of competition, but it isn’t a free-for-all at all. What keeps it all in check is a regulatory apparatus that establishes the rules all builders must adhere to.

IT already has an equivalent regulatory apparatus — its technical architecture function, which establishes the standards to which all production information technology must adhere.

Baumol’s disease and monopolies are only two of many market failures. Email me with your favorites (or, even better, leave a Comment) and next week we’ll pick up where we’re leaving off.

Somewhere in the business you support is a manager who needs to do things more effectively. The alternatives:

  • Shovel a request into the IT request queue.
  • Ask Clyde, who’s “good with PCs” to do something magical with Excel.
  • Bring in a local IT services company to build a system that helps do things more effectively.
  • Find some inexpensive off-the-shelf software that will help do things more effectively, then badger IT into allowing its installation.
  • Contract with a SaaS vendor whose software will help do things more effectively and don’t tell IT anything about it.
  • Sigh a great sigh and give up on making things happen more effectively.

The first bullet is The Right Way To Do Things.

The remaining bullets are all some form of end-user computing (EUC) or the dreaded shadow IT.

Except for the last bullet, that is. The Great Sigh is a key reason entrepreneurships are able to beat, or at least hold their own against their giant competitors.

Let’s add a dimension to this mess exciting array of alternatives: The backbone and hub of your enterprise technical architecture is one of the major commercial ERP suites. What the manager needs would, most logically, be implemented as a customization to one of the ERP suite’s modules.

Nope. Can’t have that. So option #1 — the right way to do things — is off the table, leaving only end-user computing (EUC), Shadow IT, or sighing deep sighs on the table for our sadly un-mythical manager to choose from.

Compared to the rest of the population, KJR’s readers are, disproportionately, metrics nerds, so let’s add a nerdy metrical dimension as well.

The metrics your average business manager cares about in this situation are, in descending order of importance:
1. Cycle time: Start the stopwatch the moment the manager first develops a reasonably clear idea of what’s needed. Stop it when the software is in production and the manager’s employees are doing things the new way. More than anything else, managers want this cycle time to be short.
2. Quality: No, not being bug free, although that’s nice too. Quality isn’t just the absence of defects. It’s also adherence to specifications – whether the software does what the manager needs it to do. By this definition, the plain-vanilla version of the ERP suite’s module is a low-quality solution. It doesn’t do what the manager needs it to do, because if it did, the manager wouldn’t be submitting the request. Q.E.D.
3. Fixed cost: This is the initial spend – how much the manager will have to pay for the solution. This matters because above a certain amount the software becomes a capital acquisition, which means the manager would have to go through the company’s CapEx approval process … a governance process that makes the IT request queue seem downright friendly and inviting in comparison.
IT’s priorities, presumably reflected in your company’s IT request governance, are quite different, usually along the lines of:

1. Financial Value: Amortize the fixed project costs over some reasonable number of useful years of software service. Add the expected cost of ongoing maintenance. Subtract from the business benefits that will come from doing things the new way. Divide by total cost to turn the result into a percentage. (Yes, yes, multiply by 100. Don’t be pedantic. Oh, I forgot — you’re a metrics nerd too. Okay.)

If the result is a positive number, rank it against all the other requests that have to compete for IT’s time and attention.

2. Political Value: Don’t be shocked. Also, don’t be outraged. The Financial Value undervalues a lot of what are, in polite company, called “intangible benefits.” (In less polite company they’re called “warm fuzzies”; also, “Don’t be ridiculous!”)

As minor matters like customer satisfaction usually fall into the intangibles bucket, there’s often value in political value — for someone standing up for what matters most, even if it’s hard to put a number to it.

3. Strategic Value: Some projects are part of the strategic plan — they advance the strategy. Others aren’t part of the plan but they are consistent with strategic intent. There are no others — any manager worth his or her salt knows how to write the obligatory two-paragraph account of how their pet project fits into the company strategy.

Compare the two sets of priorities and it should be clear why, for most managers, and especially for smaller efforts, EUC and shadow IT are the preferred ways to go.

Doing things the so-called right way might make a manager a good corporate citizen.

But EUC and shadow IT are what get the annual bonus.