eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Like any other IT novelties, outsourcing and its cosmopolitan cousin, offshoring, have gotten much more than their Warholian 15 minutes of fame.
In the quiet that follows the echoes of overstated cost-reduction projections and apocalyptic predictions of the death of U.S. programming skills, software development teams should seek a more accurate perspective.
Yes, some developers should fear todays expanding international market in code writing—but only about as much as they should fear each new generation of freshly minted code-school graduates or each new wave of user-oriented application development tools.
Developers whose technical skills are aging, whose interest in their organizations mission is lukewarm, and whose problem-solving and communication skills are weak cannot expect to compete against the lean and hungry.
New talent will always be ready to apply more productive tools in more creative ways, guided by a brighter and clearer picture of the organizations needs—but thats nothing new, and it doesnt mean that outsourcing and offshoring have changed the fundamentals of economics.
Team leaders and business process owners should eye with suspicion any promise that outsourcing and offshoring will yield durable reductions in development costs or an indefinite edge in quality without corresponding stretching of budgets and schedules.
Markets may briefly yield such gifts following sudden changes in the supply or the mobility of a resource, but free markets in the long run invariably seek and find equilibrium.
A survey performed this year, for example, by Hewitt Associates LLC, found that salaries in a range of industries in India were on track with Hewitts previous projections for 14 percent annual increases during this year and continued growth at a similar rate through next year.
Figures compiled by AMR Research Inc. suggest even more rapid India salary growth rates: as much as 20 percent per year for college-educated workers during 2004.
One must not assume that U.S. coders salaries are merely holding still, although some might argue that theyre static or even (in real terms) falling.
But even at a differential growth rate of only 10 percent, for example, it would take less than two decades to close the commonly estimated sixfold gap between a software project managers salary in India and compensation for a similar job in the United States.
What many seem to be forgetting, meanwhile, are decades of knowledge about nonuniform distribution of skills within either a project team or a regional work force.
Norman Augustine, the former head of Lockheed Martin Corp., noted among his oft-quoted “Augustines Laws” that in a wide range of occupations—from research scientists to professional football players—the top fifth of any group does about half the work and the bottom half does about one-fifth of the work.
Taking these numbers just a little further, one might calculate that a 20 percent loss of performance among just the top fifth of a team is enough to cancel a 50 percent performance gain (or a 33 percent cut in hourly pay) for the entire bottom half.
If the performance of a project teams leaders is only somewhat hampered, therefore, by language difficulties, time zone differences and other factors, there may be surprisingly little net gain for the project as a whole, despite the project accountants pride at hiring rank-and-file workers at lower offshore wages.
Augustines asymmetries most likely become even more distorted in software development efforts. Barry Boehm, in his definitive 1981 book “Software Engineering Economics,” concluded that a developer team drawn from the top 10 percent of the skills range will be about four times as productive as a team from the bottom 15 percent of that spectrum.
If it costs three times as much per unit of effort, therefore, to hire the best and give them optimal working conditions—including prompt and effective communication with business process owners—then the result may still be considerably better value.
In short, to play the defensive game of trying to find tolerable coding talent for less money is an inferior strategy compared with finding the best available talent and paying it what its worth.
That doesnt mean that outsourcing and offshoring are never good ideas; it does mean that these things should be done for the right reasons and in the right way.
Next Page: Evaluate a prospective partner with care.
Evaluate a prospective partner
with care”>
In many cases, one goal of an outsourcing strategy is greater flexibility in ramping effective team size up or down.
Ironically, though, its important to evaluate a prospective outsourced development services provider at least as carefully as one might evaluate a prospective permanent hire.
By the time an outsource relationship has hit its stride, a client company will invest a lot in bringing that services provider up to speed. To do that again and again is a quick way to offset hoped-for savings with repeated startup costs.
Perhaps it would be even more accurate to think of choosing an outsourced services provider as being more like forming a professional relationship than like merely hiring a laborer.
The communication overheads of working with an outside company should be offset by the pool of expertise on the other side of that boundary. If anything, an outsourced services provider should perhaps be able to teach the client some new things about best practices in an industry.
At the same time, though, a prospective client must wonder if the services provider is promising value tomorrow that will come at the expense of the clients of yesterday.
If a services provider is promising the benefits of a portfolio of industry-specific tools and data, one must wonder who really paid for that R&D. Will competitors be next in line to be pitched a still-stronger portfolio, a year or two from now, that will have been developed at your expense?
Ownership of work products and terms of use extending beyond the term of a service relationship should be discussed and formalized at the beginning of a relationship—not at or after its end.
Another thing that needs to happen early on is an effective trial run of a services providers processes and personnel—while theres still time to discuss improvements or seek alternatives.
If one doesnt really begin the process of seeking an outsourced development contractor until a massive, critical project creates an urgent need, its going to be much harder to be a discriminating buyer.
Once work is under way, its essential to distinguish between paying for effort and paying for results.
Just as competent in-house project management compares costs against progress based on objective milestones, its even more important for outside services providers to know that their progress—not their promises—will be the basis for intermediate payments and performance incentives.
Again, this implies a need to develop and solidify a service relationship during a time when the provider knows that you can afford to look elsewhere.
Finally, its just as critical to think about an entire development life cycle when an outside development services provider is involved as when an in-house team is doing the work.
In fact, its at least twice as critical because there are two interlocking cycles to consider. There may be future support or application enhancement that is appropriate to get from the same people who did the original work, assuming that the quality met the buyers expectations and that the time frame of the needed additional work is compatible with an outside contracting process.
At the same time, though, there may also be follow-on work thats either too sensitive or too urgent to do outside, in which case its crucial that in-house staff have all the needed intellectual property at hand.
Development managers have no one but themselves to blame if outsourced or offshored development turns out to be a proposition of getting “less for less.” Its unrealistic, moreover, to hope in the long run for a continued stream of “more for less.”
Good value, in the long run, comes from paying for what one gets—and a good outsourcing relationship is one in which no one is badly surprised by either whats paid or whats produced.
Technology Editor Peter Coffee can be reached at [email protected].