In today’s project and technology heavy environments, organizations choose to use remote workers to save money and to access niche skills. Individuals choose to act as remote workers to achieve opportunity, freedom, and flexibility. It is usually a win-win situation for both the individual and the organization. However, project managers have some extra challenges in successfully executing projects that use remote employees.
Back in July, I talked about the importance of communicating with remote team members and suggested resources to help facilitate effective communication. Today, I wanted to add thoughts on other issues in managing remote teams.
Geert Hofstede has thought and written about cultural differences that affect cooperative work environments. In Framework for Assessing Culture originally posted on Wikipedia, Hofstede posited these dimensions of culture in his study of national work related values. Perhaps cultural differences may help explain why the actions of co-workers were not what you expected, given what was said (or not). According to Hofstede, cultural values that affect work relationships include:
- Power distance: In cultures with small power distance, people relate to one another more as equals regardless of formal positions. Subordinates are comfortable with and demand the right to contribute to and comment on the decisions of those in power. In cultures with large power distance, the less powerful accept decisions of the more powerful, even if not completely understood or agreed with.
- Individualism vs. collectivism: This dimension measures how much members of the culture define themselves apart from their group memberships. Think of this a bit like adolescents in the United States. Sometimes it feels better to be in the wrong but part of your group, than standing out as different.
- Masculinity vs. femininity: This dimension reflects the importance of gender-based roles in giving feedback and asking questions.
- Uncertainty avoidance: This dimension measures how much members of a society attempt to cope with anxiety by minimizing uncertainty. “In cultures with strong uncertainty avoidance, people prefer explicit rules and formally structured activities… In cultures with weak uncertainty avoidance, people prefer implicit or flexible rules or guidelines and informal activities.”
So, what else can go wrong?
Applying standard practices from requirements definition through testing is good project management and eliminates or solves many problems that plagued software development efforts in the past. However, these best practices often assume common understanding of requirements and operating environments.
In Chapter 2 of Global Software Development Handbook, the authors suggest that because ambiguities caused by differences in language, culture, or experience happen despite your best efforts, project managers should utilize mechanisms for confirming understanding such as asking for paraphrasing, using multiple modalities including textual and graphic representations. (Chapter 2 is available on-line, the book is available through your favorite seller).
Strive for stability—yeah, easier said than done, I know. Stability is helped by effective requirements engineering, agile development methods that take advantage of short cycles of development and test, and detailed user-interface prototypes.
Establish regular, agreed-upon meeting times that spread the time zone pain—Just because you can’t see your remote teams daily doesn’t mean you ignore them. Real project management requires checking in regularly, asking about results and problems and giving feedback when necessary. If your project team spans the globe this becomes even more difficult than normal. Accommodating global time zones means you will need to alternate meeting times to ensure total team participation while “spreading the pain” of your meeting times. After all, with team members on the east and west coast of the U.S. this is tough enough, but add in an Asian or EMEA team member and someone is going to miss either tucking in or having breakfast with their kids. Just make sure it isn’t always the same team member!
Accept process flexibility—sometimes. Your best practices and those recommended by the software development industry are tried and tested. However, there are circumstances when another way exists to skin the cat that is more compatible with your remote worker’s environment. Do not say, “No, you can’t” without thinking through what the differences really are and what risks, if any, they present.
Add more checkpoints than you would when managing a local team. The informal, hallway-level knowledge a project manager acquires about status and issues is not available when working with remote teams. Therefore, you must build in more checkpoints to understand what is happening. This is much more than, “How are things going?” You need to see, you need other team members to see and work with, and you need more frequent—but perhaps smaller—output milestones.
What has been your experience with remote team management? We all appreciate your sharing.
