The initial meetings with a stakeholder can be nerve-wracking. Oftentimes projects come to us for “analysis” with very little detail. It can feel like everyone else knows more and is better prepared. Yet we, the business analyst, own the next step. Especially as new business analysts or business analysts in new organizations who have not yet learned the business, a bit of fear and uncertainty can creep into these early days on a project.
As I’m reading about in The Introverted Leader, you can support your confidence in uncomfortable situations through preparation, presence, push, and practice.
Preparing to elicit requirements
To prepare for an elicitation session, conduct as much research as you can to inform yourself about the problem and the existing situation.
- Talk to the sympathetic people first. This might be the person that hired you or your designated go-to person in the department.
- Learn the business and explore the system. Obtain as much insight as you can into how the business operates and the system works using the available information and tools.
- Start a list of key terms. If a glossary exists, use it as a reference to find the definitions of terms. Often you will find additional or alternate terms that are not included in even the most up-to-date glossary. Keeping terms straight can help you carve a more efficient path to real understanding.
- Start a list of questions about the system, about the process, the people, and about the project at hand. Think why, what, how, when, who. Keep this question list handy as you meet with people about the project and use it to guide your discussions.
- If system documentation is non-existent, create models as you learn about the business and the system.
Be present in your elicitation sessions
Presence relates to how you handle yourself with others. If you are prepared, you should be confident and 100% present in your initial discussions. To create presence in an elicitation session:
- Use your list of questions and agenda items as a guide, but go with the flow. Once your stakeholders start talking, let them speak through their thoughts. While later in the process you make need to practice guiding conversations and even interrupting, your initial meetings should follow the energy of the stakeholders.
- Focus on seeking to understand stakeholder perspectives. Avoid second-guessing the questions you have or what you do or do not know. Keep it top of mind that this is your opportunity to learn more about the project and the stakeholders’ opportunity to unfold their perspective.
- Be an active listener — summarize what you hear and ask intelligent follow-up questions. But don’t be so worried about your next question that you forget to listen!
- Be OK with momentary pauses. Collect your thoughts, review your questions, and continue the conversation.
Push yourself to become better at elicitation
Push refers to getting yourself outside of your comfort zone by taking on new tasks. Through push you advance your capabilities and your leadership. Some ways to push during elicitation include:
- Find gaps in your understanding and find ways to fill them. This might require involving an additional stakeholder or asking for a demo or observation.
- Seeking out the perspectives of higher level stakeholders. Drop by an executive’s office or take advantage of a chance meeting in the hallway and ask for what they value the most in the project.
- Use a new technique as part of elicitation. Learn a new way of modeling or a new tool and incorporate that into your elicitation activities.
Practice eliciting requirements
Practice is about repeating behaviors, even if they feel uncomfortable at first, until they become part of who you are. As an analyst you want to grow into a professional who loses that initial feeling of fear — the unknown becomes a sought after challenge.
Some ways to practice elicitation include:
- Practice asking your questions and listening to the answers with a friend or trusted colleague.
- Anticipate the types of feedback you might receive and practice responses.
- Keep the momentum going by scheduling elicitation sessions. After every meeting, define the next step and make it happen.
- Keep yourself informed about new skills. Read books about elicitation, especially Ellen Gottesdiener’s Requirements by Collaboration, and incorporate these practices into your elicitation activities.
With consistent practice, you will be able to spend less time preparing and more time being present in your elicitation activities. As your confidence grows, you will be able to handle more ambiguity in the initial phases and more dissonance among your stakeholders– i.e. more challenging projects.
Your reward: confidence!
By preparing, being present, pushing yourself, and practicing, that uncomfortable feeling will be replaced with excitement and confidence. As has been reinforced for me by Jennifer Kahnweiler’s The Introverted Leader: Building Your Quiet Strength, becoming a better leader is about continuing to invest in your own personal and professional development, increasing self-awareness, building on your strengths, and choosing new challenges.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 13 comments… read them below or add one }
Laura
This is a really important article that you wrote. I’ve many times taken it for granted that I can speak in front of people without too much trouble. In helping to mentor other analysts, it becomes apparent that not only should I do not do that, but see how critical it is early in a project. Your suggestions to get there are right on the mark and will build the confidence you mentioned. This is critical, as the in ability to engage a stakeholder quickly and thoroughly could result in missed requirements.
Thanks!
You make some very good points, Laura. From my own perspective, I’ll add a couple more:
- Brush up your note-taking skills. After the meeting, write up or expand your notes with as much detail as you can.
- Try to have a phone chat with your stakeholder a couple of days before the meeting. Introduce yourself and ask some open-ended questions to get the “lay of land”. That will enable you to ask more focused questions at the meeting.
- Try to keep info elicitation meetings one-on-one or one-on-two. Big stakeholder meetings are best kept for kick-off meetings or for approval late in the project.
Thanks, Chris. I think these are great tips. I myself learn so much about elicitation through note-taking and the after-meeting expansion you mention. While I’m documenting the discussion and what happened, it’s also fresh in my mind how I handled the discussion. This can be a good time to reflect on what I could have done better or how I’d like to handle a similar aspect of the discussion next time.
As far as big stakeholder meetings, I think there is a time and place for them, though they should not be over-used. Running a big meeting to elicit requirements takes strongfacilitation skills, planning, and coordination of multiple roles. As I’m learning in Requirements by Collaboration, is best focus on team’s creating actual requirements models, not just discussion about the requirements. I’d consider this a very advanced form of elicitation.
Laura
Thanks, Laura. Let me stress I find a pre-meeting phone chat to be really, really useful. Just ask them for 5 or 10 minutes, and don’t go longer than that unless the conversation is rolling and you ask their permission to continue.
Hi Chris,
I definitely agree and apologize for not responding to your entire comment. I share some similar thoughts in this past post: http://www.bridging-the-gap.com/set-the-stage-for-more-effective-meetings-by-establishing-context/
Laura
what differences might there be in preparation and execution of the elicitation if all of the responders are in different locations and the elicitation process has to be done with a phone meeting?
Steve:
I’d still like to see what Laura has to say on this, but since I deal with this regularly, I thought I’d respond as well. When preparing for elicitation remotely with distributed audiences, the first thing I do is evaluate the current relationship that I have with the majority of the audience to determine the general level of involvement, participation, etc. from those that I will be speaking with. Then, I identify what my lowest level, or least favorable constituent will be. It is this person that I will take pains to speak to, as if I can get feedback from someone that doesn’t really understand/care/want to be there/etc., the rest will fall into place.
I focus my attention then on techniques that do not require physical interaction or have a heavy need for me to see facial expression and body language, which I typically rely heavily on. Due to the absence of this input, I must prepare in other ways in order to enhance my own confidence in asking questions and being able to have an intelligent discussion. Techniques that I have found suitable include preliminary surveys and questionnaires, general requirements workshops, online prototyping, online flow diagramming, use case development and solid general conversation. I don’t find role playing, brainstorming and other creative types of techniques to be useful in these remote scenarios.
As mentioned above, I typically enhance my preparation of the material to better prepare than I might otherwise, because my audience will not be able to read me and vice versa during periods of silence, conversation, and while I do other techniques with them.
Doug
Thanks for the question Steve and great comments Doug. I’d add that from a “preparation” perspective you’ll also want to focus on logistics. Oftentimes I see logistics get in the way of productive meetings when the participants are remote. Think about call-in numbers, downloading software for sharing applications, making sure everyone has appropriate connectivity, etc. The goal here is to not let technical issues get in the way of a productive meeting and for a virtual meeting it’s worth dedicating a bit of extra time here.
In terms of practice, it might be worth on reading up on some new techniques for managing conference calls. I’ve published a few ideas here: http://www.bridging-the-gap.com/bag-of-tricks-7-effectively-managing-multiple-participants-in-a-conference-call/ But a web search will probably reveal a bunch of other ideas. Like Doug mentioned, many of the techniques you typically rely on may not work. It’s important to replace these techniques with new ones.
Laura
In the process of requirement elicitation,
I find it difficult to explain the process of system/busiess gaps to the stakeholders. Most of the end user work is manual, however, its not easy to present and document this in the best way possible for the higher mgmt.
Any help in this regard would be really appreciated
Hi Faras,
Great question. It sounds like you are taking the time to really understand the business process, whether it is manual or system based. This is the best first step. It doesn’t matter what “systems” are used, just getting an understanding of the process is key.
I’ve found that higher level managers don’t really care about the details. They care about metrics that impact the bottom line. So a statement like “there are 5 sequential steps that can take X amount of time and is very error prone” might get their attention. At this level, it’s about characterizing your detailed understanding of the problem in terms that management will pay attention to
Thanks Laura..i got it now..
Actually i am in a corporate hospital and as its a service industry..with a lot of appplications running..its difficult for me to capture the big picture of the whole processes, like some work is in ERP, but while some is left out..although it ought to be in ERP.
But yes I will be more focusing on the business process and constraints while elucidating it to mgmt..
Appreciate your time..
Faras
Hi Faras,
I think I understand you situation better now. Sometimes I find it helpful to step outside the systems and procedural steps and model the process at a higher level–really focusing on what we’re trying to achieve through the processes and ignoring the system component for awhile. The level of detail in the model is going to depend on what problem you are trying to cast light on and you can have different models for the same processes to provide different insights.
Laura
Can you elaborate on the level of detail in the models? That is, can you provide a greater level of detail in your explanation?