% fortune -ae paul murphy


Last week's blog on not out-sourcing mission critical functions led to a particularly interesting talkback discussion.

At the top, Roger commented that Zdnet should out-source its servers and several others mentioned being unable to use talkbacks. I believe there's enormous frustration within the executive ranks at Zdnet over these failures - and that, sooner or later, they'll take the necessary steps to address them.

(As an aside, when Sun first offered a free server to people willing to implement and blog about it. I told the editor I work with that I'd be happy to convert blogs.zdnet.com to an all open source environment on a T2000 and then write about it as a reliability and performance demonstration, but, so far, his bosses haven't wanted to play.)

Next, Erik Engbrecht added a commentary that really set the tone for the rest of the on-line discussion by breaking out the situations in which out-sourcing is generally considered reasonable and then showing that these should not arise in a well run business.

The contrary position was clearly and articulately put forward by a "Paul C" who argued that out-source services suppliers can sometimes do a better job than the internal IT people.

I thought they were both right, because the question isn't whether out-sourcers are better where out-sourcers are better, but under what circumstances an organization is better off using an outsourced IT service.

And the answer to that, I think is implicit in the things Erik said in the first of his contributions to the discussion: fundamentally, out-sourcing is preferable only if management fails to deliver adequate IT services internally.

As part of that, here's his theory on why out-sourcing exists:

My theory is two-fold:

1. From the business perspective, Internal IT has conistently failed to make good on promises, so if someone is going to fail, it's better that they are cheaper and/or can be sued for failing.

2. From the IT perspective, those darn business people never give IT the respect it deserves, so doing IT in a non-IT company is a dead-end career. It's better to work in a company where my skill is core to the business.

In other words, IT people don't want to be outsourced, but they typically want to be the outsourcer. The reason being they don't get any respect from the business-side, because they fail to deliver on their promises.

In person he's probably a nice guy; I'm not, so let me put it rather more bluntly: outsourcing is a solution to internal incompetence at either, or both, the business and IT levels. Thus it's quite true that very few CEOs or CFOs credit any part of their organization's competitive advantage to IT, but that says a lot about them and nothing at all about whether IT should be handled internally or externally.

Indeed it's important to remember that IT is only one part of a larger organizational picture and that it's quite possible for an organization to grow and prosper despite providing itself with inferior IT support and services. In other words saying "this business out-sourced IT and prospered" isn't an argument either for or against out-sourcing, because there's no necessary causal link between the out-sourcing and the prosperity amd no evidence that they could not have done better yet had senior management paid adequate attention to IT.

In effect the analogy I used last week: that "passing information control to a third party is a lot like putting somebody else in charge of regulating your heart beat: useful in the short term if your heart is failing, but not a recipe for Olympic success"; is the right one because the question isn't whether the patient walks or jogs now, it's how fast that patient could go with a properly functioning heart of his own.

And I think that's the real bottom line: IT out-sourcing may look, to senior management, like an effective wayof firing the IT department without acknowledging responsibility for their behavior, but it is ultimately always an acknowledgment of their own failures in either refusing, or being unable, to manage IT.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues. Erik actually had the right answer to that hidden in his contributions. Erik, however, got it right