Most of the time, as a consultant, I was brought in to correct the mistakes or omissions that were made by the off-shore developers. First off, why would an IS manager choose to use a company from a foreign country to develop a software product for their company? The one overwhelming reason that comes to mind is cost. Pure and simple, as far as hourly billable rates go, offshore is far cheaper, sometimes less than half the cost of native talent.
So why doesn’t every company use offshore?? Well, as my father (and I’m sure your father) said, “You get what you pay for ...” Meaning the quality of the end product leaves much to be desired in many offshored software projects. And there are a number of reasons, tangible and intangible, for this lack of success.
Over my long career, I’ve worked on a few projects where the business users have performed the long and arduous task of putting together a detailed and complete set of requirements before we started writing a line of code. This has been the exception though, most of the time I get a couple of emails, maybe a fax or two and if I’m lucky a wireframe design on a cocktail napkin. From these “requirements” I’m to create a complete and working piece of software that fits the business needs of the client.
Offshored projects must have complete requirements defined and detailed, because the client has probably never met the actual people who are writing the code. They work in a vacuum and produce what their bosses tell them to write. I don’t want to use the words “Assembly Line”, but Henry Ford would probably approve of their approach.
In order to have a successful software project, communications between the developers and the business users is essential. Even if you have the best requirement documents in the world, there are still going to be questions and areas in your application that will need further discussion and design. Although the offshore companies are getting much better with communications, there are language barriers, time-zone differences and discussions that are better done locally. If you want a screen that records name and address information, if your requirements don’t specify to validate the zip code, then the offshored code most likely won’t validate the zip code.
There is nothing more productive than a well-managed white board session with the business users and the developers hashing out the details of a complex business process. Hard to do when you are 3000 miles away, even with Skype.
Even though the hourly cost for offshore coders is much less than local talent, eventually the project will be delivered and your in-house staff will need to keep the applications running. In most cases, there are major corrections and additions that will need to be done because of missed features and incorrect code.
You’ll eventually want to bring in the original developers to add new features or fix some complex code or cross-train some new in-house staff, try and find the original developer from an offshore company six months down the road.
These are just a few considerations when you are looking to save some money by offshoring your software project. The few projects that I’ve seen that were successful using offshored have been projects that have used a mixture of local talent and off-shore coders. Use the local talent for project management and more complex tasks that need lots of Business User interaction and use the off-shore company for the more routine and simple tasks that every project needs. Just make sure your Project Manager likes to get up at 3:00AM for those wonderful conference calls.
Stephen Hill, Senior Software Developer/Architect, Orange County, CA