Low hourly rates and technically well-trained programmers are tempting European and American organizations to have their major software development projects done in less developed countries. Some organizations have been pleased with the results, while others have regretted their decision. Some who were pleased upon initial software delivery, have grown disenchanted with the ongoing maintainability and reliability of the software.
There's nothing new in that, of course. We've grown accustomed to project fiascos, whether contracted to a development firm in the same city or to the in-house group in the same building. Unfortunately, however, many of the risk factors that apply to all projects are magnified when development teams are located halfway around the world, and the penalties for failure are much higher.
This article suggests some precautions a wise manager should take when considering an offshore development contract.
There's no controversy about hourly rates. They're a lot lower in less developed countries than in industrialized societies.
But how do hourly rates translate to labor cost? We know that programmer productivity within developed countries spans a 20-to-1 range. A typical large organization's most productive programmer can accomplish in an afternoon what its least productive programmer may spend a couple of weeks struggling with.
But that's not the whole story:
Thus it's possible, even likely, that the true labor cost using a half dozen of the very best American or French programmers will turn out considerably lower than using a team of 12-20 randomly chosen third world programmers, even though their hourly billing rates are more than an order of magnitude higher.
How can you find out?
The one thing we know is that we shouldn't rely on a broker or a body shop to identify top performers or to assess either productivity or work quality. Just as in this country, such firms have little to gain by stressing productivity.
It's up to the contracting firm to show that your project cost will be lower. If they submit a fixed price proposal to develop a well-defined software product, then you can make comparisons. On the other hand, if you're contracting for programmer time, you'll need to assess the programming talent that will be assigned to your project.
We've all been impressed by the technical competence of programmers from such places as Russia, India, and Ireland. Now more and more countries are getting into the software development business, offering a high standard of individual knowledge and experience.
But isn't there a lot more to programming than a technical command of various tools? Many of the same programmers who dazzle us with their mastery of Java's CORBA interfaces, C++'s STL iterators, or sophisticated search algorithms haven't a clue about such software engineering essentials as:
In recent academic courses, I've encountered students who were fiercely proud of their earlier computer-science education in another country, and were astonished (or worse) to discover that just getting a program to work doesn't earn them an A on an assignment. Presumably these students attended the same overseas schools as the contract programmers you're going to be using, and, having come to America, they're probably among the best graduates.
Of course, I also encountered others who had a thorough grasp of those essentials. They tend to stay in the United States.
It's reasonable to conclude that the calibre of computer-science instruction in all countries is highly variable, and that many overseas instructors (like many of their counterparts here) lack an appreciation of software quality. Their students are unlikely to get much guidance from them beyond how it works.
Alas, the notion of defining what we're going to build before we build it is once again out of fashion. Incremental development has replaced rigorous systems analysis and specification in the thinking of many current "experts".
Unfortunately, as many organizations are rediscovering, incremental development works well for small projects but can break down altogether for major projects. When the project team discovers a crucial omission from the database after they've written a lot of code, there may be no simple "increment" that will fix the problem. Specifically:
While we never propose to freeze the specifications, we do the best we can to define completely and unambiguously what the new application is to do.
Experience keeps showing that inadequate specifications are one of the two most common causes of failure in large projects. By "specifications" we don't mean internal design or system architecture. Developers need to know what the application is to do; we can trust them to determine how it should be built.
When the programming is to be done far away by people we don't know, the possibilities for misunderstandings are multiplied, and the time it takes to discover them is extended. Easy access to the same computer network on both ends may help, but it still isn't like working with people we see every day.
With solid specifications it's also reasonable to negotiate a fixed price contract. A highly professional programming staff confident of its skills should actually seek such contracts. Then you won't have to worry about labor cost at all, but of course timeliness and quality remain important concerns.
What if you don't have rigorous specifications? You can engage a systems analyst to help you prepare them, but he or she will need to work closely with your people. I haven't heard of anyone contracting for systems analysis services in another country.
If inadequate specifications are one of the two most common causes of failure in large projects, what's the other one? Insufficient detail in the project plan.
When you use overseas programmers you're probably not dealing with a body shop. You're not making detailed assignments to individuals, but are relying on a local project manager at the programmers' site to handle the details and to deliver agreed upon results at an agreed upon time for the agreed-upon price. In theory, then, day-to-day project management isn't your concern. However, unless you have the highest confidence in the contractor, based on proven performance on earlier projects, you should insist on reviewing the project plan, making sure that:
Since it's almost always possible to say something positive about the status of a project, free form status reports (or "status meeting" minutes) are the enemy of project control. Don't accept them at any level. (Does anyone still hold status meetings?)
You need early warning of any time slippage or cost overrun, in order to take timely corrective action. In particular for the routine (at least weekly) status reports from the project team members, make sure that:
English is well established as (a) the language of business, (b) the language of computing technology, and (c) everyone's preferred second language. Nevertheless, when we're dealing with people whose native language is not ours, we risk misunderstandings in both directions as well as poor documentation.
Of course, English is an official language in India, Ireland, and some other countries we're going to be dealing with. There we can safely depend on a solid grasp of idiomatic English. Elsewhere, we take more chances.
Whether we're evaluating programming skills, project management skills, or command of written English, there's no substitute for looking at actual work products. A development organization in any country ought to be proud to show a prospective client samples of its work and its internal methodology.
Nothing in the above advice is much different than for a critical project done in-house or through a local contractor. But when you're dealing with people you don't know, who come from a different culture, and whom you don't see regularly, the penalties for not following these common-sense disciplines are that much higher.
I'm still impressed by the capabilities of many programming groups in less developed countries. I wouldn't hesitate to engage the best qualified ones to do an important complex project, but I'd take all of the above precautions.
Return to management articles
Return to IDI Home Page