In my earlier posts I talked about the history of outsourcing and how commoditizing software development and offshoring go hand in hand. So if outsourcing (and offshoring in particular) is beneficial to company bottom line, the next question is – “Will it work for me?”. I will try to document some guidelines that will help answer this question.

Type of Development

The offshore development is best suited for the projects that need the vendor to only have technology skills. If the vendor also needs to acquire the client specific domain knowledge, this engagement can become very difficult. Not only the client will need to train the vendor into its domain knowledge, the whole process may need to be repeated as the vendor team members inevitably leave for greener pastures. I am not saying this training and attrition cannot be managed. In fact several offshore vendors are managing these issues very well. However, this quickly becomes expensive for the client.

Having said the above, I strongly believe that every project can be divided into (generic) technology specific and (client) domain specific parts. In fact, most of the projects have 70%-90% technology specific parts. As long as we can partition the project tasks and the technology specific tasks are a significant majority, the project is a good candidate for outsourcing.

Changes in Functional Specifications

I have yet to work for a small or large company where the functional specifications do not change over the duration of the project. In fact, if the specifications do not change, maybe we are working in a dead area anyway:) However, every time the specs change, the offshore team will need to be informed and they will need to change course. Although the same thing is also true with onshore teams, the cost of changing the course the much more with the offshore teams because of the distance, time and cultural differences and scope for miscommunication.

One approach is to initially outsource the parts that do not change with the functional specs. These parts typically are technology specific and include functionality like device drivers, protocol interfaces, framework pieces, utilities and tools, etc. As functional specifications become more stable, more parts may be outsourced.

Management of Offshore Team

Managing an offshore team is no small task. I don’t believe that the offshore team members are incompetent. However, there are huge cultural differences. The client project manager needs to understand these differences and adjust for those. Otherwise there is huge scope for miscommunication and eventual disaster.

Moreover, there is typically a significant time difference between the two teams (onshore & offshore). In some ways you can turn this time difference to your advantage by planning for (almost) 24 hour work day. However, the project manager needs to work in all sorts of odd hours to interact with the offshore team.

Planning and Discipline

Working with offshore teams require significant planning and discipline. The project manager has to divide the project in smaller parts, determine the interdependencies, assign these parts to different team, and then monitor the progress very carefully. The project manager should also get into the habit of documenting the communication with the offshore team. This is extremely important to eliminate misunderstanding.


One critical ingredient for success is very often missing. The client needs to trust the offshore team. It should realize that both onshore as well as offshore team members sometimes miss the deliverables, don’t understand the requirements completely, and have bugs. There is typically a discomfort simply because the offshore team is not onsite and cannot be monitored all the time. Whereas I advocate close monitoring of the offshore (and onshore) teams, the client project manager should cut the offshore team some slack as well.

A Strategy for Successful Outsourcing

I would like to summarize the strategy for a successful outsourcing experience as:

  1. Divide the project into (generic) technology specific and (client) domain specific parts
  2. Identify the parts that are fairly independent of changes in the functional specifications and assign those to the offshore teams
  3. Find a project manager who understands the cultural differences and account for those in communicating with the offshore teams
  4. Document all communications with offshore team
  5. Monitor progress very carefully
  6. Trust your offshore team

Partnering with Onshore Outsourcers

Another strategy is to partner with onshore outsourcers who manage the offshore teams for the client. Essentially they provide the client with a project manager who understands outsourcing nuances. I advocate finding a highly skilled technology savvy project manager who can help the client divide the project into parts and schedule the development. These outsourcing companies typically have higher hourly rates but the total cost of the project may yet be less once the cost of client’s project manager and other overheads is factored in.