1. I can save 75% of my project costs by offshoring.
While this may be possible in some rare cases, the savings will be more in the 30 – 50% range. Although the hourly rates may drop from $100 – $25 / hour, there will be some additional overhead and travel expenses associated with the project.
2. Cost savings is the driving factor to go offshore.
Cost is certainly a significant factor but not the only factor. The choice of vendors is astounding and you can get access to very specialized resources that may be in short supply in the US. Offshore resources are more than happy to handle tasks such as maintenance, testing, porting, and data conversion which many US developers do not get too excited about. Finally, time zone difference can work to your advantage especially during testing cycles when issues can be fixed overnight. 24-hour shops can also take advantage of these resources for night and weekend application support and system monitoring.
3. Offshoring doesn’t make sense anymore with the falling dollar.
As painful as it is to fork over $20 for a beer in London, we aren’t exactly at the Peso level yet. The Indian Rupee, for example, has appreciated almost 20% against the dollar in the past 2 years. The 20% currency move has not directly translated into a 20% rate increase because most firms price in dollars (for now at least). While they may have moved their rates up slightly, the have also accepted lower margins due to the intense competition among firms.
4. There is a shortage of offshore resources.
India, China, and Russia alone have close to 10 times the population of the US. And the number of engineering graduates they turn out is well more than 10 times ours. When you consider that their domestic markets are small in comparison, there is plenty talent left over to serve multi-nationals and outsourcers. I was in India a few years ago, and the head of HR of the software company I was visiting realized that they needed 20 extra new hires to support the project. They put up a couple of posters at a regional engineering college intending to give aptitude tests to 1000 people, interview 100, and hire 20. Much to their surprise, 5000 people showed up to take the test! It’s worth mentioning that these 5000 people were all graduates of engineering colleges and had to compete with hundreds of thousands of students just to get a coveted engineering program spot. There may be turnover and competition among the best and the brightest but there is certainly not a shortage of talent.
5. I can successfully offshore any project.
False! There are some projects that just don’t fit the offshore model, and project size is the first consideration. As a rule of thumb, don’t consider offshoring any project that is less than 10 man months. Next, remember that anytime you use outside resources you need to spend a sufficient amount of time explaining and documenting exactly what you want. And then you need to explain it again and have them explain it back to you to make sure it’s well understood. All of this requires some additional overhead. I like to describe it as the ratio of explaining to doing. For example, if you are porting a system from one platform to another and need it work the exact same way, the explaining is minimal because you can just point to the existing system and ask for an exact copy. Testing is another good example because you explain the testing criteria up front and execute the tests dozens of time which is again a favorable ratio of explaining to doing.
6. India is the best or only place for offshore development
India comes to the top of the list for many reasons but it’s certainly not the only place. Russia, China, Eastern Europe, Israel, Brazil, and the Philippines all have thriving industries and combine a strong education system with a lower cost of living. There are several factors involved in picking a location including cost, maturity and variety of vendors, time zone, language skills, and the specific needs of the project. The vast majority of business applications move data in and out of a database and, while they require experienced and technical programmers, they do not require a great deal of scientific or mathematical skill. If your project requirements call for heavy use of algorithms, compression, low-level networking protocols, or embedded code, then some of those skills may be more available in Eastern Europe and Israel. In terms of depth and breadth of the market, India certainly comes in first. They have been serving US customers for a very long time; thus the industry and the execution processes are very mature.
7. The language barrier is an issue.
The language barrier is an issue but it can be compensated for. The nature of the project and the communication requirements absolutely should be a factor in selecting a vendor location. For typical business applications, heavier communication is required because the application is automating a business process which will need to be described in detail. In addition, business applications always involve user interfaces and it is difficult to have a conversation about subtle user experience issues with somebody who is not a native speaker. India is actually composed of 28 states and even more languages. When developers from all over the country get together, English is actually their common language. The accent and expressions take getting used to so it is best to have the project manager be accustomed to communication with the vendor personnel. Solid documentation and frequent milestone reviews also help complement the oral communication.
8. All I have to do is write a spec and send it to my developers.
I wish it were that easy. This is the exact reason why most projects fail. While porting and data conversion projects may be exceptions, business application projects require extensive documentation and proactive management. I have personally written specs that I thought were comprehensive enough to speak for themselves. On one of my very first projects I sent my 50 page masterpiece complete with examples, screen shots, logic diagrams, and even a database design and was upset when the development team didn’t start coding the second I sent the email. But when I went overseas and sat down with the team (meaning the developers themselves that would actually be doing the work), I was amazed at how easily two experienced people could interpret the same sentence in radically different ways. A detailed spec is a very necessary first step but it must be followed up by an execution plan that tightly manages progress and ensures that what is being developed matches up well to what the business requires. This is where the real work begins.
9. My data and intellectual property will not be secure.
This fear is not uncommon. The reality, however, is that the biggest threats are internal resources, not vendors. Moreover, a local vendor could just as easily be a security risk. What you have to remember is that a good deal of the firms that are serving US customers are public companies themselves and serve banks, pharmaceutical companies, software development firms, and many others that place a high emphasis on security. Regarding intellectual property concerns, the reality is that customer relationships, goodwill, and stateside business infrastructure represent the true value of a corporation. Even with a fully functioning copy of a piece of software, it would be of little value without the sales, marketing, client services, support, and reputation of the firm behind it. It’s probably hard to find any large software firm that is not doing work offshore. This is not, however, a license to be carefree and to not take the appropriate safeguards; its just that you shouldn’t automatically rule out doing business with a foreign firm for security reasons.
10. Offshore projects have more quality issues.
Since a good number of people attempt the “send the spec over the wall” method, this misperception is not a surprise. But with proper process and controls, there is no reason why offshore developed code should have more quality issues than code developed domestically. In fact, I would argue that the programming discipline is greater in many cases. Coupled with the fact that you can afford more QA resources and the time and effort required to setup automated testing systems, quality may be achieved more easily offshore.
I invited a guest writer Joel Mezistrano from Biltong Global to write a quick list of myths for Offshore Software Development. He is an expert in the field and you can read more about his services at his site.
Spot your target, hone your skills, master your approach and then strike. But when you strike, be like E.T. The Extra Terrestrial and phone home. Leverage the information to lessen the time it takes to get your foot in the door. 
Just think of the last time you send an email, got the auto-responder saying that your issue would be handled and a few days later you had not heard a thing?! You then pick up the phone and wind up in voice mail routing hell, and you never really get to speak to someone that can answer your questions!
My other suggestion for voicemail hell is a real live receptionist. Someone that picks up the phone in one or two rings, says hello and asks the customer who they would like to speak with. I know we have moved away from this and no company really wants the overhead of call routing. Having a live person taking that initial call from a customer is priceless in terms of value and costs less than $2.00 per minute to have it handled professionally. A dynamic company called