There have been a number of recent articles documenting Airbus 737 Max failures. Coming from an aviation engineering background, I am fascinated by mainstream coverage of a world I inhabited for years. One article in particular caught my eye. Bloomberg ran a piece on Boeing’s practice of outsourcing aspects of software development to less costly developers in other countries; the implication being that the practice was partially to blame.

Outsourcing is an ongoing topic as companies seek to save on what is inherently an expensive part of the product development lifecycle. When you consider the numbers, it’s easy to make a case for the international outsourcing of software development. If you can find someone to perform at a fraction of the cost, why wouldn’t you? Even if that developer is only half as productive, you still come out ahead.

Research suggests that there is a considerable range of productivity among developers. While there may be disparities in talent, I believe there’s an even more important reason to think twice before outsourcing. It’s a lesson that has less to do with the person actually writing the code and more to do with the outsourcing process itself.

If there’s one lesson I’ve learned over my career, it’s that handing developers a requirements document and expecting them to build to spec is a recipe for failure. Whether that person sits next to you or halfway around the world, there are often two main issues:

1. The requirements document is incorrect.
   Requirements documents often assume one has learned all there is to know during the requirements gathering phase and are adequately prepared for implementation. The Agile revolution is built on the (often correct) notion that you actually don’t have all the answers—and even more importantly—that no single person can know everything at the start of the project. Instead, we iterate in learning cycles, experimenting and incorporating new findings into the product.
2. The requirements document is insufficient
   Even if you presume requirements can be gathered up front, you still need to thoroughly communicate them to an external team. In my experience, frequent conversations between the development team and stakeholders are the only foolproof solution.

The crux of the problem is communication. By choosing to outsource, channels of communication are often formal and immutable (requirements document, legal documents, etc). Language barriers between the stakeholders and the development team also get in the way. While this can be overcome with the right structures in place, it adds a layer of confusion. And, even if you address the above challenges, teams are in a different time zone, on a different continent, and generally less available to chat. All of these conspire to make communication the greatest detractor to international outsourcing.

So what is the alternative? We can’t change the fact that organizations are increasingly turning to remote forms of collaboration, either across the country or across the world. The question is how to overcome the inevitable gaps in communication.

Heavily regulated industries lean towards formal requirements for good reason. We need to determine how best to improve upon them. We also need to come to the realization that documents can no longer be the sole method of communication. Well-documented conversations are an equally essential component. Or perhaps even more essential. As the Agile Manifesto makes clear: “Individuals and interactions over processes and tools.” While processes and tools offer value, individuals and interactions create even more.