At this point in my career I've worked on quite a few outsourcing projects. I've worked for companies in Japan, the UK and the US doing outsourcing to Russia, India, Argentina, and various countries in Eastern Europe. I've seen projects that benefited greatly from offshore outsourcing, and I've seen projects turned into unmitigated disasters. In this post, I thought I would share some of the things I've learned along the way.
1. Not everything can or should be outsourced.
If you are looking to add a few people to an established local team outsourcing is probably not your best option. The communications overhead and other logistical concerns will far outweigh the benefits. The same is true for outsourcing tightly coupled components in larger systems. The coordination efforts will be too great for you to realize any efficiencies or cost savings. Also consider the fact that certain types of tasks lend themselves to outsourcing more than others. Outsourcing the graphic and UX design of your web application is probably a bad idea. Working directly with a local designer is much more likely to yield quality results. Finally, consider the impact on your organization. Its very hard to put together a highly efficient development team. If you already have a tight local team of developers that are highly productive it probably doesn't make sense to replace them with an unproven offshore group. You can still use an offshore team for discrete projects (i.e. to augment rather than replace), but in this scenario make sure you clearly communicate your plans to all parties.
2. Carefully consider your offshore location.
One of the most critical factors is the quality and size of the talent pool. Is your outsource partner having a hard time putting forward quality candidates? Are there good universities in the area? Also think about things like timezones. If you are in New York,
is 9.5 hours ahead (or 14.5 hours back), while
is only an hour off. This can make a huge difference in the effectiveness of communication between your teams. Finally, consider the degree to which the country respects and is able to enforce the rule of law. Does the country have strong intellectual property protection laws? Are they able to enforce them? How do foreign companies fare in legal disputes?
3. Consider language.
Do your critical offshore people speak the same language as your managers? I've found that having just one or two English speakers in the offshore location is not good enough. You don't want the team to be opaque. Ensure you have multiple contacts within your offshore team with which you can comfortably communicate.
4. Hand pick your offshore people and don't be cheap.
As we all know, one fantastic engineer is worth five average ones, and a poor engineer can actually cause negative productivity. The same rules apply offshore. Interview every individual on your offshore team, in person if possible, and hire only the best. What is the difference between paying $2,000 and $2,500 a month? If this is the difference between a so-so developer and a star developer its a no-brainer. Paying your developers good salaries will engender loyalty.
5. Treat your offshore team well.
Implement policies that will maximize retention and motivate your offshore team. This is especially important for long running projects. Provide bonuses and other incentives for quality work just as you would for your local employees. If you are dealing with a large offshore operation, ensure bonuses are being passed along to the developers working on your project.
6. Avoid an us-and-them mentality.
Again, this is especially important for long running projects. I've found a few ways to help avoid this trap. The most important is to get your teams together. At a minimum, visit your offshore team. Take them out to dinner. Get to know them. If possible, fly some of them out to work with your team for a while. For projects that last six months or longer I often temporarily relocate local managers with the offshore team. This helps export your company's culture, processes and quality standards. It can also motivate your local managers by giving them an exciting opportunity to spend a little time in another country.
7. Don't forget QA.
Avoid massively scaling your development group without scaling your quality assurance team to compensate. I've seen this happen on numerous occasions with disastrous consequences. Some QA can be done offshore, but certain types of QA work really require local resources. For example, its very hard to find QA people that can catch locale specific UI issues for Japanese interfaces outside of Japan. Finally, hold your offshore team to the same QA standards to which you hold local developers. Demand test driven development and other practices that ensure the QA team isn't being used to catch problems that could easily be caught by unit tests. I hope you find this information useful. I've only covered a small portion of the important things to consider when engaging in offshore outsourcing efforts, but this is a good start. As always, questions, comments and creative insults are welcome.
- Design • Build • Localize | Web • Desktop • Mobile