Not all that many years ago, a friend of mine bought a router. When he brought it home to show his wife, she asked, skeptically if it was really worth a week’s lunch money. So to prove its value he’d spend hours in his workshop, using his new router to build nifty items like chairs, tables, and lamps. (Now, of course, the wife is as likely as the husband to bring home a router. Usually, it has Wi-Fi built into it. But I digress.)

Routers are versatile tools. But not so versatile that they solve every problem. To pry the lid off the paint can or hammer nails you’d be better off with other gadgets. It’s a lesson some CIOs need to learn: Having adopted global sourcing as a useful addition to their IT sourcing strategies, they’re now trying to use it for every job in IT.

The problem is, global sourcing vendors aren’t well suited to every job in IT, and in fact some modern trends are converging that should aim wise CIOs squarely at local resources. These trends are the accelerating trend toward making use of commercial software rather than in-house developed proprietary software, the trend toward componentized software architectures, the increasing use of adaptive methodologies such as eXtreme Programming (XP), and the growing awareness that the proper goal of IT isn’t successful software delivery — it’s to collaborate in the delivery of successful business change.

One at a time:

When you buy commercial software, the tasks that remain are to adapt it to your enterprise and vice versa. That means process redesign for the business, configuration and customization of the software, and systems integration work. Sending any of this work offshore is an unnatural act, as the work is highly interactive and heavily dependent on the details of the situation. It’s on-site work, heavy on telephone calls and light on heads-down coding.

With componentized architectures, developers connect software modules that provide generalized business services to support business processes (yes, I’m oversimplifying, but for the purposes of this discussion it should be close enough). While the coding to create components might be accomplished by a global sourcing vendor, the use of the components is, again, light on coding and high on interactivity. Offshore? What’s the point?

Which brings us to adaptive methodologies. Whether you prefer XP or some other flavor, adaptive methodologies all embrace the idea of high interactivity, to the point of having business users looking over programmers’ shoulders during development. You could, I suppose, use NetMeeting to allow end-users to look over the virtual shoulders of third-shift programmers in Bangalore. But then, with enough effort you can make soy paste taste vaguely like hamburger (or so I’m told). That doesn’t make it a good idea.

Adaptive methodologies don’t achieve IT nirvana, though, because they’re still focused on software delivery. And software delivery is yesterday’s news. It used to define success for IT. Now it’s the ante that lets you into the real game: Changing the business.

The traditional methodology used to redesign business functions, business process re-engineering (BPR), closely resembles traditional IT “waterfall” methodologies (those that separate analysis, design and coding into separate sequential phases). Business re-designers figure things out, then let IT know what they need. This isn’t very different from having business analysts figure things out and then hand specifications to developers. Global sourcing can succeed with traditional BPR, because sequential methodologies with strong separation of function is their strong suit.

The problem is one we’ve known for at least twenty-five years but still pretend doesn’t exist: With waterfall methodologies you have to be right the first time, and nobody is ever right the first time. Business redesign succeeds best when it gets the initial elements of a new process into production and then continually improves it until it hums.

There are two ways to continually improve a business process. One is to assume the available tools are fixed and immutable — the machinery, work space, and information technology is what it is, and the process works within those limitations. With this assumption there’s no work to send offshore.

The other assumption is that everything is up for grabs — process flow, work space, information technology, training, and even product design. With this assumption the last thing in the world a business should do is to send the IT part of continuous process improvement half a world away. The proper solution is, in fact, the exact opposite:

Move programmers out of IT and into the business area where they can participate in the work.