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.
Decomposing…… ugh, punny.
Interesting articles by you and George Will. But you don’t say what the metric is to determine productivity.
When I think of IT, I see 3 main functions – 1. Maintenance (of the computer infrastructure). 2. Business advisory and education at both the management and non-management levels. 3. Software development, which is, at worst, a craft, and sometimes, an art.
In my view, software development succeeds in direct proportion to how appropriately customized it is to the situation(s) it was created for. The economics of crafts people and artists, to the best of my knowledge, has always been different from economics of producing standardized goods for exactly the reasons stated by you and Will.
Perhaps people are using a light meter to measure the length of a football field when critiquing IT productivity.
Fraud. Markets have issues with fraud and lemons. The two are related to an extent, except the former is worse. Witness VW cheating emissions tests using software. We’ve already discussed commons, but that’s another topic.
I also like Brook’s Law: adding more “resources” (Oh how I hate that word!) to a late project will make it later.
Then the law of common sense: You cannot make a baby in one month by assigning 9 fertile women to the birth project.
I like your baby example better than the string quartet for illuminating the meaning of Baumol’s disease.
Back in Beethoven’s day, it did require four musicians to play a quartet, any time someone wanted to hear it. However, due to “IT” innovations, today people can play a recording on demand instead. Music productivity has actually shot up astronomically.
We still can’t produce a baby in a month, though. Maybe in a couple hundred years, I don’t know.
As for business analyst relationships – there are methods for capturing the required information that are more efficient than others, although Bob is correct that the conversation can only be made so efficient. The distribution of the information captured can probably be improved. It’s helpful to have that person-to-person relationship from business to IT, but the IT analyst will likely need to share the info with multiple IT personnel – and one-on-one convos are probably not the most efficient there.
Sometimes IT analysts are embedded in the business area, for even better and more efficient communication and understanding. Sometimes the business analyst is brought into IT. I expect there are additional solutions no one’s thought of yet.
I doubt there’s a “one size fits all” solution, so at any given time any given organization might not be employing the most efficient/productive relationship (maybe they’ve outgrown their old one, or their current employees don’t fit well into the model developed by previous ones).
PS: You might want to fix the couple of “Baumal” mispellings to “Baumol”. I hadn’t heard of him before, so originally I wasn’t certain which spelling was correct.
Fixed. Thanks.
It takes a great deal of savvy on the part of IT leadership, but if the focus of the IT leaders is on creating bigger bonuses for the people who run the company, budget will not be an issue.
To turn to the 2nd week of an elementary economis course….by definition a ‘Market Failure’ is a violation of the assumptions of the neoclassical model of an economy. And the one violation that nobody wants to talk about is ‘Perfect Information’.
But, we don’t need to talk about the information failures outside of our company/department/workteam. Mgmt. is busy requiring us to hide information. Such as: The real cost of projects. The real effort spent on a specific project. What the real 6 month plan is. I once worked at a place where the Org. Chart and pay grade ranges were considered ‘confidential information’, not for ordinary employee’s eyes.