Lost in Translation
What does the phrase, ‘Lost in Translation’ mean?
It refers to the situation when you try to translate something and the original meaning can not be directly translated into the secondary language. In these cases it must be rephrased or restated in a different way. The result is that some things are never able to be translated properly. That is especially the case when attempting to tell a joke to a foreign audience! – Don’t attempt.
How does this apply to a Business Analyst (BA) whose role is to define requirements?
When my children were young and they asked “what do you do?” – I would try to explain that my job was to translate. I had to understand the language used by the business and translate that into the language used by the IT developers. Having spent time both in IT as well as business functional areas we understood a little of both “languages”.
The BA has to translate the business goals, objectives, rules, processes and data into business requirements that all stakeholders can understand and agree upon. Often the BA has to rephrase, restate or “translate” the meaning of the business requirements into words that can be understood by all. A good Business Requirements Document (BRD) fosters communications between the business people and IT developers by enabling them to share the common vision that will be translated into a technical solution as part of implementation. It is critical to capture a clear understanding to ensure the “system” meets the expectations of the business people. Problems often occur when the BA has to communicate across multiple business functional areas. It can all go horribly wrong if the business people were unable to completely understand what was written in the BRD (especially if it was written with more “techie” terms) – or they never read or approved of the document in the first place. If the final result of the “system” does not meet the expectations of the business stakeholders – the blame is usually placed squarely on the shoulders of the BA.
Most BAs or their organizations have standardized and streamlined their BRDs and Use Cases so they look familiar, and can easily be interpreted by the developers. If the developers are able to read and understand the BRD – can the business users? Often these BRDs are written in more technical terms rather than in business terms with the BA spending more time facing towards IT. But more often the real question is — “does the BA really understand the business?” Is what has been written in the BRD captured the real requirements – with the translation having been done correctly?
Rather than facing the developer when creating the BRD, a thorough understanding of the business requirements will help ensure a better result. There are various characteristics of business people that need to be understood. They all come in a variety of flavors: Some are very academic and intelligent while others are very down to earth. They definitely are not “standardized.” Often the stakeholders assigned to the project have no prior project experience and therefore no clue of what is expected of them. Business management often feels that it is the BA’s responsibility to get the correct requirements – not the business team members. As a result it is important that these team members are continually involved in the BRD process. In order to understand, verify and help make adjustments where necessary, the process of developing, as well as the final BRD document, should be oriented to the business understanding. It is a good idea to “walk through” various portions of the document with the appropriate stakeholders as often as possible before finalizing the entire document. Some of my business stakeholders have said to me through this review process “You wrote what I said, not what I meant to say,” “Did I really say that?” or “I couldn’t have said that – I need to rethink this point.” I am sure that you have heard similar comments on numerous occasions.
Let’s take a look at the problem of interviewing business stakeholders during elicitation. The BA asks questions and takes notes that are later translated into the BRD – which is usually written at a basic high-school level (or below). The BRD usually contains the requirements gathered from multiple stakeholders compiled after many reviews and corrections being made. I have been amazed at how many business stakeholders only casually read the BRD, if they even read it at all. When I start to work for the first time with a business stakeholder, I will deliberately include a few minor errors to see if they are caught by the reader. I realize that some BAs object to such actions because it might reflect poorly on them, but we all need to feel comfortable that the business stakeholders are fully involved in the review process. We need the appropriate involvement to help us feel comfortable that the requirements that we are developing will result in the proper outcome. We definitely don’t want to discover the errors at the time of implementation. There are a few stakeholders who find all our punctuation, spelling and grammar errors – and thoroughly enjoy this level of scrutiny. Those types of reviews don’t really bother me; at least they are reading it. I just wish they would also respond to questions and omissions on content – not like my high school English teacher.
My favorite elicitation technique (and one that I personally feel results in the most thorough BRD), is facilitated sessions. In order to discover and document “group memory,” business stakeholders are gathered and whiteboards, flipcharts, projectors and screen are used to record the results of the discussions. Since this information is gathered during the session, and remains visible to all attendees, reviews and approvals can be initiated on the spot. This continual review process is especially helpful when the stakeholders are from different functional areas and have different points of view that require compromises. You as the facilitator have to be aware of which participants are right-brain (work best with pictures and/or diagrams) and which participants are left-brain (work best with detail written documents). Often the combination of both types of techniques is needed to gain the necessary group consensus. After the session has been completed, the results need to be documented and sent back to the participants for future review, as well as providing a starting point for the next session, when needed. Use of facilitation techniques is very helpful in “translating” the process being analyzed and produces a BRD that is more accurate.
One additional thought – If any stakeholder is replaced, or a new individual added to the team, you can be assured that the business requirements will change. Even when you have three stakeholders from a single functional area, there will often be three different sets of business requirements. These three sets are compromised into a single document that is acceptable to all. Just about the time you feel comfortable that a set of requirements have been completed, a change to the makeup of the team occurs. Now you will have to go back and gain acceptance of the requirements from all the members of the new team. If you don’t take the time to review with the new team you run the risk of not meeting the stakeholder’s expectation of the final result.
In summary you have to understand each of the tools and techniques available to a BA for understanding and documenting the requirements effort. You also have to understand how the final documentation needs to be tailored to each individual stakeholder in order to maximize the understanding of the content. Only in this attention to detail within the final deliverable can you feel comfortable so ensure that the requirements have not been lost in translation.
Don’t forget to leave your comments below.
Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include business process improvement, business analysis, business intelligence, data analytics, project and IT management.