Recent trends in outsourcing development projects include the increased use of a more globalized resource pool in the form of offshore development centers (ODCs). If your organization selects offshore resources to help complete a project you’re assigned to, chances are you’ll have some long-distance development efforts to coordinate.

Perhaps the foreign development company you’ll be working with has partnered with a U.S. IT services company. Together, they’ll provide local project management and maybe design, with development occurring offshore. Or you might enter into an agreement with a local vendor that has an ODC from which you agree to purchase a certain amount of services. Regardless of the scenario, however, working with an ODC is likely to introduce some new challenges to your project. In this article, we’ll look at some ways you can help sidestep pitfalls and make things go more smoothly.

ODC stats
According to one Gartner study, so far, India leads the way in providing software and services with over $4 billion in exports in 2000. Ireland, Israel, Vietnam and China are also providing an increasing range of development services.

A coordinated effort
When you participate in a development project with staff who live far from you, many time zones away and with cultural perspectives and expectations different from yours, you’ll face a number of concerns. In particular, you need to communicate well to keep the development process running smoothly, and you must make sure that code-writing and infrastructure issues don’t hinder your ability to turn out great results.

What can you do to facilitate the process of working with folks so far away? For starters, it will help if you can participate in choosing the developers on the project. Once a team is assembled, you should take the time to get to know the members. And of course, there are a number of workflow and technical issues that you may need to iron out, as well. Here are some suggestions that will help you establish effective communications and ensure that your coordinated coding effort is as seamless as it would be if you were working with the codie in the next cube.

Assess the talent of the workforce
Help choose. If you can, get involved in the selection process. Conduct technical interviews with at least two developers you would be working with to assess their skill level. Work with your own developers to create a set of questions for each development language you require expertise in, with low-, medium-, and advanced-level questions. This is not to try to trip up any potential resources but to make sure that you understand how they can apply the knowledge and services they’re selling.

When you survey developers that you bring on board locally, you need to be certain that they can do more than talk the talk. After you’ve worked two cubes away from them for a while, you discover their strengths and weaknesses in both work habits and code ability. It’s not as easy when someone is geographically remote. When you choose offshore resources, you don’t necessarily have the benefit of that constant interaction. So it pays to be extra attentive in the selection process.

Get references. Find out how many offshore projects the candidates have completed successfully and how long they’ve been working with such projects. Search through the names of the companies they’ve worked with for ones you recognize. Determine the complexity of the applications they’ve already developed and make sure that it matches your needs for development.

Get ratings. Find out where the company rates, if at all, in the SEI Capability Maturity Model for Software (SW-CMM). At the very least, the level should match your own. If you can find a company that exceeds your own level, even better; you can expect them to teach you some best practices. You can also check the list of published maturity levels for companies worldwide.

Timing is everything
Take advantage of shift work. Working with a group in a time zone that sleeps while you work and works while you sleep offers some benefits. Say you get a bug report 30 minutes before you need to leave for your daughter’s soccer practice. Task the work out to your ODC and look forward to seeing the fix or workaround when you arrive at work the next morning. This extended workday can be especially handy for projects that demand quick turnaround.

Prepare to be flexible. Unfortunately, operating across time zones can make it difficult to talk face-to-face, or even on the phone, especially when you’re working with a company located on the other side of the world. If you are okay with communicating mainly via e-mail, this may not be a problem, assuming that fast turnaround is not an issue. But if you need to work through a problem in a conference call, someone’s going to be giving up a warm dinner at home or skipping the morning workout in order to be available to talk.

Technical issues
Start small. Begin with a small application project to test the waters. Make sure the development team can meet deadlines, return good code, follow best practices, and work well with your existing team before you entrust them with larger projects.

Choose someone to call the shots. Probably your architect, the lead person should be prepared to provide clarification when differences of opinion or design preference issues arise. He or she should be familiar with the business-unit needs, the requirements of the project, and the complexities of the business logic. It helps if this person is tactful, clear, and friendly in carrying out these decisions.

Set up a Web site. Using a Web site as a central repository for code documentation, task clarification, schedule listings, etc., can be useful for any distributed team. By keeping the latest version of documentation on the site, both sides of an offshore development effort are operating on the same page.

Know your reasons for the design. If the design work was done in-house, be prepared to justify it when another group comes in. Anytime new resources are brought into a project, they bring their own ideas and expectations and even their desires for skill development. In fact, the ability of the offshore development resource to work with your designs should be an important evaluation factor if you have the option of selecting this outside group. You may have to defend many of the details of your design until they understand the reason behind your decisions. It’s equally important that you remain receptive to suggestions that might improve the design. If you notice that anyone is becoming too territorial, you might want to read up on egoless programming.

Clarify and communicate your best practices: code standards, source control, and bug fixes. Identify and communicate your development standards. In the beginning, you may want to conduct frequent code reviews to make sure that development styles mesh well and that code documentation is adequate. Even if your standards are published, a new team may interpret them in a completely unexpected way.

Infrastructure problems
Continued strides in infrastructure development in countries such as India should make problems with voice and data network infrastructure less of an issue, but glitches and disruptions will happen. Develop a good backup plan for the exchange of information should a breakdown of expected capabilities occur.

It’s all just a matter of communication
Coordinating work with an overseas group is really no different from coordinating work with someone in your own country. You either work it out together, and the effort succeeds, or you have a project that will never reach its potential. Many Fortune 500 companies have already begun to use offshore development as a cost-effective way to fulfill development staffing requirements. Smaller companies are likely to follow suit in the near future. When your company jumps on the bandwagon, your effort to avoid kinks can make all the difference in project success.