Engineering Success Offshore
Best practices for ensuring a productive outsourcing experience.
- By Leonard Lobel
You don't have to be a management guru to know that outsourcing development to an offshore team can be a risky proposition. Poor collaboration is an issue in any team effort, but when that team spans geographic, linguistic and cultural borders, the stakes go up in a big way. Unless you manage things carefully, the cost savings expected from an offshore operation can quickly evaporate.
In my experience as lead architect in the development of an enterprise-scale ASP.NET C# application for a global financial institution, I focused closely on smoothly integrating onshore and offshore development. Here are some of the methods and techniques that have proven successful -- both in maximizing ROI and minimizing risk -- in our working relationship with the offshore team.
Naturally, communication across the entire team is essential. E-mail, documentation and project plans are all useful and necessary. An implemented process of guidance for testing and tracking defects, such as that promoted by Microsoft Visual Studio Team System, also goes a long way to keep everyone in touch. But live verbal conversation between team members still ranks as the most effective means for staying connected.
Time zone differences can make this difficult. Being located on the east coast of the United States at Greenwich Mean Time -05:00 creates a ten-plus hour barrier between us and the offshore team in India at GMT +05:30. Each day begins at 8:00 a.m. Eastern time with a dial-in phone conference with the offshore team, which is just ending its day at 6:30 p.m. When appropriate, we augment these calls with a LiveMeeting session, so all participants can view a shared desktop.
We consider this daily verbal dialog (which averages 30 to 60 minutes) to be a vital part of our process, in which requirements, design and general issues are openly discussed and the project is kept on-track. For locations further west in the United States where greater time zone barriers can make daily conference calls impractical, a good idea is to implement a call every other day, alternating the time so that the burden of meeting very early or very late is shared fairly between teams.
The culture gap is another important issue. Fluency levels in English tend to vary, as do accents. Use of slang and metaphors can confuse even the most fluent non-native speakers, so be careful to avoid them both verbally and in writing. You'll also need extra patience when communicating, using carefully worded language and clear enunciation.
It's not unusual for foreign contractors to be reticent about speaking up. So make a point to reach out and solicit confirmation and response during your conference calls. Follow these guidelines, and not only will you boost morale, but you'll find that the communications gap will narrow over time.
One of the first goals I set out to achieve was to improve application architecture by applying proven patterns and practices. The allure for hiring more developers at lower cost by outsourcing must be tempered by the reality that offshore companies draw on a very large pool of developers with varying levels of skill and experience.
In our case, a large number of bright developers provided the muscle for writing a lot of code that successfully implemented key functionality. What was lacking, I found, was a coherent application framework. We needed to leverage the advantages of object-oriented design, yet inheritance and polymorphism were practically non-existent in the code the offshore team produced. Predictably, we ended up with a lot of duplicated and difficult to maintain code.
To resolve the issue, I was charged with shepherding the object model moving forward, designing an infrastructure of base classes and interfaces for the offshore team to run with and extend horizontally with concrete functionality.
In our case, we needed more than conference calls to get our offshore developers working with the newly minted object model. So instead of just telling them how to implement concrete classes we opted to show them, by recording video tutorials of the process. A third-party product, like Camtasia Studio, can capture your on-screen activities to a file, which can then be included as part of your formal documentation set under source control. By having the offshore team view the videos and then discuss them in our daily conference calls, we were able to efficiently get everyone on the same page. The result: The team delivered all derived classes in advance of the release deadline.
A team is a team, no matter how large, dispersed or diverse. But for offshored projects, there's no doubt that the margin for error is reduced. By employing techniques like these, you can ensure that your distributed development effort goes more smoothly.