Author: Greta Blash

Lost in Translation

Written by Greta Blash on March 1, 2011. Posted in Articles.

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.

Elicitation

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.

Champion of Change – The Business Analyst

Written by Greta Blash on January 4, 2011. Posted in Articles. 2 Comments on Champion of Change – The Business Analyst

Six months after implementation of a new software application, complaints were heard, such as “The software doesn’t work” or “It’s too cumbersome.” After several weeks of post-implementation analysis I determined that the problem was not with the system but rather the resistance by the users to the changes required by the new system. This resistance had become so strong that a replacement of the new application was already being considered.

Upon completion of a project, the organization will have to cope with the inevitable changes that will affect the business. This is a classic example of where the business analyst has to be a “Champion of Change” and mitigate the impact of new systems on workers at all levels in the organization. Project success doesn’t just mean delivering on time and on budget — but includes genuine acceptance by the people in the organization who will benefit or, in some cases, be impacted negatively by the new implementation. This aspect of the project is often lightly touched upon or brushed aside as the BA views these changes as merely part of project communications (“Just tell the employees what needs to be done in the future”), or training (“Just send them to a training session”). In reality, acceptance of change can either make or break a project effort and needs to be addressed throughout the project.

The implementation of the application will always result in some change to the organization’s structure, processes, systems and/or jobs. Whenever change of any type happens within the organization it requires extensive planning and hard work to ensure the change is implemented in a manner that will be embraced by all. This change applies to all individuals, or stakeholders, who will be impacted by the results of the project. They are the ones that Mark Twain’s quote would apply to best, “I’m all for progress. It is change I don’t like.”

The business analyst utilizes a set of tools and techniques to elicit and manage the business requirements. These are usually focused on understanding the requirements necessary for the software and technical aspects of the application and can challenge a business analyst’s “hard skills.” On the other hand, the “soft skills” of a business analyst need to stay focused on the stakeholders and workers impacted by the change that is inevitable. This includes providing support and empathy in addressing resistance while helping mitigate the eventual impact of the final solution to the organization.

Stages of Change

When business change is inevitable, the business analyst needs to be aware of and identify:

Specific organizations and jobs that will be impacted
Individual business persons from those organizations who will most likely accept the changes as well as those who will resist the changes
Potential discussions that can be facilitated to address the changes that will occur, giving individuals the opportunity to share their concerns, provide feedback and ask questions
Concerns that need to be addressed in order to potentially move stakeholders from a non-supportive to a supportive position

Understanding the various stages that a person goes through when presented with change will also help determine the appropriate way to proceed.

Denial of change
Response of anger and resistance
Acceptance and adaption to the change
Commitment to the new way

During this time it is critical to continually monitor the resistance, as well as the acceptance to the new environment, as various stakeholders progress through these stages at different rates.

Communication

A communication plan will need to be targeted for each of the different audiences impacted by the change to ensure that the most effective communications methods are being utilized. The BA needs to identify the right message, at the right time, the right format and the right “authorized” sender to carry the message to the organization.

These types of communications are often best conveyed by someone in the organization, other than the BA. By working with management and project sponsors, a strong and active coalition of senior “leaders” can be gathered to craft the key messages, or “sound bites” that must be communicated. Just as in political debates, often impressions are made based on a few words, and therefore these words need to be very carefully chosen.

The initial emphasis should focus to making the case of “why” the change is needed, even before the specific details of the solution are complete. This is very similar to the development of a marketing plan for a “product”, without which no new product would be expected to be successful when “rolled out”.

These messages need to be incorporated into the development of a training plan that will include not only the normal operational training aspects but also the “selling” of the benefits or reason behind the change. This may require not only formal training, but also potential mentoring and coaching to effectively enable the change throughout the organization.

Final Thoughts

To truly become a champion of change, the business analyst should consider the following suggestions:

Seek support from management and then support them.
Choose your battles wisely with the people, management or supervisors.
Be patient with the rate of acceptance; some take longer to see the light.
Be tolerant of mistakes; they happen.
Practice good stress management; you’ll need it
Have a sense of humor; you have to laugh sometimes.
Embrace the future and don’t get “bogged down” by the past.
Recognize and reward the accomplishments of those who were instrumental in enabling the change – Yes, it’s time to party

Most of all, remember the purpose of a project is to provide a benefit or improvement for the organization, and with that, something must change. If there was no need for change, there would be no need for business analysts!!!