Business Process
How to Improve ‘Listening Skills’ When Gathering Functional Requirements
Summary: Listening skills help business analysts gather the right level of information to document functional, technical, and business requirements.
The ability to listen – not just wait until the other person is finished, so you can have your say – is one of those skills that makes you better at doing your job.
Learn more about this Functional Requirements Evaluation Form
Listening is one of those ‘soft skills’ that give you an insight into how something works, why it’s needed, and how you can apply it. It also gives you something else.
Listening helps you feel what is NOT said. What others imply, suggest, or hint at.
As someone who works in project management, process design, and proposal development listening to what others are saying – and leaving out – makes a huge difference.
Let’s look at process design.
Let’s say we’re building a new banking application and want to understand the requirements. Where to begin?
There’s usually three phases involved in writing requirements.
- First, when the customer outlines what they expect to be delivered. In general, these are the known known requirements and should be easy to agree on.
- Second, is when the customer, who may not be sure about some feature, introduces another requirement. You, as the business analyst, need to work with the customer so there is no ambiguity or assumptions.
- Thirdly, when the functional specs are still in flux because the application is getting designed, and as they see prototypes, have new ideas, which of course translate to requirements.
In the middle of all this, you need to listen to what’s going on.
For example, if you are working with an overseas client, say using Skype for conference calls, you need to tease out what’s driving the customer to introduce these new requirements.
For me, what makes the most difference is when I remind myself to actively listen.
This means you listen not only to their needs, but are sensitive enough to help them articulate what they’re trying to explain. If you can do this, you’ll find that you capture more accurate requirements faster, avoid confusion, and build trust.
How to listen when taking requirements
Listening is a so-called ‘soft’ skill. But it’s still a skill.
It’s underrated as you, the listener, don’t appear to be doing anything.
Talking looks more impressive as the speaker appears to be taking action. In truth, they’re often saying things because their nervous, impatient, or have little interest in others’ needs.
Every really successful business person I’ve met has known how to ask probing questions and listen to the response. A lot of them also take notes.
Here are three ways to improve your listening skills:
- Remind yourself to listen. It’s easy to forget when everyone’s jostling for space. But find some way, for example, setup a reminder on your phone, to LISTEN. Now that you’re prepared to listen…
- Slow down. Take a deep breath and prepare to be hear what the other is saying. In other words, stop competing. Stop responding mechanically. Instead, pause, take note, and help the other person feel that you are NOW listening to them.
- Ask for clarification. When the customer explains something, and you’ve had a moment to digest it, ask if you can explain it back to them as you understand it. This gives them a chance to review your understanding and, if done correctly, help them see gaps in their own explanation.
Once you get into the habit of listening, it becomes easier. More than that, you begin to see how useful a tool it is and will use it more often.
Listening has another benefit.
As others are spending time talking, you can look for holes, gaps, and contradictions. This gives you an advantage when you have to fight your corner. Like a good debater, if you listen carefully, you see the gaps in others arguments. Once you have identified this, it’s easier to control the situation.
Returning to writing requirements.
Listen to:
- What is being said.
- What is implied.
- What has been overlooked.
Most business analysts will get the first two. If you train yourself, you’ll get the third.
Learn more about this Functional Requirements Specification Template
