The key to success in working with subcontractors and outsourcers is to treat them as extensions of your own organisation. This means that you must communicate as effectively with them as you do with your in-house teams, and ensure that they comply with the same policies you set for your own organisation. It doesn't matter if you are working with a large outsourcing operation offshore or a small subcontractor on the other side of town: If they're not following your standard policies and/or you misunderstand each other, the project is unlikely to succeed.

For starters, the outsourcer or subcontractor should implement your organisation's standard policies before it begins performing any work for you. This means that they should adopt the designated organisationwide source-control system, build procedure, testing practices, testing technologies, code commenting requirements and style, and so forth. This might seem trivial or oppressive, but failure to standardise on these basic items has caused the downfall of many outsourcing projects. For instance, if the outsourcer or subcontractor uses a source-control system that is incompatible with your own, significant amounts of information could be lost in code transfers. If it doesn't have the same build procedure, you won't know if a build failed because code was implemented incorrectly or because the build process itself was flawed.

The next big hurdle is to communicate effectively regarding requirements. Considering that misunderstandings are common even in conversations about simple, everyday topics, it's no surprise that the situation is even worse for communication about requirements -- detailed technical descriptions of how code is supposed to operate. Chances are, you won't be satisfied with the code provided unless you closely monitor the requirements process: Ensure that clear requirements are provided to the outsourcer/subcontractor, ensure that the requirements are understood (for instance, by having the outsourcer/subcontractor express its understanding of the requirements), and then verify that the code actually operates according to the specification.

Granted, this process can be complicated to configure and difficult to operate. It requires a lot of code review, a lot of prototyping and a lot of close attention so that problems can be identified and corrected as they emerge -- before they have the opportunity to cause large setbacks. Many organisations have found that weekly code reviews of prototyped or actual code are vital for identifying and correcting misunderstandings as early as possible. Though it may require a significant amount of patience and vigilance upfront, an effective system for communicating and working with outsourcers and subcontractors will provide long-term benefits to both parties involved.

Adam Kolawa is co-founder and CEO of Parasoft, a vendor of automated error-prevention software and services based in California. Co-author of Bulletproofing Web Applications (Hungry Minds 2001), Kolawa has contributed to and written more than 200 commentary pieces and technical articles for numerous publications. He holds a Ph.D. in theoretical physics from the California Institute of Technology.