Why Offshoring Will Always Be a Novelty, Never a Valuable Strategy

By CIOinsight  |  Posted 05-25-2005

Why Offshoring Will Always Be a Novelty, Never a Valuable Strategy

In my last columnI explained the obvious, if mostly ignored, reason why so many significant development projects fail.

At its most basic, the problem boils down to the refusal or inability of developers and their managers to adhere to commonplace quality control and documentation procedures that have been proven to result in better products, lower costs and fewer delays.

The chronic overruns of time and resources that blight the average unstructured corporate development project leave hapless or helpless managers with two main alternatives:

  • Fix their hiring, their staff of programmers, their methods, their procedures, their management practices, and invest in training; or
  • Buy work from outsiders with a quality requirement that approximately matches what they are already delivering, but at a lot lower cost-per-hour, and hope the benefit-cost of the lower ceiling on quality hurts the value less than the lower price helps it.

    The first is the professional approach, the second the response of an amateur throwing up his hands because he doesn't know what else to do. Prayer rug time. The lack of skill and discipline among most development management doesn't excuse this abrogation of responsibility.

    But does it always fail? Is it really so bad?

    It doesn't always fail, but it's always bad.

    There are two reasons offshored developers and help desk people have a quality ceiling that's too low for any organization that can only succeed with quality that's adequate or better.

    (Some organizations depend totally on volume, or come to the table with such overwhelming superiority of force in sales and marketing that they are exempt from ordinary quality requirements; think monopolies, organized crime, WalMart and the U.S. military).

    The first fracture point is proximity.

    You can collaborate with someone in a different location, but you can't know a user's work and how he or she views it if you're not immersed in it; and you can't be immersed in it if you're not physically present. You can't learn it through e-mail, screen sharing, screaming video, cell phone voice dialogue or a collaborative software client.

    That ignorance simply cannot be overcome with technology. Which is not to say that legacy practices were any better. There are plenty of shops that had developers on the same floor of the same building who didn't bother to immerse themselves in the work they were enhancing or automating.

    It's a rare application developed with that missing ingredient that doesn't sap productivity, however. Losses come in the form of missing features and late changes to specs, steep incremental training efforts, user discouragement or resistance, and large numbers of avoidable updates or patches.

    The other fracture point is culture. And culture is really two different related things here: Departmental and regional.

    People who build products of any sort who don't share the culture of the specific department that will be using the product will miss subtle features or areas of concern.

    Like physical hand tools that are designed for right-handed people but sold to left-handers, there will always be some loss of effectiveness and occasional damage to the user.

    The entire repertoire of behaviors that constitutes the cultural norm for a factory floor is, in most ways, not just dissimilar but antithetical to the repertoire of development groups' behaviors, for example.

    Culture, much of which relies on shared perception, can't be transmitted without proximity.

    The last big project I worked on was located in Seattle and the development team was in Cleveland. Every subtle aspect they missed turned into a potential change order item. As good as they were - and they were good - they missed plenty.

    When you move development offshore, you add the other cultural issue: Without a native context, little facets of behavior don't fit snugly together.

    Everyone sentient who's ever traveled overseas has noticed this; have you ever tried to make a phone call in Kenya or France?

    The cultural differences between regions enrich our lives as humans, but degrade our ability to craft tools for someone from another region.

    Next Page: Localization is more than a feature.

Localization is More Than

a Feature">

Here's a software usability example: For users whose language flows bottom to top, menu bars in software should be at the bottom. How many developers, regardless of intelligence and determination, know that?

Oddly, intelligence and general education level doesn't trump cultural immersion when it comes to tool building.

I've worked with development teams from India and Eastern Europe. In each case the developers were "better educated" by my own standards (history, science, literature, geography, social sciences, art) than their American counterparts.

They also seemed generally more intelligent, though that may just have been my own bias, generated because they were better educated.

In spite of that, the offshore programmers are almost all missing the culture of programming that's developed in mid- and large-sized American organizations over the last 35 years. Without exception, they failed to understand the importance of documentation, QA, usability, and a half-dozen other project essentials.

That programming culture (like all cultures) involves residual knowledge of things that were tried and discarded for good reason; it includes an awareness of which methods work well alone, which work well only in combination with other methods; of things (like structured techniques) that everyone knows will work, but which they won't use because of dysfunctional external pressures.

Even the better-educated and more sophisticated offshore workforce can't deliver better products, largely because they didn't learn to program within an evolving environment made up of the perceptions of both developers and the people who would eventually use the product.

Just as the best American auto-workers can't build Cadillac SUVs that will become best-sellers in Venezuela, and the best American McDonald's kitchen help can't build cheeseburgers that will become best-sellers in India or Iran, quality procedures in offshore development operations can't overcome lack of immersion in the user's environment and more general differences in national culture.

There's no amount of labor-cost cutting that can balance this equation. Those who think differently are just fooling themselves.

It just doesn't pay to offshore development no matter how great your passion for cutting labor costs.

The ugly alternative is that you have to become more disciplined, clean up your own processes, invest in training and hire locally.

It's the only alternative.

Jeff Angus is a management consultant and has been working with IT since 1974. He has held IT management positions in user interface design, marketing, operations and testing/analysis. Look for his book, "Management by Baseball: A Pocket Reader." Jeff's columns have appeared in The New York Times, The Washington Post, the St. Louis Post-Dispatch and the Baltimore Sun.

Check out eWEEK.com's for the latest news, reviews and analysis on IT management from CIO Insight.

Read part 1 of this article to see Offshoring, the Self-Inflicted Wound.