Imagine you are running a meeting, probably about software requirements for a project, and someone in the room gets squirmy.
- Maybe they are shuffling their papers.
- Maybe they are bored and checking their emails.
- Or maybe they are restless and start finishing your sentences and communicating with that leaned-forward head nod that says “yes, yes, yes” let’s move along now.
I often feel I must bore my unlucky meeting attendees by poring through detail after detail of requirements documentation, issues, and questions, the typical process of a requirements review. Even if it doesn’t seem to be all that enjoyable, what else am I to do?
This is a tough question, because in all reality, a key business analyst skill is to find the details others miss. It is possible, however, to achieve our quest to document the right details without communicating from the details. This is an important distinction. The result of our analysis and the matter of our discussions can be at two different levels.
Let’s look at an example.
What if you set aside mindless walk-throughs for meaningful requirements sign-off? This applies to use case reviews, wireframe reviews, or any meeting where your purpose is to validate that a specific deliverable communicates exactly what is intended. It’s easy to focus on the details, details, details.
Instead, turn a walk-through into a discussion with a purpose. Not all details are created equal.
- Some details you know for sure you’ve got right.
- Some can be inferred from one another.
- Some need to be asked.
Create a discussion with a purpose by setting a clear goal (often part of your meeting agenda) Â that defines what you want to learn–share this goal with your participants. You might also have an internal goal for yourself about what you’d like to document and what requirements you need to validate, but most participants do not need to be explicitly aware of that goal.
Secondly, gauge what details your participants care about.
- Do they care about the minuscule details of the user interface, the emails that are sent, the flow of the site, or what they need to build?
- How do they perceive this value in the context of this project?
Just as importantly, what value can they add that no one else can? - How can you leverage this insight to maximize the value of their input?
By considering the unique perspective of the stakeholder, you can set goals that they can and want to help you accomplish.
Finally, gauge how your participants want to learn and communicate.
- Do they like to read documentation and ask questions?
- Do they want you to verbalize the key requirements to set a context and then answer your questions?
- Do they need time to prepare or will they never prepare no matter how much lead time you give them?
- Do they need to see pictures?
- Do they need handouts?
- Will you get their best ideas by getting them to draw on a white board?
You might try out various approaches until you find the right mix that works with your stakeholders. You know you are close if you are getting the feedback you need to move the project forward.
It’s important to remember that stakeholders will come at your project from different levels of detail. By imposing your detail-orientation on them, you make them work harder to provide you the right input and risk the possibility they might never give you the necessary details. You might be their forest or you might be lost in the trees. Considering things from their point of view and meeting them as close to their level as you possibly can get will help you elicit the right requirements efficiently.