Corporations often build offshore development teams as either an extension of their domestic teams or to serve as core groups. This means that product management teams often have to overcome a unique set of problems to communicate requirements across the miles.
One of the fundamental tenets of product management is that you should communicate market requirements without being specific about the implementation. But there are significant challenges to this when working with offshore teams:
Lack of business context. Something as fundamental as a work order might not be commonly used in the host country, and often teams have no real, practical grasp of the driving forces behind the users’ goals.
Language barriers. Due to limited face-to-face interactions, written communication is critical, but it is susceptible to misunderstanding resulting in rework and project delays.
Culture. Teams residing in countries with centralized authoritarian systems and/or collectivistic cultures tend to resist development methodologies that don’t rely on discrete instructions and finite deliverables (e.g., Agile) and have a strong preference for rigid requirement documents and deliverables (e.g., Waterfall).
Size. To compensate for potential skill challenges and hedge for personnel turnover, teams are typically larger. Getting all these team members on the same page—especially without face-to-face interaction and while overcoming time zone differences—requires a great amount of effort and coordination.
Avoiding the Prescriptive Requirement Documents Trap
A hybrid framework, combining some of the elements of both Agile and Waterfall methodologies, can be instrumental in achieving success in early-stage offshore teams—before any measure of maturity has been developed (which typically occurs at 3-5 years for highly technical, niche products). This allows the organization to develop core competencies in critical areas early on, while also enabling the team to ramp up productivity in a reasonable time. Later, more traditional Agile methods can be gradually introduced, adopting elements of each method that best fit needs, circumstances and skillsets. (For example, you could develop market requirements documents using Agile methodology elements such as high-level requirements, context scenarios and personas. And you could develop other artifacts such as project plans, system requirement documents and test plans using more Waterfall-like processes and methods.)
Here are some critical factors to successfully integrating offshore teams:
Delegate a liaison. This person—commonly referred to as a business analyst, team liaison or product owner—should serve as the main point of contact between local product management and the remote team. It is unlikely that this would be an independent role, but this individual will be an invaluable resource that can work directly with product management to help develop requirement documents, answer questions from developers and perform quality assurance—escalating only issues and questions that cannot be resolved independently. This resource will develop system-requirement documents in collaboration with product managers or engineering managers, based on the market requirements document developed by product management.
Expand user goals and requirement descriptions. These need to be significantly more elaborate than typical requirements to provide enough context. Succinctness is not always a virtue in this scenario.
Don’t say: “2.2.5.3 Sorting: Unless otherwise stated on the system requirements document, tables should default to sort by newest to oldest data.”
Say: “2.2.5.3 Sorting: Unless otherwise stated on the system requirements document, tables should have the sorting function enabled on each column. The sorting default should be newest to oldest based on the date column.”
To a native English speaker, the first paragraph has the same meaning as the second. The phrase “sorting a table” (while grammatically vague) can only mean that the columns within can be sorted, and the only way that sorting can occur is if that function is enabled. These are the types of stylistic shortcuts we usually take when writing internal documentation. But for a non-native speaker, drawing all these implicit conclusions is very confusing—in part, because the syntax of their native language is very different.
Create personas that represent both external users and internal stakeholders. The advantage of this approach is that it overcomes internal resistance to deliverables. (Why do we need this? We should defer this feature.) Internal deliverables like building a sales demo are typically not directly correlated to personas. Under this framework, however, describing an internal stakeholder that won’t use the end product but has a stake in a specific project or product goal is extremely beneficial. Not only does it indirectly provide additional context to a requirement, but it also explains the business and cultural environment for the developers and the whole offshore team.
Let’s consider this example for the fictional Stark Corporation:
Context Scenario for John, Sales Representative persona. Several times a year, John presents the ProActivities portal demo to potential customers. He has noticed that it contains outdated dashboard samples. His other option would be to show another customer’s data directly from the production portal, which would not be acceptable because the data is confidential. The demo site cannot be accessed half of the time, because the client cannot provide him with a network connection, the demo site is down or something else in his laptop operating system has changed causing problems with the browser. He just wishes he could demo the portal offline, so that he would know what to expect and avoid any unwarranted negative perception of Acme’s solutions.
Requirement. Develop a subset of the online dashboard using a technology that conveys the look and feel of a multimedia, rich Internet application.
Group. Develop exciting online/offline dashboards and offline demos using BIP/Flash.
Although various external end-user personas and context scenarios existed (not shown in the illustration) to support the requirement, this scenario supports the notion that a set of features that allows offline dashboard interaction is needed and reinforces that a mature look and feel is critical, since it affects the sales cycle. (Note: It could be argued that in an Agile paradigm, even the mention of “Flash” falls into prescriptive territory. But as we are explaining in this article, depending on the offshore team maturity, some exceptions to this stance are pertinent and beneficial.)
Using various channels of communication is more critical when verbal communication is infrequent and work is done in different time zones. The expanded use of personas and user stories and the designation of an offshore resource as a main liaison will go a long way to building a process with built-in redundancy to traditional communication methods such as prescheduled conference calls and on-site visits. These will serve as safeguards that make it less likely that minor miscommunications derail your project.
