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

By CIOinsight  |  Posted 05-25-2005 Print Email

Opinion: Distance and difference do more than make managing offshore development difficult. They make it impossible to give developers a tight-enough grasp on user requirements to make good software.

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.



 

Submit a Comment

Loading Comments...