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.

Why should an IT organization ship work offshore?

Certainly not because the work is “not core,” — the answer offered up by the popular but not-very-useful “core/context” theory that’s too-often used to make this decision.

The core/context theory’s deficiencies have been explored in this space often enough that wary readers might be wondering if yours truly has anything to offer beyond criticism. Yes, I do … while criticizing others is more enjoyable and less risky than offering an alternative, it just doesn’t pay the bills.

So if the core/context theory provides the wrong criteria, what are the right criteria? Here’s the starting point: “What should I send offshore,” asks the wrong question. And when you ask the wrong question, even the best answer is misleading.

What you need, that is, isn’t an offshoring strategy. You need a sourcing strategy — one that takes into account the full range of choices available to you to staff the different kinds of situations you face running an IT organization.

And you have a wide variety of staffing resources to choose from: Employees; consultants (defined here as outside experts brought in because of their special knowledge); contractors (non-employee staff brought in to perform day-to-day tasks); on-shore, off-shore, and multi-shore integrators who provide multidisciplinary teams to execute projects on your behalf; and outsourcers of various stripes to take over ongoing functional responsibilities. Each has its own characteristics, which suits it well to some staffing situations and poorly for others.

So here’s the plan: Make each of these staffing sources a column in a matrix. The rows are the characteristics used to match sources to situations. Score each cell using a ranking ranging from strongly disadvantageous to strongly advantageous. At IT Catalysts we use a –2 to +2 scale for this purpose; others prefer 0 to 5 or High/Medium/Low. Whatever works for you.

Different companies will fill out this matrix differently. The cost of internal employees is lower in Altoona, Wisconsin, for example, than it is in downtown Manhattan; if you’re a giant multinational corporation you have economies of scale internally that you don’t have if you operate a half-dozen retail locations. What’s important is that you understand how well each available source scores in each of these characteristics for your organization (and whatever others apply to you that aren’t listed here).

Then, when the time comes to match sources to the requirements of a specific business situation, you can choose the source that best fits your characteristics and specific situation.

When you choose a piece of software, you assess its fit with your requirements — it’s a complex, in-depth process that requires serious effort and analysis.

Why would choosing a source of staffing call for anything less?