Not to say that all offshore projects fail, I have both been a contributor and leader in projects that have been a great success and those that have been complete failures. Each project had its own reasons for failing and were defined by the business (e.g. why are you sending it offshore to begin with) that typically include cost savings, quality, increased turnaround in deliverables, and customer satisfaction--all of which are key drivers for moving work offshore, but in doing so there are key areas your business must pay close attention to.
According to Gartner, businesses will spend more than $50 billion USD on offshore and "near-shore" outsourcing by 2007 and many projects will fail because of poor planning. Gartner also maintains that there are benefits achieved by those businesses that successfully outsource their non-core processes, however, rewards will not be instant.
Reasons for Failure
Often times, the effort and time involved in communicating with offshore team members and maintaining that relationship is underestimated. In my experiences with offshore teams to date, there has often been a lack of key items to complete awarded work effectively (like infrastructure, soft skills, planning). Additionally, coordinating between the teams requires longer hours, detailed planning, and cultural training—all of which are more expensive when working with offshore than with your own staff and can, as I have observed here, lead to lower morale and reduced deliverable output. Gartner also observes that lack of productivity in the offshore is also an issue for several reasons including high staff turnover and skill levels, especially in highly competitive markets such as Bangalore and Hyderabad, India.
Much like the dot com days, new programmers coming into the field of work are inexperienced, attaining only the necessary core skills for them to receive a job in this field and often struggle with ambiguities in specification or shifting directives. As such, the teams typically do not operate with clear processes and depend on the competence and heroics of those more experienced and not on the use of proven processes. In spite of the chaos, these teams often produce usable work products; however, they frequently exceed the budget and schedule. More often than not these teams over commit, abandon any established process in times of chaos, and may not be able to repeat past successes again.
What's more, senior executives are not involved to keep strategy on track and morale high—they are only in the picture when a significant escalation occurs or to sign a new deal. As I mentioned in my previous entry, in order for an offshore deal to succeed there needs to be a good level of communication between all parties. Requirements, goals, and expectations have to be defined clearly and in detail. Your onshore managers need to explain to the coordinating staff why the work has been sent offshore and what benefits are expected.
More often than not, the cultural differences will come into play creating havoc for the project; classic incarnations of this include not questioning authority and just pressing forward by the offshore team. All too many times do we find out late that guidance or requirements had been ignored for cross cutting to please the schedule rather than announcing a slip.
How can Visual Studio Team System help?
Gartner advises companies that plan on offshoring work to figure out their IT process maturity and identify gaps in your process. As previously mentioned, it is important to set all expectations clearly up front with your vendor. When using Visual Studio 2005 with Team Foundation Server, several mechanisms out of box enable teams to work effectively in these environments: