Skip to main content

Know Your Audience

As a Business Analyst, effective communication is critical to effective and efficient elicitation of requirements.

Communicating at the right level of detail and empathy creates a stronger relationship between the Business Analyst and the business.

I’ve often joked that as analysts we are sometimes psychologists and even mind readers. When eliciting requirements, you should pay attention and look for those subtle (and sometimes not so subtle) clues that you need to ask more questions.

Observe and Engage Your Audience

Picture yourself in a room with a group of subject matter experts and their management. The purpose of the meeting is to understand and document an end to end process with a team of subject matter experts that are very knowledgeable in the process. You notice one of the managers is doing most of the talking and everyone else stays quiet. The manager is describing a fairly simple process that is running quite smoothly. When you glance around the room as he or she is speaking, you see one team member rolling his eyes. Another has a surprised look on her face. These are important clues there is more to the story, and you need people other than that manager to talk.

In this situation, I thank the manager for all the great information he or she has provided and then explain it is time to involve others in the room. I look at the woman who was acting surprised and ask about her role. Then I ask for examples of when the process isn’t straightforward. What are the exceptions? What goes wrong? She hesitates at first but then starts describing five exception scenarios where the process takes a completely different path. When she is done, I thank her and describe how critical her information was in helping me document the end to end process. I continue to select others in the room, prompting them and encouraging them to share more.


Make Everyone Feel Comfortable

It is important to make people feel comfortable talking. If they look uncomfortable, they may be afraid to contradict what their manager said or may be uncomfortable speaking in front of a group. In this case, I try to throw out examples of what I believe is happening in the process or where I could see something may go wrong to prompt agreement or disagreement to start the conversation. In some extreme cases, I have ended the group meeting and asked to sit with a few members of the team one on one where they may be more willing to share.

Show Your Appreciation

Do not forget to show appreciation and recognize each person’s contribution as important to understanding the process. The more they feel involved and appreciated, the more likely it will be for them to help again later. Confirm their time is valued and important to the project.

Appropriate Level of Detail

A common mistake I have seen when reviewing requirements is it contains the wrong level of detail for its intended audience. As much as I like to minimize the amount of paperwork required for a project (which is why I am a fan of Agile Scrum), there are times when doing Waterfall projects that a one size fits all requirement document does not work.

If the approver of the requirements is going to be a senior vice president of a very busy customer service area, it is unlikely that they will want a 150-page requirement document with technical details, samples of code and XML files. For that person, I need to take it up a level and give them what they need to feel confident they will get their needs met. They want to know I understood them and will correctly convey what they want to the IT teams, training teams, and other stakeholders. I need to understand and use the business terms they use every day. If I can supplement those descriptions with screen prints and basic mock-ups of the changes, that is even better.

Get Technical with the Right Audience

For the developer and QA teams, this level of detail is also useful (if they take the time to read it!). For this audience, we often need to add more technical requirements. Including which database contains the data or which script needs to be updated can be critical to getting the correct results. Depending on the organization and how technical their analysts are will probably drive how far an analyst documents the technical changes needed versus what a developer will define and document.

If you plan to do a walk-through of the requirements, consider the pros and cons of including the technical and non-technical stakeholders in the same room. I’ve seen it too many times where business VPs are in a room either yawning or reading emails on their phone because the Business Analyst is talking in too much detail about the code changes. You’ve lost their attention when this happens you lose the opportunity to find an incorrect requirement early in the process. In the opposite scenario, developers are falling asleep listening to business people disagree about what the exact verbiage of a legal disclaimer.

Plan Your Engagement

Know your audience both regarding the documentation you provide and how you approach meetings. Plan to make sure the right level of detail for your audience. Plan your meetings with a clear agenda. Set expectations clearly on the expected outcome of the meeting. Keep your audience engaged by paying attention, prompting feedback and clarifying statements to avoid uncertainty. And sometimes bribing them with fresh coffee and snacks doesn’t hurt!

Exceptions to the Rule

Of course, there are always exceptions to what I’m describing here. I had one senior level manager that I worked with who was a former subject matter expert of the system. I knew I had to include the technical piece for them otherwise they would just come back and ask me for it. It all comes back to knowing your audience and knowing their expectations. When in doubt, ask them what their preference is; or provide both a business version and the technical version.