Communicating Requirements For Offshore Projects

Duration - 2 Days
Available on-site at your location.
This seminar is a component of PESG's Managing Offshore Resources curriculum.
What happens when we hand off deliverables over a virtual wall - or an ocean? What happens to requirements? 
Organizations can realize the expected savings from application development outsourcing, especially offshore, by reducing misinterpretation of requirements and gaining efficiencies in process. Application teams must learn how to adapt their project methodology to meet the communication needs of global application development. This seminar provide guidelines and techniques for success after requirements have been gathered and documented and global teams are ready for refining and validating requirements. This course is compliant with BABOK® Version 2. 
The case study project to create a Requirements Management System (RMS) includes sample deliverables throughout the development life cycle, including a RMS product selection.
Intended Audience
Business analysts, designers, architects, engineers, RFP and proposal writers, and applications team members responsible for communicating or managing requirements intended for offshore resources.
Learning Outcomes
Upon completion of this workshop, the participant will be able to:  
  • Gain agreement on communication protocols to promote understanding 
  • Assess the audience to assure appropriate level of detail and extent of formality
  • Select appropriate requirements gathering techniques (e.g. use case) to match the audience’s need for detail and methods.
  • Uncover and validate hidden assumptions impacting requirements with offshore resources
  • Refine requirements to be more quantifiable and measurable assuring more effective 
  • validation
  • Plan and conduct mock virtual reviews that include offshore resources 
  • Determine the extent of traceability and change control needed based on project needs and your relationship with  offshore resource
  • Use the System Requirements Specification (SRS) to manage expectations and capture baseline estimates so design teams can begin work sooner
  • Determine the impact of changes to requirements throughout the life-cycle
Topics Addressed
  • Frameworks for Level Setting: BABOK®, SDLC, PMBOK®, OMM
  • Gaining Offshore Team Agreement on the Requirements Process
  • Hints and Tips to Avoid Requirement Misinterpretation 
  • Validation Tools & Techniques
  • Offshore Team Involvement in Tracing Requirements and Managing Change
  • Challenges in Requirements Communications
  • What Happens to Requirements in Offshore Projects?
  • Requirements and Product Selection/Implementation
  • Collaboration for Tracing and Managing Changing Requirements
Seminar Agenda
1. Business Analysis Body of Knowledge (BABOK™) Overview
An overview of the knowledge areas provides the necessary framework for future workshop activities.   Planning and analysis deliverables in addition to the case study “Practice What We Preach” is introduced.
a. Enterprise Analysis
b. Requirements Planning and Management
c. Requirements Analysis and Documentation
d. Requirements Communication
e. Solution Assessment and Validation Overview
2. Challenges in Requirement Communications
Use consistent language and format to promote clarity in interpretation.  As organizations have more cross-organizational, externally sourced and global teams, the gaps between assumptions become greater and harder to manage.  The use of natural language is helpful for interpretation to the business, but how about to the teams providing the solution?  The business analyst fulfills the role of the translator between the business language needed for the need verification by subject matter experts and the technical language needed by the solution providers.  What influences how well that translation occurs?
a. Promoting Clarity by Classifying Requirements
b. Natural Language Challenges
c. Cross-cultural Impacts to Communicating Requirements
d. Project Types and Using a One-Size-Fits-All Approach
e. Technology Impacts to Communicating Virtually
3. Knowing Your Audience for Requirement Communications
If you have any business analysis experience, you know how challenging it can be to balance the amount of effort extended in documenting vs. the risk of missing a requirement or having one misinterpreted.  Previously we discussed the translation from business to technical and level of detail based on type of projects, but how do we adjust our effort in documentation based on the audience?  How do we adjust our ongoing communications?
a. Understanding the Roles in the System Development Lifecycle
b. Assessing the Audience Communication Style, Skill and Experience
c. Communication Approaches (e.g. types of diagrams or models)
d. Mapping the Right Communication Approach to the Right Audience
e. Tailoring the Validation and Approval Process
4. What Happens to Requirements?
Sometimes we get stuck in our silos – we live and breathe the System Development Lifecycle role we are in.  But this poses many challenges when we handoff deliverables over a virtual wall (or ocean).  What happens to these requirements?  How do they get transformed into an executable system and a successful project?  As a business analyst, the role doesn’t end at the analysis phase when the SRS is approved or and Request for Proposal (RFP) has been sent to a vendor.  Gaining insight in how the requirements and analysis tools we use and document are leveraged and transformed in future phases helps in more effective communications.

a. Using the SRS and the RFP as an Effective Communication Tool
b. The Project Lifecycle, the SDLC and Future Use of Key Business Analysis Documents
c. How Project Factors Influence the SRS and Future Business Analysis Work
d. Use Cases, Business Models and Analysis Tools for Future Phases
e. Packaging Requirements for Product/Vendor Solicitation (RFP)
f. Packaging Requirements for Offshore Development (SRS – Who does the Design or Technical Specification?)
5. Touch-Points and Solution Validation
Each SDLC role that the business analyst interacts with will be examined.  What are the best practices for communicating requirements to that role?  What is the best approach to validate that the solution will indeed address every requirement and how can that be done when dealing with someone who may be across the world? One mistake can cost a day or more and impact overall project success. 
a. Working with the Project Manager Throughout the Project’s Life
b. Working with an Offshore Liaison or Vendor Business Analyst
c. Transitioning to Designers, Database Administrators and System Architects
d. Working with Developers and Testers
e. Assisting Trainers and Change Agents
6. Requirements and Product Selection/Implementation
It is different, a different way to document and communication requirements when it is part of a bidding process.  But what is different?  The process is examined and hints and tips are provided to assure this isn’t another “big costly mistake”.
a. Variances in Requirements Documentation and Prioritization
b. Types of Requirements that Must be Addressed
c. Understanding Features and Functions
d. Applying Weights and Ratings to Requirements
e. Using Use Cases for Conference Room Pilots
7. Collaboration for Tracing and Managing Changing Requirements
Traceability – a scary word for many business analysts.  Takes a lot of time and effort – but is it worth it?  Risks and impacts are discussed.  There are tradeoffs, but there are also huge benefits and there are tools out there that can help.  Just be sure not to let the tool drive the process!

a. Correlation Between Traceability and Assessing Change Impacts
b. Working the Change Process with Vendors and Offshore Teams
c. Alignment to Previous Agreements (Business Case, Project Charter, Statement of Work, etc) and Managing Expectations
d. Tool Features Most Useful for Requirements Collaboration
e. Solution is Implemented – Now What?