Pitfalls Arising When Outsourcing Code: Communications

Like anything, outsourcing is not the right tool for every job but it's a good tool for the right job. There are a number of problems traditionally associated with offshore software outsourcing development and we offer our series "Pitfalls arising when outsourcing code" to help you avoid these problems. This is the first article dedicated to communication problems that often lead outsourcing projects to a complete collapse.

The best solution for the problem is to remove the reasons, not to overcome the consequences. The need for rich communications usually comes from underspecified requirements. Thus, paying as much attention as possible to the requirements is the way to limit communications. However, it is not always possible to work out exact requirements. A client needs special skills and additional time or the project itself may have changing nature This is especially true for web projects. Below we have given several tips for such situations. But take care - there is no silver bullet and there are many situations nobody can predict.

Several of the main reasons why communication problems arise are:

• Geographical distance. While an onsite programmer always can ask his manager or system analyst siting in the next room, a small problem in offshore outsourcing may cause a huge correspondence with unpredictable results.
  
  
• The time zone difference limits time for communication. Moscow or St.-Petersburg, for example, are 8 to 11 hours ahead of the USA. Although the working day in Russian companies is often adjusted to their clients' working hours, this adjustment makes sense only for European customers. If you are in the USA, prepare for the same difficulties you have with your European partners (at best).
  
  
• Language barriers may also exist. There is no need for every developer to be a fluent speaker, but the project manager\\\\ tech. leader must have adequate communication and language skills.
  
  
• Cultural differences may result in the fact that business logic and user expectations have to be spelled out in greater detail than would be necessary for a native developer.

Tips that may help

• Treat them as long-term partners. If you plan to bring in outsourced developers, plan on a long term relationship. You will need to closely manage the project and monitor progress often. Also, plan for long term support of the project from the beginning of the project, not at the end. You will always need ongoing support, and it is better to negotiate terms before the project begins rather than after the project is completed.
  
  
• Use a single communications channel. Build your communications with the provider via one-to-one channel, between the project manager from their side and your dedicated person for management and communications from your side. Initial specifications are never right and you can overcome the problem with continuous feedback.
  
  
• Simplify communications. Use email, chat, ICQ, IRC and conference calls and set up frequent status reporting.
  
  
• Visit often. It is very difficult to communicate effectively only by email. Visit your counterparts at least one time in two-three months.
  
  
• Check their project manager. The offshore project manager has to have a very clear understanding of cultural sensitivities. Ideally, if he has travelled widely and lived in several countries, he understands why and how other people behave as they do.
  
  
• Think before requesting changes. Always weigh the importance of the changes requested by your side. The management overhead is always huge and can be justified only in cases when the change is really important and serious.
  
  
• Share your knowledge. Send over one or two of your staff to join the development team for a trial period. This will help everyone better understand your corporate standards. Or bring their lead developers to work with you for a week or so, so they get into the rhythm of your project. Then they can go back and lead the project much more accurately, as they'll feel more a part of it.
  
  
• Listen to them. If you're hiring them for expertise you lack, don't pretend you know it all. Listen to what they say.
  
  
• Bring your coding/documentation standards and enforce them on a day-to-day basis rather than every other month. Do regular code reviews to make sure you don't get sloppy code.
  
  
• Give extra attention when needed. Unfortunately, it often happens that half of the developers are newcomers or inexperienced in the skills you have chosen for the project. This is rather a delicate moment. You can insist on certain candidates for the project team or demand everybody to have 5+ years experience in the selected tool, but we do not recommend it. It may result in higher rates or the provider will bring inexperienced developers saying they are the coolest you can find. However, if you have specialists in the area, we recommend to identify the risks, i.e. the weakest programmers and give them the extra attention they need to keep up.