Working with remote stakeholders without face-to-face contact is never easy. If we cannot walk down the hall to ask a question or to look over someone’s shoulder to sneak a peek at their progress – we gain little insight into the detailed work and sometimes we don’t know until too late that we are off track. When we cannot read the body language and we don’t understand some of the conversation on a conference call – we may miss much of the intended message. We really increase the risk and complexity of our projects when we are assigned on global teams with people from different time zones, different cultures and with different business norms.
As business analysts we often function as the liaison between two major groups of stakeholders. Not only do we communicate with the business stakeholders to elicit, analyze, document, and validate the business needs but we need to clearly communicate the properly detailed requirements to the development team in a format that they understand and can use to build the appropriate software solution. Communicating well and translating needs is difficult on any IT project. When our development team is in another country, we need to become much more formal in our processes and communication or we can really have a disaster on our hands. Of course all good projects begin with a shared understanding of the project purpose, scope, and roles and responsibilities. Beyond that, I have learned some key factors which improved my success on global projects. Some items mentioned below are the sole responsibility of the business analyst, such as scheduling requirements work sessions with stakeholders. Others may be owned or shared by the PM, BA or other team members such as acquiring training for the team. The items for consideration include:
1) Selecting and using common (familiar) processes, tools, templates, techniques and standards.
2) Acquiring training as needed for the team – specifically regarding requirements elicitation, analysis, and validation techniques.
3) Scheduling more frequent structured meetings and formal communications.
4) Adherence to a well-understood and formal change control process.
5) Using collaboration tools, wikis, and internet/intranet project repositories where information can be centralized and shared regardless of the person’s location.
6) Maintaining a secure infrastructure for role-based access to information.
Next week’s blog will include more details about each recommendation.
Your comments and recommendations with global teams are welcomed.
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009