One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and business analysts work in the same building, misunderstandings are bound to arise. It's a challenge to ask the right questions, get the right people involved and document unambiguous requirements, regardless of the backgrounds of those participating. When the project includes multicultural stakeholders, and particularly when those stakeholders work in geographically dispersed areas and form a virtual team, the job becomes much harder.
Some of the challenges facing project managers and business analysts aren't unique to multicultural projects. However, personal agendas and conflicts about roles, priorities and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking defects in requirements. While there are many underlying reasons for this rework, dealing with a group of multicultural business customers and/or project team members can create significant hurdles.
Challenges
Physical distance of stakeholders
Although many of the challenges exist even when the team and business customers are located on the same floor in the same building, the difficulties in dealing with them increase with physical distance. Time zones make meetings hard to schedule. Business analysts on today's global projects have learned that the standard eight-hour workday doesn't exist. If we are truly customer-focused and interested in building relationships to capture requirements, we schedule meetings at a time convenient to our customers, not to us.
Few meetings on global projects are face-to-face, making the assessment of nonverbal communication nearly impossible. Since most business analysts pay a great deal of attention to nonverbal factors as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements.
Although there are alternatives to face-to-face meetings, neither videoconferencing nor Net meetings are ideal. Videoconferences usually lack some spontaneity, and the audio lag can be distracting. Facilitating large groups over a videoconference is quite challenging, since multiple conversations, the dominance of one group or individual, and other facilitation difficulties abound. With both videoconferencing and Net meetings, there are often equipment issues that hinder the elicitation of requirements.
Roles and responsibilities
Unclear roles and responsibilities can be the bane of project mangers and business analysts everywhere. When they are unclear, tasks invariably fall through the cracks, and finger-pointing ensues. Unfortunately, when stakeholders are removed from one another, it takes longer to find omissions, and the resulting errors are harder to correct. Trouble usually occurs when a business analyst expects the business client to define the requirements, but the business client thinks he has already provided his part. With differing cultural attitudes toward conflict, it can take even longer to perceive that there is a difference of opinion, let alone resolve it.
Language
Language barriers across cultures are numerous. The difficulties caused by differences in languages and even pronunciation are well known. In addition, there are disparities in people's abilities with second and third languages. For example, some people can understand another language when spoken but have difficulty writing it. Others can read with comprehension and speak well but don't understand as much in conversation. To facilitate requirements-gathering from business customers who speak a different language, project managers and business analysts need to assess every person's level of ability and whether they are better with written or oral communication.
Participants also need to keep in mind that communication roadblocks are as common as the widespread use of TLAs (three-letter acronyms) and are caused by attempts at humor, euphemisms ("powder room," "passed away," "downsizing"), and sports analogies ("ballpark estimate," "coming out of left field," "long shot"). In a multicultural setting, all of these can cause confusion and misunderstanding.
The cultural landscape
Another barrier is assuming that all team members, whether or not they are collocated, approach the project with the same cultural perspective. For example, the female author of this article was managing a project that included a male team member who became increasingly uncommunicative and uncooperative as she discussed the importance of meeting deadlines, communicating status and working in teams. She thought this man was uncomfortable taking direction from a woman, but she eventually realized that the real problem was that she had done nothing to build trust and a strong relationship with him. His cultural work ethic dictated the importance of relationships—he completed tasks because of the relationship, not because tasks appeared on a work-breakdown structure.
Tips and Techniques for Making It Work
As organizations take on more global projects or projects that include a diverse set of business customers, they need to establish a corporate mind-set of acceptance, inclusion and learning that crosses borders. In addition, the project team needs to understand its interdependency in order to have project success. Synergy between the business customers and the project manager or business analyst is required to ensure that the end product is successful. Therefore, each party—the project manager, the business analyst, the sponsor and all the business customers—have an obligation and a stake in making this cultural diversity work. Without the project manager, the organization will spend more time and money on failed projects. Without the business analyst, the end product will not be usable. Without strong sponsorship and actively engaged business clients, the true requirements will not be discovered, and the end product will not be viable.
Although each party has its share of responsibility for making the project and end product successful, there are some things that the project manager and business analyst can do that help bridge the cultural gap.
Build relationships and trust
Building relationships and trust is important on all projects. There are myriad ways business customers can sabotage a project if they are afraid that the result will jeopardize or dramatically change their jobs or when the local requirements aren't taken into account. With good relationships, issues surface more easily and can be resolved quicker.
The different requirements-elicitation venues promote team building to a greater or lesser degree.
- For example, the use of surveys does little to promote mutual understanding.
- Facilitated sessions (which may have to be Net meetings on global projects) can help build teamwork, but it could take weeks or months for a virtual team to solidify.
- One-on-one meetings serve to build relationships and help navigate the political and cultural landscape. By meeting individually, the project manager or business analyst can assess commitment to the project, discuss individual concerns, gather requirements from those who may not speak up in meetings and determine the local needs of the global business experts. One-on-ones can also more easily promote understanding of team members from various cultural backgrounds, because language differences are less of a problem, and personal stories and experiences can be more easily shared.
Define roles and responsibilities using a matrix
One technique that can aid in avoiding the pitfalls of unclear roles and responsibilities is to document them using some form of matrix, such as the responsibility assignment matrix or the RACI chart. These tools use minimal text, so they are easier to understand than textual descriptions. In addition, in order to complete them, valuable discussion needs to occur. By facilitating this discussion, the project manager can help ensure that the fine distinctions between things such as roles and responsibilities can be cleared up earlier rather than later in the project.
 | ||||||||||||||||||||||||||||||||||||
|
Model the Requirements
One of the best ways to elicit requirements is to use various models to represent the requirements. Models, such as process models, usage models and prototypes, can provide a structure that encourages asking questions to find hidden requirements and more quickly document a complete set of requirements. Models have a number of advantages in general, and for cross-cultural projects in particular:
- Models have the advantage of needing few words, so language barriers can be more easily overcome. They also have the advantage of promoting a two-way translation of requirements, from business customer to the model and back to the business customer, again with a great deal of structure and a minimum use of words. Models should be created so that they are clearly understood and easily used by the business clients.
- Models are the most effective way to avoid having different members of the group have different mental pictures of the requirements. They are, for the most part, culturally independent. They can be created using several of the requirements venues including facilitated sessions, one-on-one meeting and observation.
- Models can help traverse the cultural landscape because they produce unambiguous requirements. That is, there is little room for misinterpreting them. Regardless of the birth countries of the business customers, business analyst and team members, cultural interpretations of the requirements are minimized by using pictures instead of text.
- Finally, models can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared via e-mail, videoconferencing and Net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.
Some Examples
A large, multinational U.S.-based pharmaceutical client of ours regularly experiences the challenge of cross-cultural requirements gathering. The following are some anecdotes to summarize a few of the key points in this article.
- A conference call with a Tokyo client took twice as long to review a process flow as with domestic clients. The analyst kept asking "Is there anything else?" because of not wanting to omit something important. Conclusion: You need to plan for extra time when working cross-culturally.
- A similar group of Japanese clients insisted on spending time at the beginning of a project getting to know their IT counterparts. They repeatedly ask that the IT staffers come over to Japan to meet and visit with them. When the groups do meet in person, each meeting ends with a glass of sake to celebrate. Conclusion: Relationships are more important than the work in some cultures than others, even to the extent of delaying work. Projects will be stalled until relationships are established, and trust may be even more difficult to establish.
- A cross-cultural team of American, French and British clients spent two hours disagreeing about three industry terms. They later discovered that the terms were all defining the same thing and then had to agree on which one to adopt. Conclusion: Language differences will be a challenge, so take the time to define key terms and record them in a glossary during projects.
- A project manager made an on-site visit to a client from Latin America on a project. The project manager had written in an e-mail that he had found a restaurant to go to, but you had to "BYOB." The client was confused and asked when they got together, "Who is Bee-yob?" Conclusion: Be careful with and define all acronyms.
In sum, gathering requirements on a multicultural project has numerous challenges. To avoid or lessen the effects of these pitfalls, project managers and business analysts should spend time developing relationships, clarify roles and responsibilities in a chart format to ensure understanding by all, use terms and language carefully, and model the requirements to help ask questions. The ultimate goal is to uncover requirements in a way that is easier for all stakeholders, regardless of their language and culture.