Integrating Outsourced Projects
Integrating teams is the key to outsourcing success
When you hire an outsourcer, you are essentially adding a separate entity to your enterprise. This new “appendage” needs to be integrated into your existing, functioning system. Integration is the glue that binds disjointed parts together. How seamlessly those parts meld is up to you.
Two different areas that need to be integrated with your enterprise when you enlist an outsourcer: infrastructure and work force.
Infrastructures consist of systems and processes. Integrating those systems and processes you already have with the outsourcer’s infrastructure is essential. With a common infrastructure, you can remain in control of your outsourced projects and keep a close eye on their status to ensure that everything is on schedule and meets standards.
We discussed one proven method for integrating infrastructures in detail in a previous article, “Solid Infrastructure Paramount to Successful Outsourcing” (see http://esj.com/Enterprise/article.aspx?EditorialsID=1416). In a nutshell, this process involves implementing a preventive methodology based on five principles:
- Apply industry best practices to prevent common errors and establish a foundation for full-lifecycle error prevention
- Modify practices as needed to prevent unique errors
- Ensure that each group implements practices correctly and consistently
- Phase in each practice incrementally
- Use statistics to stabilize each process, and then make it capable
Integrating Work Forces
Joining your employees and the outsourcer’s employees to form a single cohesive unit is imperative to the success of your outsourcing project. When you go outside the confines of your organization to implement a project, you inevitably need to bring two different groups of people together into a working relationship. Whether that working relationship is congenial, productive, and efficient greatly depends on you.
The greatest challenge is that these two groups of people feel independent from one another. Why? First, the groups are physically separated from each another. Each group spends its working hours in different buildings that are likely to be in different cities, states, or even countries. Second, there is a high probability that the groups will have difficulty understanding one another because of differences in their culture and knowledge bases. Cultural differences can occur at the corporate level, ethnic level, or both. As for knowledge differences, it’s not because one group is more intelligent than another; it's because they focus and specialize in different areas. For these reasons, there is a great chance that the outsourcer’s team will feel distant and detached from your team.
Unifying two separate teams is essential for the success of an outsourcing project. Even if the outsourcers are contractors, it is imperative that everyone feels they are working together towards the same goal. If they do not feel like they belong, they won’t care about the product they are building. You will end up with delayed or shoddy results—or both!
Best Practice: Perform Exchanges
One way to unify the two teams is to begin each new outsourcing project with employee exchanges. These exchanges are a way of “planting seeds.” Observe the outsourcer’s developers. Pick out a few who are capable of learning and intentionally spreading your philosophy, infrastructure, and methods among their team members. Bring them to your central location, and immerse them in your culture.
Your first reaction is likely to be, “That’s crazy! What about the expense? One of the reasons I’m outsourcing is to save money, not spend more money.”
Sometimes you need to pay a small cost up front in order to avoid large, detrimental costs in the end. Having just two or three of your outsourcer's employees to interact directly with your team reduces costs by dramatically decreasing miscommunication. Miscommunication leads to an unpleasant problem: rework. Rework costs a substantial amount of money.
In the beginning, when you plant these so-called seeds, the entire communication system will be broken. It just won’t work! The two groups need to connect on a human level. After communication between the two groups is initiated, they will establish, (and then refine) the way they communicate.
Best Practice: Teach and Involve
Next, teach the visiting outsourced developers about, and involve them in, your infrastructure and methods. This way, they learn to work as part of your team, and the two groups of team members have more in common. It is a similar situation to a new hire during the first few months of employment. The more they learn and the more they become involved, the more your outsourcer's team members will start thinking the way your entire organization thinks.
Observe the way this new joint team interacts. It will help you know when it’s time to send the few outsourced developers back to their own location. How? The outsourcer's team members will know everybody personally and have developed a rapport—even friendships. Can you trust that all the individuals who visited your site will bring back what they’ve learned and naturally integrate it into their home environment? Yes. They are working on common code. They know exactly what they are doing—they know the processes and practices. The outsourcer’s developers also have a thorough understanding of how the system operates. By now, they do not feel alienated. In fact, quite the contrary—they feel like part of the company. They’ve had time to learn and become part of it during the duration of their visit to your site. Trust that the seeds you planted will spread and sprout.
These two groups—your employees and the outsourcer’s employees—need to connect on a human level, which can only be done face to face. That’s a major part of the integration. After both sides have developed a connection and understanding among themselves, they can be separated.
To maintain the integration (more specifically the relationship and connectedness between your team and the outsourcer’s team), one visit is not enough. The outsourcer’s team must pay intermittent visits. A remote infrastructure (such as Webcasts) helps, but nothing replaces two people sitting at the same table.
Adam Kolawa is the co-founder and CEO of Parasoft Corp. He is also the co-author of "Automated Defect Prevention: Best Practices in Software Management" (John Wiley & Sons Inc., 2007).