3 Ways to Conduct Elicitation Even If You Aren’t in a Business Analyst Role

Elicitation is a fundamental business analyst skill and is used by BAs and non-BAs alike to:

• Gain clarity on what’s expected from a project assignment;

• Understand an existing business process or system; or

• Create a shared understanding of the problem to be solved.

You can even use elicitation techniques as a sales person to understand your potential customers’ pain points or at home when trying to understand your spouse’s point of view on a contentious subject.

In my last article, I listed 3 business analysis activities that nearly any professional has an opportunity to apply. Those activities are:

• Scope a Project;

• Facilitate a Meeting (or part of one);

• And Analyze a Business Process.

I also provided a step-by-step process for getting started analyzing a business process. In this article, I’ll show you how you can apply three specific business analysis elicitation or requirements gathering techniques as part of facilitating all or part of a meeting even if you aren’t in a business analysis role.

#1 – Understand the Problem

Nearly any conversation can be improved with a shared understanding of what problem you are trying to solve. BAs keep asking questions about the problem and avoid too much discussion about the solution until everyone is in agreement about the project objective.

You do not have to be a BA to apply this skill. For example, in my not so humble opinion, what makes a salesperson a pleasure to work with is when they take the time to understand not just what I want, but what I need, and be true to that problem throughout the entire sales process.

If you happen to be a software developers looking to become business analysts you’ll especially benefit from practicing this skill. Being technically focused and full of ideas for how to solve a customer’s problem, many software developers quickly jump into solution mode. If you aspire to be a business analyst, stop yourself. When talking to a business stakeholder about a problem they are having take pains to understand the problem from every which way – the end-to-end process, the impact of the problem on the stakeholder, and what will be the case once the problem is addressed or minimized.

In order to solve the problem, you must truly listen to what your stakeholders need and not just what they want, and that brings us to the second way you can conduct elicitation outside a formal BA role.

#2 – Use Active Listening Techniques

We might wish that our stakeholders would come right out and tell us what they really need, but it just doesn’t work that way. Getting to the real problem – the root problem – may take several carefully crafted “why” questions, designed to get at the underlying problem without irritating your stakeholders. Unlike a 2-year-old we can’t really ask “why” five times (even though the 5 Whys is a formal business analyst elicitation technique). No, we need to ask why with finesse.

We also need to listen. Often just by listening more actively, we can help our stakeholders communicate the underlying problem. Active listening can involve body language such as eye contact or note-taking, but the most powerful technique is to simply summarize what you heard to confirm understanding.

Often what the stakeholder attempts to communicate and what you understand are different. By paraphrasing what you do understand you are able to keep the conversation moving. After paraphrasing, you often don’t even have to ask a question. The stakeholder hears what you are missing (or what they failed to share) and begins clarifying.

You don’t need to be a BA to practice asking why without being irritating and especially not to actively listen. The next time a co-worker complains about a problem, you could summarize what you heard. Or, the next time your manager assigns you a new task, you can reframe it in your own words to ensure understanding. I’m sure your family would appreciate your attempts at active listening too!

#3 – Ask the “Stupid” Questions

Many new and aspiring business analysts see their lack of knowledge as a liability. The reality is that it’s one of their greatest strengths. When you are a business analyst and your job is to confirm understanding, analyze requirements, and validate a go-forward approach, there is almost no stupid question. Well, wait, there is one. The stupid question is the one that you didn’t ask.

Let me share an example from my own early career. In one of my very first requirements meetings, I sensed that the two developers in the room were not communicating clearly. However, they were using very technical language that I didn’t completely understand and I didn’t speak up. I pushed back the inkling that something was amiss and didn’t ask the question. After all, as the new business analyst, I didn’t want to appear that I didn’t really understand the technology and I didn’t have the confidence to make a communication mistake that I thought would make me look stupid. Two weeks later, it turned out that each developer had invested time in part of the solution and their two pieces conflicted with each other. They had not been communicating. If I had asked my question or used active listening to summarize what I had been hearing, I may have been able to save the wasted time and I would have looked pretty smart even though I would have felt rather stupid.

There are many ways to practice this. A simple way to warm up to the idea of asking the “stupid” questions is to be on the lookout for acronyms. The next time someone uses an acronym that you are not familiar with (or if you know that someone else is not familiar with), ask them to define what the acronym means. As you gain confidence that asking stupid questions is not going to make you look stupid, take on bigger communication challenges. For example, if you sense that something is off in the conversation or directly hear people using the same words to talk about different things, stop and ask a question. You might want to start by paraphrasing what you heard first and then ask for clarification. Or, simply apologize for not understanding and ask the information to be rephrased.

By asking the questions no one else will ask, you position yourself a self-confident communicator – the one who can slow down the conversation and ensure yourself and everyone else involved in the discussion understands what’s being communicated. And that makes you look smart, not stupid. You will also be practicing an elicitation technique that experienced business analysts use to succeed at driving communication regardless of how much they know about the domain.

What Does This Mean for an Aspiring BA?

I’ve identified 3 techniques that experienced business analysts use to improve their elicitation and requirements gathering sessions. You don’t have to be a BA to use them! You can use them in any business conversation. And what this means to you is that you have opportunities to be a BA here and now by incorporating additional elicitation and requirements gathering techniques into your everyday conversations. And doing so will help you inch closer and closer to business analysis.

Author: Laura Brandenburg, CBAP is the author of How to Start a Business Analyst Career, the host of Bridging the Gap, and offers an email course (it’s free!) to help seasoned professionals transition into business analysis careers.