Imagine a team of business analysts gathered in the conference room discussing new features with stakeholders.

After the meeting they compare notes and are surprised at the differences in the information gathered.

Each business analyst had a list of questions for the stakeholders. They were all very similar:

What are you trying to achieve with the functionality?
How will it support your current business processes?
How often do you perform this task?
Do you receive inputs from another person or document?
What is done with the completed output?
How do you accomplish this today?

The client answered all the questions and some viable solutions were discussed for the requirement. The assigned business analyst had an in-depth discussion about what would work for the stakeholders and what wouldn’t. Questions were asked and answered about priority, what were their must haves and what should be delivered first. This process was repeated several times as each business analyst presented their initial investigation results. The stakeholders provided a wealth of information.

Business Problem

The stakeholders described their issues and gave specific examples. It wasn’t entirely new information. It may have been the reason the meeting was called. They reiterated the business problem and scenarios. They stated what they need to be able to do and why.

Current Work Flow

They went into detail about their current process. They begin with this piece of data. They review the files and documents and look for specific information. Key figures are located, calculated and input into the system. Reports are generated, analysis begins, and proposals are made.

Frequency

When asked how often these tasks were performed, we found out that it was a good portion of their week. This was one of their major job functions and they might start this process in the morning, stop for a meeting or lunch and then resume. We gained more insight into the need to work two projects at the same time.

Expectations

The stakeholders told us what about the current process was frustrating and what changes could make it better. Some were large requests, others were very small changes. Any of them would make a difference in their daily work lives. Some would make them happier than others.

Comparing Notes

Everyone in the room heard this information, but all of it was not reflected in their meeting notes. The content collected ranged from a few lines to a few paragraphs per person. Why is that? There could be assorted reasons including:

---

---

The focus is on answers to specific questions

If you have completed some initial investigation, you have a list of questions for the stakeholders that you need answers to. You may be listening for these answers and filtering out the rest. It’s not always easy to switch between the question you asked and a new topic or question that your stakeholder raises.

Take a deep breath and try pausing the conversation to “jot this down”. You can also ask teammate to act a scribe during your discussion until you become more experienced.

The statement was obvious or easy to remember

Most people don’t write down statements that they have heard before. It may seem like a waste of time or duplication of effort. In reality, you need to know what is important to each stakeholder and what issues are important to multiple stakeholders. This will help in accessing priority.

Everyone thinks they have a good memory until they don’t. Writing (hand writing on paper) things down has been proven to be more effective at helping you remember than typing notes on your laptop. Maintaining eye contact is easier when you are not staring at your screen.

Write the speakers initials by what was said. When you review your notes, you will know who was most passionate about certain functionality.

It didn’t seem important at the time

You won’t always know what is important when you hear it. Later in the investigation, it might provide insight or clarity when trying to convey the stakeholders must haves to members of your development team.

It may seem impossible to capture everything that is said, but if you just jot down a few words it will help jog your memory.

The conversation was about a requirement assigned to someone else

This one is less obvious, and not many people do this. You should be taking notes during the entire meeting, not just when you are looking for answers.

Being part of a team means that you should be aware of what your teammates are working on. Taking notes while they are leading the discussion will not only help you retain this information but will be beneficial to them when you share notes with them afterwards.

Up your game

Being a good listener is one of the most important skills to a successful career as a Business Analyst. To be able to retrieve the information that you heard quickly and with accuracy is just as important. Writing down everything that has been said, even if you’ve heard it before, can give you a head start on your business problem and user story. It is more compelling when explained in the stakeholder’s words.

Consider ways you can improve your listening and note taking skills. Try it all your meetings, not just your requirements gathering. See what a difference it makes in your ability to recall vital facts and in your productivity. If you are looking to move from an individual contributor to a team lead or manager, this is an invaluable skill to hone. Demonstrating leadership skills is the first step to receiving additional responsibility and promotion.