Business Analysis in Offshore Projects - Part 1

by Gary K. Evans

I work with many groups who have adopted some form of a development process involving outsourcing or offshoring the technical development. When these organizations have elected a linear, waterfall software development process, the business and technical requirements must be identified and articulated as completely as possible up-front in the project, and intensively scrubbed for clarity so they can be understood and implemented by persons whose native language is not English, whose work culture differs from that of the U.S., and who may not share our American in-your-face willingness to push back when a specification is incomplete or contradictory.

Just a few of the challenges experienced in offshored projects are:

• Cultural and language differences
• Different approaches to completing tasks
• Different attitudes toward conflict
• Different decision-making styles
• Geographic and time zone distances
• Staffing practices and skill sets required
• Staff turn-over rates that are higher than we are accustomed to in the U.S.

Many of these challenges properly fall into the jurisdiction of Project Management, but for the BA or BSA the challenges of offshoring are more challenges of degree rather than challenges of kind:

• Accuracy of features and requirements for the project
• Clarity of expression for a non-American reader for whom English is a second language
• Awareness that the reader may not speak English at all
• Limiting vocabulary and eliminating culturally-specific jargon and slang
• Simplicity rather than over-specification
• Adapting to the needs of the reader and development group
• Visual expression wherever possible (e.g., UML)
• Understanding of the software development process being used by the offshore developers

First - You Are a Writer

In all cases, when you as a BA or BSA produce a written specification, focus first on the accuracy of what you are specifying - and then think carefully about how much precision to include in your specification. When there is uncertainty about what you are specifying, any attempt to be over-precise will be ill-advised, but you can always be accurate in what you specify. Being too precise early in a project is just as dangerous and costly as not being precise enough by the end of a project.

The foremost guideline I can offer any BA or BSA writing specifications for offshore development is this: you must first think of yourself as a writer - and as a business or technical specifier second. This guideline is always true, but it has special nuances in offshore situations. Even if your specification is absolutely perfect in its content and domain knowledge, if your reader cannot understand the syntax or semantics of your words then your specification is a failure. You are writing for an audience, not for yourself. And your audience is probably "foreign" to some of your language.

In my university days I owned a zippy little MGB sports car. I learned auto mechanics on this car, yet I was initially confounded by the car's British Repair Manual. It referenced "wings", which to me were the front fenders, and a "bonnet" which was the engine-compartment hood, and then there was the references to the "boot" - the trunk lid. The Manual authors wrote perfectly for a British reader, but not for me. You may not have owned an MGB, but you have probably purchased a product made in Japan or China with an Owner's Manual written in some cryptic semblance of English. We too often submit our offshore groups to this confusion, and quite unnecessarily.

But what if you are not really a good writer? How can you improve the clarity of your specifications? Three suggestions:

1. Ask the development group if your writing is clear to them.
2. Support your BAs and BSAs with an editor on your project who can standardize the terminology, syntax and style across all your project specifications.
3. Augment your project textual specifications with visual models such as UML (Unified Modeling Language) diagrams, or more traditional diagramming artifacts such as Context Diagrams or Functional Decomposition Diagrams.

Quantity Delivered vs. Quality Obtained

Last year I spoke with an internationally-known consultant who had visited one of the very large IT shops in India. While on a tour of the facility, this consultant asked his guide, "What does your organization really do with those huge specifications you receive from American companies?" His guide pointed out a young man working in a corner cubicle and politely replied, "Our schedules are really too tight to read all of those specifications, so Ashok rewrites them to a size we can manage. If we miss a requirement or misinterpret a need, we will be asked to redo it." True story.

But what should this mean to us? It strongly suggests that even if you and your team are very good writers, creating larger and more precise specifications may not be the right approach. One blog respondent notes "Many development managers feel that they can "throw the requirements" over seas and expect magic."

I have worked with two organizations that overcame this "throw the requirements" attitude. Both brought at least one key representative from the offshore group to their location here in the U.S. One group was using a Russian development team, and the other a European team. Both organizations produce specifications, some quite large. But the quality obtained is from the interactions of the key representative with the American BAs or BSAs, and any local developers and architects. Since this representative comes from, and understands, the development group's culture and native language(s), not only are major misunderstandings avoided, but many of the more numerous minor misunderstandings are circumvented as well. The BAs and BSAs can interact both indirectly and directly with the offshore teams to assure accuracy of understanding, and increasing precision as the project unfolds.

Next month I will offer some very specific ideas for BAs and BSAs to specify business requirements, user requirements, and technical requirements for an offshore project. And all of these suggestions will improve your specification for in-house communication as well.

Have a productive month,

    Gary K. Evans