Tips for Working with Off-Shore Stakeholders
In this global economy, facilitated by the Internet, Business Analysts are asked more and more to work with stakeholders who are located all over the world. Several issues can be challenging, such as setting up meetings that are convenient for all attendees, working on deadline when stakeholders are several time zones away, and understanding people whose native language is different than yours.
Time/Attendance Barriers
Depending upon the team’s locations, workday hours can be problematic. While sometimes you will be able to wait a day to get a response to an e-mail or a document review request, occasionally you will have to work after-hours to accommodate a time zone difference.
Tight deadlines call for more creative measures. On a recent project, I worked with technical and QA teams in Manila, which is 14 hours ahead of New Jersey. Working with the QA team was particularly challenging when I was asked to be the test lead for User Acceptance Tests (UATs), and the turnaround for defects was three hours.
Since I was on-call 24×7 for the tests, I worked from home so I could sleep between defect calls. This enabled me to facilitate solutions within the short turnaround. If I hadn’t done that, there would have been a one-day delay between issues and solutions, and even easily fixed items would have been dragged out. Working this way enabled us to get the work done on time, and the project met the go-live deadline.
Language Barriers
The global workforce is often made up of people who speak English as a second language. Sometimes, the on-shore workforce also speaks English as a second language. If you’re a native English speaker, this could present some challenges to understanding each other. Even native English speakers sometimes have trouble understanding each other; for example, I have a hard time understanding Australian slang.
Most of your interaction with the offshore team will be on the phone, sometimes on conference calls. It’s hard enough to figure out who’s speaking and what people are saying on calls with a large group of attendees; it’s more difficult when there are language barriers.
There are several actions you can take to get around the problem. For example, if you’re chairing a requirements meeting, try to use visual aids where possible.
Make sure to send an agenda and accompanying documents out with the meeting invitation if at all possible.
Sending artifacts two minutes before the meeting ensures everyone will be reading them, not paying attention to you speaking.
Make it clear that you are open to answering questions during any presentations or while working the agenda. If people are hesitant about interrupting you, key information will be missed.
A good rule for getting the most out of a conference call, regardless of language, is to make sure you ask follow-up questions about anything you’re not completely sure of.
If there are language barriers, a gentle, “I’m sorry, I’m not sure I understood you, could you please repeat that,” goes a long way to resolving issues. Don’t be afraid to ask people to slow down, or to repeat what they said.
it’s effective to repeat back to someone what they said. That way you will both know if you are grasping the concepts and details, or if you (or the stakeholder) missed something.
There are applications that can facilitate conference calls, such as Cisco WebEx and Citrix GoToMeeting. They both offer HD video, and enable attendees to view each other’s computer screens, which allows you to give PowerPoint presentations without boring everyone to tears. You can also share other documents, questions, and strategies.
I also use WebEx for presenting and discussing applications that are partially built or in beta. It gives people on the phone a better idea of the functionality than documentation and screenshots can, and it also gives people real-time experience with the app. Nothing beats working with an app for understand the user interface and functionality.
After a conference call, it is particularly important to follow-up with a clarification e-mail to ensure no information was lost in translation. You should always send a follow-up e-mail with key points and dates anyway. Write simply, “This is what I understand from the meeting,” followed by a bulleted list. If you know you missed some answers, repeat the questions in the e-mail. Don’t assume or guess.
Also, when writing for a global audience, remember that English, like any language, is filled with slang and idiomatic expressions, words that means something different when put together than they do individually.
Just state the facts, and, as always, strive for the clearest language possible. For example, instead of saying, “we have a tight deadline so we’re going to jump in feet first,” say, “we have a tight deadline, so we’re going to have to learn quickly.” If you use idioms, you will spend time explaining what you mean, or people will simply gloss over the words and miss important ideas. Remember, business analysis is all about getting the right information from the right people. Your job is to facilitate that process.
Don’t forget to leave your comments below.