allPM.com :: Projects Without Borders: Gathering Requirements on a Multi-Cultural Project By Elizabeth Larson, PMP and Richard Larson, PMP

Projects Without Borders: Gathering Requirements on a Multi-Cultural Project By Elizabeth Larson, PMP and Richard Larson, PMP

Published on Thursday, August 03, 2006 - 09:17 AM

One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and the business analyst 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 multi-cultural stakeholders, particularly if they comprise a virtual team working in geographically dispersed areas, the job becomes much harder.

Some of the challenges facing project managers and business analysts are not unique to multi-cultural projects. However, personal agendas, conflicts about roles and priorities, and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking requirements defects. While there are many underlying reasons for this rework, dealing with a group of multi-cultural business customers and/or project team members can create significant hurdles.

Challenges of gathering requirements from culturally diverse business customers

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 work day 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 non-verbal communication nearly impossible. Since most business analysts pay a great deal of attention to non-verbals as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements. Finally, although there are alternatives to face-to-face meetings, neither video conferencing nor “net” meetings is ideal. Video conferences usually lack some spontaneity and the audio lag can be distracting. Facilitating large groups over a video conference is quite challenging, since multiple conversations, dominance of one group or individual, and other facilitation difficulties abound. With both video-conferencing and net meetings, there are often equipment issues which hinder the requirements elicitation.

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 each other, it takes longer to find omissions and the resulting errors are harder to correct. Trouble usually occurs if a business analyst expects the business client to define the requirements, but the business client thinks they have already provided the solution and the rest is up to the business analyst. With differing cultural attitudes towards 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 among the stakeholders is well-known. In addition, most people have different levels of understanding and expressing both written and oral languages that are not their tongue.

For example, some people can understand another language when spoken, but have difficulty writing it. Others can understand better than they speak and write better than they understand. In order to elicit the requirements, project managers and business analysts need to work with business customers whose language differs from theirs to assess the comfort with both written and oral communications.

Finally, we need to consider the use of TLAs (three-letter acronyms), humor, euphemisms (powder room, passed away, downsizing), and sports analogies (ballpark estimate, coming out of left field, long shot) that can cause confusion and misunderstanding.

Not understanding cultural landscape

Another barrier is assuming that all team members, whether or not they are co-located, approach the project with the same cultural perspective. For example, we know a woman who was managing a project that included a male team member from Southeast Asia. He appeared uncomfortable taking direction from the female project lead.

The more she discussed the importance of meeting deadlines, communicating status, and teamwork, the more uncommunicative and uncooperative he became. Finally she 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. Therefore, 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 mindset of acceptance, inclusion, and learning that crosses borders. In addition, the project team needs to understand its inter-dependency 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, business analyst, 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 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 a myriad of ways business customers can sabotage a project if they are afraid that the end result will jeopardize or dramatically change their jobs, or when the local requirements are not 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-ones 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 gather requirements related to 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 the least problematic 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 such things as a role and responsibility can be cleared up earlier rather than later in the project.

Example RACI Chart

(Responsibility for doing the work, Accountability for decisions, Consult with on the work, Inform that the work has completed)

Task/Phase	R	A	C	I
Project Plan	Martha	Mary	PMO	Team
Requirements List	Martha	Client	Requirements Consultant	Team Client’s Staff
Modeling (Process, Use Case, and Data)	Ying, Susan, David	Mary	DBA	Team
User Interface Requirements/Prototyping	Martha, David	Mary	Usability Lab	Team
Programming	Sunil, Shashi	Mary	All BAs	Team
User Acceptance Testing	Martha	Client	Sunil, Shashi
•••

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, they:

Have the advantage of needing few words, so the language issues 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 clear and for the most part understood and used by the business clients.

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-ones, and observation.

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, cultural interpretations of the requirements are minimized by using pictures instead of text.

Can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared in-person, by email, with video-conferencing, and with net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.

Summary

In sum, gathering requirements on a multi-cultural project has numerous challenges. To avoid or lessen the affects 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.

About the Author

Elizabeth Larson, PMP, (Elizabeth.Larson@watermarklearning.com) & Richard Larson, PMP, (Richard.Larson@watermarklearning.com) are Principals of Watermark Learning (www.watermarklearning.com), a leading project management, requirements analysis, business analysis training and skill development company. Watermark Learning maintains training facilities in both Minnesota and Arizona. For more information, visit <http://www.watermarklearning.com> or contact them at 800.646.9362.

How well does management support newly assigned project managers?