IT is part of the business, but not for the reasons you think

A colleague of mine, Gabriel Morgan, pointed out a recent Infoworld article by Bob Lewis called “Why running IT as a business is a train wreck waiting to happen.”  So, I read the article and while I agree with some of Mr. Lewis sentiments, his logical arguments are completely random and his conclusions are therefore without basis.  His article is one giant non-sequitur. 

In the article, Mr. Lewis points out that many IT groups have adopted the mantra of “running IT like a business.”  He goes on to indicate that this is a bad idea and quotes a few folks in interesting ways.  The logic of the argument starts to get really weird from there, completely failing to make connections.

Let’s take a moment to examine the logical argument that he made and see if it holds up.

• Assertion: Running IT like a business is nonsense.
• Evidence: CIO complaint that IT cannot deliver competitive services: e.g. a $200 PC to a business customer  (won’t run his apps), or cheap file and print server hosting. 
• He then goes on to discuss situations where the IT department listened carefully to the customers and created bad solutions that met their needs exactly as described. 

Somewhere along the way, Mr. Lewis has implied something… that these two things are somehow related to one another.  He has assumed that “running IT like a business” is the same as “doing everything your customer asked, even if it is crazy.”

The kernel of the argument finally comes about half-way through.  Mr. Lewis states:

“When IT acts as a separate, stand-alone business, the rest of the enterprise will treat it as a vendor. Other than in dysfunctional, highly political environments, business executives don't trust vendors to the extent they trust each other.”

Mr. Lewis is not ambiguous in this statement.  If you run IT as a business, he says, you kill trust.  Why?  Because no one trusts a business.  They must be in it for themselves.  They must not be on my side.  Businesses are not to be trusted.  From a logical standpoint, A implies B.  Period.

Unfortunately for Mr. Lewis, it is fairly easy to disprove an implication like that… find a single case where A doesn’t imply B.  One single case is all we need.  With one case, the rule is broken… the argument becomes a fallacy.  That doesn’t mean that the conclusion is wrong.  It just means that the conclusion is not supported by the argument.  The conclusion could be correct, but not caused by the things he says are the cause. 

And this is why I had such a hard time reading this seriously flawed article.  I saw that the argument was a fallacy because I was able to disprove it almost instantly.  And I bet you can too.

Thought experiment:

Is there a business that you trust?  Any business?  Let’s say that you took a loan to buy your car.  You pay a fixed amount of money every month to pay off the loan.  You are doing business with that bank.

Do you trust the bank?  Technically, they could come and repossess your car at any time.  Yet, I’m willing to bet that most of my readers have gone all the way through a car loan without ever being in fear of repossession.  Why?  Because you TRUSTED the bank… as long as you paid your monthly payment on time, you TRUSTED that it was in their best interest not to repossess the car.

Here’s another case. 

Does your company use a payroll processing vendor to handle the payroll?  Many companies do.  After your company started using the payroll processing company, did a bad relationship result between your company and the payroll processing vendor?  I’m sure that happens sometimes, but given the fact that most companies are extremely loyal to their payroll processing vendor, it doesn’t happen that often.  The payroll processing vendor offers a clear and simple service.  The business buys it.  Everyone is happy.

Mr. Lewis goes on to dispense GOOD advice, but he does it in the name of getting rid of the BAD mantra of “running IT as a business.”  The good advice is good, despite the fact that it had nothing to do with the BAD things he pointed at. 

For example the article states:

Nobody in IT should ever say, "You're my customer and my job is to make sure you're satisfied," or ask, "What do you want me to do?"

Instead, they should say, "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done."

This is good advice. 

But the bad practice of “doing whatever a customer asks” is NOT the result of “running IT as a business.”  I don’t know of many businesses who run that way.  Let’s see if you do.  Thought experiment: Please provide an example of a business that you do business with today in your personal life that meets this criteria: you hire them to provide you a custom service.  You tell them how to provide the service, what the service will look like, all the features and aspects of the service, and then you ask them to operate the service indefinitely while you complain about the cost.

Go ahead.  Name a single business in your personal life that runs that way. 

What really happens?  Let’s see.  You go to a car dealership and you say “I want a car.”  The dealer asks some questions and then points you to one of their STANDARD services (one of their five car models) and then tells you how that model will meet your needs.  They don’t offer a car with five wheels or three engines.  They have a set of products and they help you to pick the best one.

Let’s consider another business, a service business.  I pay my cell phone bill every month.  Sometimes it costs more than others.  If I look at my bill, I may see that I downloaded ringtones, or went over my allotted number of minutes.  The service is custom: after all, I got different services than my neighbor, right?  Not really.  I got different Quantities of the same services.  The services were standard.  What varied were the quantities.

Here’s another example: go into a restaurant.  Buy dinner.  When the bill comes, ask the restaurant to break down the costs of the bill.  Let’s say I take my wife to a nice steakhouse.  We spend $100 on a nice dinner.  When the waiter brings me the bill, can I send it back and ask the business to tell me where every dollar went?  Can I decide not to pay for the bathroom (after all, I didn’t use it)?  How about the fees that the restaurant pays for health inspections?  Can I choose not to pay for that?  No… because I got $100 worth of value from my experience.

That is what it means to “run IT as a business.”  It means to make sure that the business gets value out of their experience.

In Microsoft, we have more than one IT group.  We have several.  I watched an excellent example play out that I’d like to share… one which shows the value of “running IT as a business.”

In three separate IT groups, we were doing eCommerce in different ways.  One group (team R) had a single storefront, and they did their billing through an agreement with Cybersource.  In another group, (Team O), there was a nice platform for building eCommerce sites that was used by about 20 different areas of the business.  You could build a front end, shopping basket, and checkout process for a flat price and the team took care of all the backoffice stuff for you.  Your business got all of the revenue minus the service charges that the bank charged.    In a third group, (team C) an independent business unit had created their own eCommerce system that did only the credit card billing but none of the front-end work.  This one charged its customers on a per-transaction basis.

Over the years, these different teams would compete with one another.  Every time a new business need arose for eCommerce, that business could visit each of these three different groups to ask what they did.  Most folks don’t want to create an eCommerce platform so there is a built-in incentive to reuse things.

All this played out over nearly a decade.  Nowadays, one team has become the clear winner.  Nearly all eCommerce in the company goes through it.  The other two still exist, but not for long.  Both are on the way out. 

Did the survivor have the best platform?  Nope.  It was not the most reliable.  It was not the one that handled the most currencies, or ran in the most countries.  It was not the easiest one to build to.  So why did it succeed?

I believe it was because that IT team had a very simple model for offering themselves as a service to their business customers. 

Basically, any business in the company could use that particular platform for a transaction fee.  But it wasn’t an accounting nightmare.  There are no bean counters.  No complex charge-back schemes.  It is much simpler than that. 

Each business unit answers two simple questions at the beginning of the budget cycle: (a) which of the three standard eCommerce services do you want to buy, and (b) how many transactions do you estimate you will incur?  That’s it.  With these two variables and a little simple math, each team would PREPAY for all of their eCommerce services for the year.  Easy to budget.  All the “rules” fit on a single page.  Nothing complex.  Estimates were based on last year’s numbers, so it was pretty tough to “intentionally underestimate” the transactions.  All the differences ended up simply washing out. 

But what if you are a business customer of the eCommerce service and you want some changes?  You want the eCommerce team to add a feature?  Go ahead and ask.  It’s a software project, and you will still pay for the changes, but the interesting thing is this: the changes ended up being subsidized.  You see, the program made a small profit on the sale of per-transaction fees.  They used that profit to subsidize the change requests, so that each change request ended up costing far less than a typical IT organization would charge. 

It is easy to compete when you do a little creative cost-shifting.  That is how businesses actually run:  Standard services at Reasonable prices.  Solid value that is clearly articulated.  Understandable billing.  Good customer service.  Oodles of cost shifting. 

Successful businesses run that way.  Apparently, so do successful IT services.

The per-transaction fees were easy to understand and, like the $100 dinner, were not cheap but were worth the cost.  More importantly, that IT team did not divulge every detail of the costs to their business customers.  There was no need to account for the cost of architecture and the cost of project management and the cost of hardware as separate line items.  The customer never saw any of that.  Customers saw the cost of something they could perceive as valuable: the cost of the transaction.  Everything else was hidden.  Just like I may pay for the steak dinner, and the restaurant would pay for the cook and the electric bill, the customer of the eCommerce service paid for the transaction and the IT team would use that money to pay for the architect and the ESB bus.

That is what it means to “Run IT as a Business.” 

All I need is one case to disprove the logical argument that Bob Lewis presented in his InfoWorld article, and I had found it… many times over.  Mr. Lewis’ argument is flawed because Mr. Lewis seems to ignore the way businesses actually run.