By Boris Kontsevoi, Ruediger Dorawa and Diana Kontsevaia, Intetics, for the Outsourcing Journal – Building distributed teams is often a necessity in today’s fast, globalized economy. When a company faces talent shortage, tough deadlines for product release, and requires cost optimization, distributed teams are the best option to achieve all of the objectives. Indeed, in majority of cases distributed teams are the only answer, or there is a very good chance that a project won’t happen at all. While it is often the best choice, managing distributed teams can be its own challenge. Chiefly, it requires early investment in communication and development of a systematic communication process. Despite the early investment, working with distributed teams with a process designed to mitigate the risks will lead to more efficiency and better results.
Risks of distributed teams: Causes, effects and mitigation strategies
One of the biggest deterrents of working with a distributed team is limited communication. Lack of proper communication often results in low quality products, management overhead and inefficient teams with overall reduced business value. That is an unacceptable result for executives whose primary goal when outsourcing is to derive more value and optimize efficiency and cost.
The issue of the risks of distributed teams has been around for quite some time. The interest in how to properly manage a global team mirrors the growth of the outsourcing industry – as executives found them- selves working with teams across the world, the need for different kind of management increased.
The topic gained recognition in 1997, and really took off in 2005. As the global labor market continues to grow, so does the need for properly managing distributed teams.
The biggest risks associated with distributed teams can be roughly categorized into three categories: geographical distance, socio-cultural distance and temporal distance[i].
Distributed teams are separated by physical distance, which causes certain challenges when managing a team. Most notably, the effort to communicate must be increased. Since effort has to increase, the quality and frequency may decrease. Second, people become more dependent on information and communication tools. Face to face meeting time is naturally reduced, as traveling to meet teams is inefficient and often expensive. Finally, there is a lack of group awareness: who is really on the team, who is working on what, and so on.
Typical examples of a geographical distance risks are lack of face-to-face contact and lack of trust. Lack of face to face contact is caused by having limited availability to the actual remote site: it is hard to know whether the work is actually being done, when one isn’t there to see it. The second cause is traveling costs. If the reason for outsourcing was to reduce costs, then constant travel to the site could erode any potential gains (though some travel will actually maximize business value). This is the number one risk when working with distributed teams, because it can lead to lack of trust, reduced personal investment and reduction in informal communication – all of which can reduce the quality of the end result.
Another geographical distance risk is lack of trust. Having limited knowledge of the people and the space means that there is less trust between team members and managers. Trust is usually created naturally in a workplace, but in a distributed setting, it must be created consciously. The causes for lack of trust are limited visibility of remote site, unpredictable communication, and lack of interpersonal or quality relationships within the team. This can lead to relationship break down, not having a sense of a team and difficulty coordinating tasks.
The best way to mitigate geographical distance risks is by:
- Key team members visiting remote teams at the beginning of the project
- Frequent travel to remote sites
- Open and clear communication using voice and video conferencing
- Organizing team building activities
Since parts of distributed teams are located in different locations, the behavior of people in each region will differ. In some cases, the differences might be subtle, while in others they might be huge. Socio-cultural distance might make miscommunication more likely, reducing the business value to be derived from the cooperation.
Two common example of socio-cultural distance risks are lack of native business language skills and lack of mutual understanding.
The lack of native business language skills is a result of political, cultural, and linguistic diversity, as well as different standards from one organization to the next. This risk can lead to miscommunication, worsened relationships and unwillingness to transfer knowledge. It can be effectively dealt with by insisting on the use of a common language (such as English), and appointing communication leaders within a team. If only a few people have thorough knowledge of the language, these people can translate the tasks to the remaining members. The second way to deal with this problem is to train remote teams, warning them and instructing them on how to deal with certain cultural and behavioral issues. This should be done especially when an organization has a very specific set of standards. Finally, it is best to document the designated requirements, so there is a written record of the pre-negotiated requirements in case of disputes.
In addition to being caused by political, linguistic and cultural diversity, lack of mutual understanding is also caused by perceived different levels of expertise. It can result in product quality decrease, bad behavior and costly communication overhead. To prevent lack of understanding it is imperative to actively build acceptance among team members.
Socio-cultural distance risks can be mitigated by:
- Use of common language (English)
- Appointing a liaison
- Encouraging team building activities
- Documenting requirements on paper for objective resolution of potential disputes
- Promote socialization of team members from project start
- Provide training on systems, expectations and organization’s culture
Alongside different geographical locations, teams are often separated by different time zones, making communication during a given set of business hours more difficult. This fact can lead to response delay, reduction of communication frequency, lack of synchronous communication, and limited availability of remote team members.
Temporal distance risks can be mitigated by:
- Staying available as much as possible
- Shifting work hours
- Encouraging synchronous communication for proper coordination
- Promoting direct communication or pair to pair links among team members
- Employing specific business processes and schedules
If managed correctly, the risks of working with a distributed team can be minimized. The right process can maximize efficiency and amount of business value received from the project. The best way to manage risk is by paying attention to communication. In other words, there must be a systematic communication process to guarantee positive results.
Outsourcing models and distributed team management
Onshore, nearshore and offshore models all have different geographical, socio-cultural and temporal distances. The severity of the above risks and their mitigation strategies will vary depending on which outsourcing model is being used.
Distributed teams under a nearshore model
Nearshore models are used for different reasons than offshore models. One of the main reasons is the team size. The second biggest reason is type of project. Compared to offshore providers, nearshore providers are often smaller, focusing on skill-intensive tasks, rather than volume and repetitive tasks (such as customer service and call center).[ii]
The success of the team starts by selecting the right model for the right project. If there’s a mismatch at the very beginning, in terms of team members’ skill level, team size and vendor scalability, the project is unlikely to achieve the expected results no matter what the communication process.
When a nearshore model is implemented, it is best to work as one team. In fact, since the nearshore team is likely smaller, it is imperative that they work as one with the in-house team. In nearshore partnerships the remote team members should be viewed as colleagues. First, members of a nearshore team are not hired for just one single task or a job, they are there to work on a product for a year or more. The nearshore team should become a natural extension of the in-house team. Then, all parts of the team should be able to do all the activities, they are just doing them in different locations. As a result, there are no doubts about either side’s ability to work on the project, which helps avoid the “us vs. them” mentality. Thirdly, there should be daily contact. Since the teams are geographically and temporally closer together, arranging time to talk to the rest of the team is easier. It is also more vital to getting an integrated result, as these teams work very closely with the in-house team. Finally, it is imperative to create opportunities to get together. Again, this is much easier because distance is reduced, and it adds volumes to end result quality.
Under the nearshore model, some of the inherent risks that exist in managing a distributed team are naturally reduced, especially the socio-cultural distance risks. This is because the political and cultural diversity is much smaller in a nearshore environment. Furthermore, since teams are smaller, there is less possibility of effective training and identification of skills deficit – so that any problems can be resolved much quicker.
Enabling rich communication: Distributed teams in software development
Nearshore outsourcing is often used for software development. Regardless of where it takes place, software development in itself is already a highly systematic procedure, with processes like SCRUM and Agile at the forefront of successful product development.
With the rise of distributed teams, executives have begun to use “distributed SCRUM” practices to manage their distributed teams. While the core idea behind SCRUM is still the same – using daily meetings and short iterations, distributed SCRUM emphasizes communication and building trust. As a result, a consistent process of software development – and communication – is achieved.
The starting point for implementing distributed SCRUM is to understand that each miscommunication reduces business value derived from the product. Moreover, the more effort communication requires, the less business value will be deduced. Since daily communication is already part of the SCRUM process and it’s a highly visual process, the SCRUM master’s main role is to guide the rest of the team towards rich paths of communication.
What is rich communication? From richest communication to poorest communication it is:
- Face-to-face conversation with physical whiteboard
- High-resolution, large screen videoconference with a virtual whiteboard
- High-resolution, large-screen videoconference
- Low-resolution, small-screen videoconference
- Clear telephone connection, using high quality phone hardware and a landline
- Clear VoIP connection over good Internet lines
- Noisy telephone connection, using poor quality hardware and VoIP
- Instant messaging and real-time text chat
- Wikis and electronic discussion boards
- E-mail [iii]
In other words, the SCRUM master’s main role is to lead the team away from e-mail as the primary form of communication. Audio-only calls have their limitations also: they allow members to multitask, it is unclear who is speaking, and there are no facial and body language cues to help understand others. If face-to-face isn’t available, then investing in a high-resolution videoconferencing is more likely to achieve the best value in terms of project quality, quantity, and correctness of end result.
The second largest difference from regular SCRUM is that trust has to be built more consciously and less naturally than in a face to face setting. This can be done by ensuring two things at the project start. First, the team must get together before the project starts. Secondly, the Product Owner must clearly communicate that they want to hear the good and the bad news. If the team is uncomfortable telling the Product Owner what can go wrong, there is much less room to fix problems if they do arise.
Investing in good communication tools and in frequent travel might seem a lot, but they are actually little investments that usually take less than 5% of total project cost and only 0.1% of the project’s resulting end value. Given the fact that the improvements from better communication and more trust can have a 20%-30% productivity impact on the team and reduce risk, they are definitely worth the costs[iv].
Distributed SCRUM is a working method of how to build the right process to effectively deal with the risks of distributed teams. It helps create a systematic process and schedule tasks, so each team member always knows what they need to do. It also prescribes communication channels – who should communicate with whom and when. One of the biggest arguments against distributed teams is that lack of face to face reduces the amount of ad hoc communication that happens in informal settings, which may reduce product quality. While ad hoc communication is certainly rare for distributed teams, having a systematic process can actually yield a superior result. Ad-hoc communication can actually work against a systematic process by allowing people to do things out of order or work on unscheduled tasks. Since distributed teams have no other choice but to follow the schedule, the results they achieve are much more predictable and reliable. And with proper communication, perhaps even less risky.
There’s no “Us vs. them” in “Team”
Developing a systematic process and investing in communication tools might seem as an unnecessary cost, especially when the point of distributed teams is to reduce costs. Yet, understanding how communication with distributed teams differs from regular teams – and preparing for it accordingly and early – is the best way to ensure the success and efficiency of remote teams.
[i]Iqbal, A., Gencel, C., & Abbas, S. (2012). Communication Risks and Best practices in global software development. Lap Lambert Academic Publishing.
[ii]Van Wieringen Borski, J., & Herke, S. (2014). How To Organize Offshore and Nearshore Collaboration: Lessons Learned in Offshoring and Nearshoring. In How To Organize Offshore and Nearshore Collaboration: Lessons Learned in Offshoring and Nearshoring.
[iii] Deemer, P. Distributed SCRUM Primer. Retrieved from http://www.goodagile.com/distributedscrumprimer/DistributedScrumPrimer.pdf
[iv] Deemer, P.
About the Authors:
Boris Kontsevoi – Mr. Kontsevoi is Founder and President of Intetics Co. Under his leadership a group of software engineers developed into a truly global technology company with multiple professional certifications and industry awards, including Global Outsourcing 100 and Top 100 Global Services company. For the impressive growth Intetics demonstrated over the years, Boris received an Entrepreneurial Excellence Award in 2009. Boris has over 30 years of managing experience and about 40 scientific publications. He was a featured speaker at several international conferences. He holds a Master’s degree in Radiophysics and Computer Science from the Belarus State University and certificates in project management from Aspen (ISIM) University, Colorado, USA. He is Certified Outsourcing Professional (COP), a professional designation awarded by International Association of Outsourcing Professionals (IAOP) to leading outsourcing practitioners that demonstrated ability to design, implement and manage successful outsourcing initiatives. Boris also serves as IAOP’s Eastern European Chapter Chair and, during last 14 years, as a Distinguished Judge of WebAward Competition conducted by Web Marketing Association. He is also a member of IAOP, the Outsourcing Institute, NOA and several other professional and community organizations. He can be reached at email@example.com, or via LinkedIn at https://www.linkedin.com/in/boriskontsevoi.
Rüdiger Dorawa – Mr. Dorawa is the Executive Director of Intetics GmbH. He holds a joint degree in International Management and Corporate Communications from FOM (Germany) and Avans+ (The Netherlands). He has 20 years of IT experience in software, software development and software testing in outsourcing, near- and off- shoring projects. In his career, Ruediger worked for international software vendors and product development and lifecycle management companies such as Novell and Symphony Teleca, where he launched new software and business solutions. As an Assistant Professor for Sales & Marketing, he also actively contributes to professional development in Germany. He can be reached at firstname.lastname@example.org, or via LinkedIn at https://de.linkedin.com/in/ruedigerdorawa.
Diana Kontsevaia – Ms. Kontsevaia is Content Marketing Director at Intetics Co. She holds a Bachelor’s degree from McGill University. She is a published author in a variety of academic and industry print and online publications. She can be reached at email@example.com, or via LinkedIn at https://www.linkedin.com/in/dianakontsevaia.
This article was published in the Outsourcing Journal Special Edition “Nearshoring Europe Edition” in Q4/2015. You can download this edition (150 pages, PDF) free of charge here (membership with German OutsourcingA association required (free, personal membership available) >http://www.outsourcing-journal.org/Special-Editions/outsourcing-journal—nearshoring-europe-edition.html