Continued from BA Considerations when Working with Global Teams – Part 1
1) Selecting and using common (familiar) processes, tools, templates, techniques and standards. We should try to select development processes, tools, techniques and templates for which the team has experience. For the BA the key deliverable is the requirements package. Using a standard template for requirements really helps save time and energy in managing everyone’s expectations about what will be delivered. It is still important that the BA communicate which components (like a process decomposition diagram, a logical data model, etc.) their package will include, and how each component will be presented for validation (text, structured text, tables, models, workflow diagrams, prototypes, etc). The team should agree which techniques, notations, and standards to follow when creating models and diagrams. Training may be needed by some team members (see #2). Text should be kept to a minimum because words have so many different meanings (especially across cultures) and add more risk. Models, diagrams, and tables are preferred. Identifying company-wide standards such as legal considerations, security standards, and technical standards i.e., coding languages, platforms, and architecture framework, increases the development team’s understanding about the project technical constraints.
2) Acquiring training as needed for the team – specifically regarding requirements elicitation, analysis, and validation techniques or templates. If the project incorporates anything new from the previous item training may needed to provide a common baseline for the team.
3) Scheduling more frequent structured meetings and formal communications. A conference call schedule for when requirements will be elicited, analyzed, and reviewed, who will be involved, and what techniques and tools will be used to develop the requirements. When scheduling meetings for disparate teams try to alternate the time of the meeting regularly so that the same stakeholders are not always inconvenienced by the time zone differences. A clear work session agenda should specify purpose, topics with time boxes, and roles and responsibilities such as identifying who is facilitating the discussion, and what participation is expected from each attendee, what outcome is expected, as well as what collaborative tools will be used. Try to keep discussions focused and short to keep remote participants engaged. Have more frequent shorter meetings rather than broad discussions that can be difficult over the telephone.
4) Adherence to a well-understood and formal change control process. Developers should not be adding in any functionality that was not part of the agreed requirements. Business stakeholders should not be directly communicating with the developers to request additional functionality. Change requests need to be documented and assessed before they can be added to the project scope.
5) Using collaboration tools, wikis, and Internet/intranet project repositories where information can be centralized and shared regardless of the person’s location. Certain web-based tools are needed to view and update information by the project team whether they are inside or outside the company’s firewall. The team should be able to access the project documents like the requirements package as they need it. Additionally collaboration tools can be used by the development team to show/build prototypes and share details with the rest of the team.
6) Maintaining a secure infrastructure for role-based access to information. This includes maintaining proper security access to view sensitive requirements documentation, any other protected intellectual property such as, internal business processes or other assets such as, customer or account information. This may include determining which team members have “view” privilege and which have “update” privileges to specific project documents.
Having people from different time zones and diverse cultures adds another layer of complexity on your global project to delivering clear requirements, but this risk can be managed successfully. Your comments about working on 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