Business Analysis in Offshore Projects - Part 2

by Gary K. Evans

Offshore projects need special care. Offshore developers are not just "remote " developers. They are usually "different" from us by language, culture, time-sense...even what they accept as comfortable personal space. Here is an offering - in no particular order - of some practical ideas I have learned on my projects that involved offshore development.

• Reconsider how you partition your requirements content for delivery to the offshore group. Emphasize readability and ability to cross-reference content for understandability over conformance to your (American) corporate template for requirements - even if you have to depart from your (internal) corporate templates.
• Consider disassembling large, interleaved documents into smaller, discrete documents: one for functional requirements, one for non-functional criteria, one containing only use cases, etc. Multiple, smaller documents have a higher probability of actually being read than does a 300-400 page monolithic tome.
• Ruthlessly pursue a standard that all documents are clear and concise, with a limited, simple vocabulary, devoid of slang or Americanisms. Create an editor role in your company, and install someone with excellent writing and communication skills who can assure that all requirements documents going to the offshore group are consistent in vocabulary, grammar, and style.
• Do not ask the offshore vendor if they "understand" and like the documentation formats you are sending. They will probably say "Yes", even if they don't understand. Ask them to define a new format that meets their needs and understanding.
• Seek alignment between the development process followed by the offshore group, and the specification process followed by your corporate analysts. A waterfall specification process feeding an iterative, or agile, development process will show cracks of misalignment early, and often.
• Don't leave your brain at the door: your project will not succeed just because you are investing large amounts of money. As Ronald Reagan admonished, "Trust, but verify".
• Don't measure success by calendar milestones. Validate your project's status by the actual, working code, not status reports. Get early and continual feedback on the project through working (or non-working) code so you can make necessary improvement by the smallest possible adjustments.
• Text is inherently subtle, and in the hands of less-than-skillful writers, text can be alternately vague and ambiguous, or otherwise misleading. Strongly consider incorporating any and all forms of visual specification on your project. Remember the obvious: your techies probably were not English majors.
• UML is a de facto standard for visual specification, and can be an invaluable improvement in productivity and clarity of expression. UML is unambiguous, precisely defined as a grammar, and not terribly difficult to learn. Its visual focus is not prone to misunderstanding the way natural, written language is. This is a compounded benefit when you consider that English is a second language for some, or many, members of your offshore team. And some of them may have almost no facility in English.
• Accept that some of the offshore team may speak and know English structure better than you. But in India, your team will have been thoroughly schooled in British English, not American English. As George Bernard Shaw wrote, "The British and the Americans are two peoples separated by a common language". Beware.
• Analyze the channels you use for communication between your company and your offshore partners. Strive to use the "warmest" channels you can, and try to limit the "coldest". Here is a sample spectrum: (warm) face-to-face, video, telephone, instant messaging, Twitter, email, project documents (cold). Isn't it interesting that the "main" way we communicate requirements is the coldest?
• Exchange on-site team members if at all possible. I have seen this solve a host of problems, and provide clarity to all areas of a project.
• Stipulate in your contracts that payment will be made only after acceptance criteria have been met, not when a calendar duration has elapsed. Include penalty clauses for late delivery.
• Share your project's Business Requirements with the offshore team, in addition to the System Requirements and other requirements. The Business Requirements can help the offshore "techies" see beyond the limited technical landscape of their development job, and appreciate the overall business goals and perspective of the project. "Knowledge is power" - Sir Francis Bacon.
• If your offshore group is also producing design artifacts from your system requirements, you will presumably be validating their design at some time. Compel them to deliver their design in appropriate UML diagrams or other visual representations, as well as in textual design specifications. You will benefit from the native language-independence of the visual models just as they will.
• Feature lists are not sufficient, even for American developers. Incorporate use cases on your project so your offshore team can read them and appropriate understanding of the system behavior they need to ultimately implement to satisfy the needs and goals of your system's users. Feature lists focus on the system; user cases focus on the user. You need both, and offshore developers really need use cases.
• Recognize that use cases for offshore use should "bend" the rules for what a use case can contain. Here is a graphic from Alistair Cockburn that describes two use case perspectives (click for a larger version). The "A"-level use cases are known as essential use cases. These are the ones you should always produce. "A"-level use cases are devoid of technology, data format, and user interface content. These focus totally on "what" a system should do to meet a user's goals.

  The "B"-level use cases are really design specifications dressed-up in use case format. These "B"-level use cases still convey the process definition to accomplish a user goal, but also contain design- and implementation-specific content. For offshore teams you need to produce and provide both: the "A" use cases describe "what" behavior the system must support; the "B" use cases describe "how" this behavior should be realized.

I hope this brief list will be helpful if you are involved in an offshore project, or if you become involved in the future. All of this suggestions are common sense, but the subtleties of offshore development always seem to confound us with many details.

Have a productive month,

    Gary K. Evans