There are many flavors of outsourcing, but the true split is outsourcing to US-based companies and out-sourcing to non-US-based companies. I’ll deal with the second type, as the market and industry for out-sourcing to US-based companies is pretty stable. Outsourcing work to another location in the US or bringing in outside consultants to work temporarily in the office can be complex but does not face as many challenges as outsourcing work to non-US locations, also known as “offshoring”.

Off-shoring has been put into the political and economic lime-light over the last two years. It has been blamed for the slow recovery of the US’s economy by moving traditionally well-paying white-collar jobs overseas. Politicians have lobbied to cap work visas and to blacklist US companies that outsource work. At various government levels it has been proposed that US government work should never be outsourced to non-US based companies – given that it’s American work integral to American interests, it should be done by Americans. A little while ago one news show would daily scroll the names of US-based companies who had outsourced their jobs overseas. There were many high-profile names including Yahoo! and Boeing, and the list by now is quite large.

Having worked for one of the top 5 outsourcing outfits in India and led a team on a $3.5 million dollar project, my experience leads me to conclude that the outsourcing movement has a few merits but only when applied to very specific types of IT implementations.

The most obvious pro of outsourcing to non-US companies is the lower labor cost. However, when a US-based IT department considers offshoring, it has to weigh the following factors:

1. IT infrastructure & process
a. Integration - How will your US-based network, architecture integrate with the India-based network, architecture?
b. Bandwidth - Will India-based developers access/develop on servers in the US? If yes, do you have enough bandwidth to support remote builds, etc? Consider the time/cost in setting up a dedicated pipe or frame relay.
c. Security - How will you secure that access? Via VPN?
d. Other issues – How will you coordinate VM? Testing? System testing? Code reviews?

2. Time zone difference & Geographic distance
a. Coordination – All teams need direction from managers. Phone calls will need to be schedule daily at early hours/late hours due to the 9.5 hour time difference between the East Coast and India. It’s 12.5 hours between the West Coast and India. It’s 13.5 hours during day-lights savings. A call from California at 7am is already 8:30pm in India.
b. “24-hour work day” - Outsourcing outfits tout the “24-hour work day”, i.e. while US-based employees are sleeping, India-based employees are working and vice-versa. On my old project we called it the “24-hour delay”, i.e. while US-based employees were sleeping, India-based employees were stuck on an issue and couldn’t go forward without functional input/technical decisions from the US. And again, vice-versa.
c. Response time - Decisions made in India while the US slept had to be deciphered and understood during the US day, taking up valuable time. Emails will not be responded to immediately given the time difference.

3. Team Hierarchy & Management
a. On-shore manager – All direction needs to come from the on-shore manager. It requires expert coordination of time, resources and tasks to balance the on-shore team and off-shore team timelines.
b. On-shore team – There needs to be an on-shore team to review the off-shore team’s deliverables for quality control. The even the best-written specs can get misinterpreted, especially if the developer has no access to the BA for that “quick question” over the cubicle wall.
c. On-shore and off-shore managers - There needs to be a dedicated manager of the developers for the off-shore developers in India and a corresponding on-site (US-based) manager. An on-shore manager cannot effectively manage a set of developers remotely given time and physical distance. By doing this, you’ve just added an extra layer of communication and labor cost to your team.
d. Team building - A “soft” skills consideration, teams work best when they trust their peers. The on-shore and off-shore need to trust each other and build a relationship. Same for the on- and off-shore developers. This is difficult to do when separated by time and distance.

4. Functional knowledge
a. Business Analyst role – I have not seen a successful transfer of Business Analyst responsibilities to off-shore employees. A good Business Analyst is in-tune with End User needs, has in-depth industry knowledge and intimately knows the company’s culture as well as the functional requirements and business goals for the IT implementation. An off-shore employee will have none of this knowledge.
b. Requirements and Design documents – If these documents are not 100% complete, tightly written and precise, there is too much room for error on the developers part. Please see points 2.b, 2.c and 3.b above – if there is little or no opportunity for quick clarifications, quick correction of development course, the resulting deliverable can be way off track by the deadline.

5. Culture & Language
a. Work habits - How many hours are there in a work day? What is the definition of “done” code? What type of initiative to you expect from your off-shore developers to resolve problems? How do you define “quality” in code, documentation, process? Depending on your answers you may face frustrations since the answers to these questions are more subjective and culture-based than we initially think.
b. ESL – Indians are taught in English starting in elementary school. Despite an excellent education through university, there are still differences in Indian English versus US English, which can lead to misinterpretation of requirements, design. Be aware that for most people, regardless of nationality, writing skills are not as well developed as verbal. Expectations for clear documentation of code, design docs etc. should be adjusted accordingly, and the time spent to clean-up/clarify documents etc. must be factored in.

The first item is most often looked at and tackled as a technical problem with a technical solution. The last four are more difficult to pin down given their highly variable nature. I argue that depending on the IT implementation, the last four can break even the best technically-planned project. The question that the IT department needs to ask is, is the cost and time to resolve 1-5 going to be greater than the potential labor cost savings for labor at a lower rate? Since the IT department will not be interviewing each developer, it must trust the personnel criteria, hiring process and management of resources by an outside vendor.

In what cases do I think IT outsourcing works?

1. Development of tightly-focused, well-designed, small standalone pieces for widely-known technologies and code standards
2. Call centers, where the system is in place and requires the Indian employee to recite information
3. Back-up/maintenance of stood-up, production systems

These tasks do not require in-depth knowledge of industry or company business goals; they do not require analysis of functional requirements and contact with functional resources for clarification. They do not require high-contact with managers for direction.