It’s difficult to even think about being a business analyst without elicitation. Yet, it’s so core, it’s often difficult to abstract from the other BA tasks as well. It seems we are almost always eliciting something – the business need, the solution requirements, our stakeholder’s concerns, assumptions and constraints, detailed requirements, etc.
Some elicitation will, by the nature of what it takes to be a BA, happens without a lot of premeditation. The big chunks of elicitation where we discover the majority of our business or solution requirements will benefit from some careful preparation. And that’s what we are going to consider in this post.
Preparing for elicitation involves clarifying the scope of the selected elicitation technique, gathering any supporting materials, and scheduling all the people and resources.
Prepare for Elicitation – Step 1 – Clarify Elicitation Scope
Before we begin elicitation, we either consciously or intuitively decide what we want to achieve through the activity.
In the best of words, the scope of a phase or session of elicitation is formally captured in a meeting agenda and communicated to all involved stakeholders. You might even create a detailed elicitation plan that includes a stakeholder analysis – identifying who will be involved and what their role is.
At a minimum, you’ll mentally prepare for a conversation before popping your head into someone’s office. (This might sound a bit tongue-in-cheek, and it is! But I also know that perfectionism is a big deal in the business analysis space, and I don’t want you to discount what you do to prepare, even if it’s not incredibly formal.)
Prepare for Elicitation – Step 2 – Gather Supporting Materials
Gathering supporting materials is equally significant. This could involve research into what documentation or artifacts already exist. Or, it could involve completing another task to create a deliverable, such as using requirements analysis to analyze the “as is” process as a starting point for an elicitation discussion.
On one project where I was working remotely as a BA for a very geographically-dispersed organization a wiki was in place as a primary means of sharing information and documentation. In this organization, “supporting materials” often meant creating a skeleton wiki page containing any known information about the project along with links to other supporting documents such as as is processes or wireframes. Stakeholders were sent links to the materials in advance of the meeting.
Another element of your supporting materials will be your requirements questionnaires. A requirements questionnaire is essentially the list of questions you have about the requirements related to the scope of the session.
(By the way, we offer a Requirements Discovery Checklist Pack which includes over 700 categorized and cross-referenced questions to drill into the details behind common business processes and features. Essentially you’ll have everything you need to create your requirements questionnaires.)
Prepare for Elicitation – Step 3 – Schedule Resources
Finally, there is the need to actually schedule the meeting. In a complex stakeholder environment, this is often easier said than done. You might reschedule the meeting multiple times to find a time that works for all the participants. At times when a suitable time cannot be found, I’ve restructured the meeting so I can meet with different parts of the group separately and accommodate various schedules. Scheduling resources also involves nailing down meeting logistics: the conference room, conference call numbers, securing the projector, etc.
On my first BA project, we had two standing one hour meetings each week called “use case meetings” in which we performed a combination of elicitation and analysis. In this organization, getting a meeting on people’s calendars was a significant task. Having this regular time made scheduling (of both people and tangible resources – we had one projector for 4 BAs and it was often double-booked) easier and created a nice pace for the other aspects of the business analysis process.
Ignore Preparing for Elicitation At Your Own Risk
While at first blush, preparing for elicitation may seem insignificant, in my experience newer business analysts often underestimate the importance of this activity. Then they wonder why their elicitation sessions consistently go off track and they consistently miss deadlines.
When they learn to build in time to prepare for their elicitation sessions, their business analysis work starts flowing much more easily, and they gain significant credibility with their stakeholders as well.
Whether formal or informal, intuitive or structured, documented or undocumented, preparing for elicitation helps put your best foot forward as a BA and helps solidify stakeholder relationships by showing you value the time they spend with you while you are conducting elicitation.
>>Get Your Free Checklist
Looking to improve your elicitation? Discover exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.
Pingback: Identifying and Eliciting Information From Stakeholders – abdulbaqiblog
Preparing for an information gathering session does not mean that the session is so planned that it runs like clockwork. You prepare yourself, not the session. For example, rather than have a timed, prioritized agenda, the “agenda” is simply a paragraph explaining why the session is being held (to gather information about a particular part of the problem or solution), who will be participating, and what each participant’s role is.
I recall a meeting decades ago in a local civic group when the moderator had been beset by complaints about the length of the meetings: they never ended on time. The moderator decided to plan the meeting by assigning all the motions and seconds in advance as well as all the speakers and what they were speaking on. The meeting ran efficiently and ended fifteen minutes or so early which the moderator proudly pointed out. The meeting was well planned. There is a “last comments” section and one of the older participants who had complained about the length of the meeting spoke up. He said that the meeting did run quicker and things were done (motions passed, reports made, etc.) but as far as he was concerned he would have been satisfied simply reading the minutes of the meeting. There was no life in the meeting. He suggested that the moderator spend time preparing himself to manage the meeting to keep it within time and on track rather than managing the meeting to do so. I was not the moderator but learned a lesson from it.
Your account of having a general discussion instead of the planned meeting echoes the lesson learned.
The best rabbit out of the hat is to ask more questions – questions about the responses rather than prepared questions. Take the discussion off topic for a bit to get people relaxed and in the mode of answering questions. Remember that everyone is somewhat nervous about a situation in which they will be questioned. (“will I know the answers?” “What is she going to ask me?” “Will I be embarrassed by the questions or answers?” “Why does she want to know this?” and so forth) When you changed the meeting into a general discussion, people could relax more and the meeting went better.
Does this help?
Steve,
I like your statement “The best rabbit out of the hat is to ask more questions – questions about the responses rather than prepared questions”. I’ve managed pretty well reading out from a questionnaire in a scripted fashion but there have been times this approach has led to issues while eliciting requirements. Asking questions on the responses while the session is in progress is an art. I’m working really hard to learn this art and I hope I’m able to learn this approach in due course of time. I believe it is something that can be learnt from experience. Also, I think knowing the business process inside out can help a business analyst respond to questions while the session is in progress.
Sam, yes I think you’re right, it’s a practiced art, so I’m discovering. I think a degree of patience is required also. I think a degree of understanding their situation is a must (Steve, I think you’re aluding to this) and ensuring you are adding value. I will continue to learn!
Thank you all.
Sam and Tracey,
My favorite way to ask questions while the session is in progress is to just be silent for a moment. Often from the silence comes something – whether from me or the stakeholder. Another “trick” is to ask “is there anything I should be asking or we should be talking about?” Or, just to pause for a moment, look over my notes, and see where the gaps are, then pose a question to fill in the gap. You could look at it as an art, but I think patience with oneself as well as the confidence to allow for some awkward-feeling silence can go a long way.
There is a game you can play that helps you get better at asking questions. The goal in an information gathering session is to gather information and you gather information by asking questions so the idea is to say nothing that is not a question after the introductions are over. It can be done.
Here is the game. The original name of the game is Rosencrantz and Guldernstern. The game was introduced in the Tom Stoppard play “Rosencrantz and Guldernstern are Dead”. I’ve also heard it referred to as “tennis” or “verbal tennis”.
Rules are simple. Two players. One person starts by asking the other a question. The other must respond to the question with another question based on what was asked. Then the first responds with a question and so on. They have a conversation all in questions. If a player responds with anything but a question or takes too long to answer, the player is “buzzed out” and a new player takes his or her place. The winner is the one who stays longest without getting replaced. Good party game.
To win the game ask closed ended questions. People tend to answer the closed ended questions without thinking.
However, a better result is a more cooperative everyone wins. Consider the tennis match where the object is to keep the ball going across the net for the longest time rather than beat the opponent.
In this case the way to keep going is to focus on the last words or phrase the person makes and form a question around those words. You can do this in a meeting or interview as well, and it is easier since the responder is not asking you questions (or shouldn’t be asking). Ask the question even when you know the answer (as long as the question is not overly obvious). Asking the question has several positive results
1. you get information
2. The person whose last words you reference is flattered because you are clearly listening to what they are saying and appear to have an interest in their thoughts and answers – they will give you more information willingly
3. Others listening will also feel more encouraged to join in, especially if they know the answers. (remember the natural tendency of us all to mentally try to answer a question when asked of someone else – hence the continuing popularity of Jeopardy.)
4. The interchange and continuing answers get everyone involved and feeling good about their involvement
Try it.
Hi Laura (et all)
Loving this site! I’m a newbe BA and I’m getting so much from it. I wanted to ask the more expereinced guys, even with the planning and prep – how do you deal with a situation when stakeholders just don’t respond to your approach and the session goes cold.. Is it just expereince to pull another rabbit from the hat (so to speak). I found myself in this situation even though I spent a long time preping, the stakeholders felt uncomfortable and I just couldn’t get their understanding as to the value of the exercise. I actually stopped the session, sat down, and had a general discussion instead – which was more warmly received. Maybe I’ve just answered my own question! Thanks for sharing. T
Tracey, there may be some stakeholders who are apprehensive about speaking in a requirements session. One way to tackle this situation is to develop a questionnaire through Survey Monkey and forward it to the participants 3-5 days prior to the session. Survey Monkey does not reveal the names of respondents. You could also send the questionnaire in an MS word format to respondents via email and then tell them that you would be collecting the questionnaire from their place of work. Once you have all the responses in hand, you could then facilitate a general session or a session that is based on their responses. At least this way you have some high level requirements in hand before you go to a session which is general in nature.
If you are not sending in the questionnaire, atleast have a copy of the questions in your notepad, so in case you miss out on something, you could always look into your notepad. I’m sure you already do this.
But preparation is the key, have your agenda, questionnaire (if needed), questions in your notepad, rehearse a bit, give the stakeholders a heads up on what is in store for them at the session and try to maintain the scope of your discussion.
Thank you Sam, I’ll add Survey Monkey into my’ Rabbit’s Hat’!
Pingback: BA Stories: Are You Responsible for the Solution? (BABOK 7.1)
I can’t find this: “Tony Heaps” functional specification document template
Poor google and even the bridging the gap search engines failed. Ok, I give, where is it?
Here it is…
https://www.bridging-the-gap.com/an-agile-functional-specification/
Hi Resty
I follow the same process for in house and external. The only difference I have found is sometimes in the contract – the external vendor wants to gather the requirements. We have been pushing back hard on that one – they know a lot but they do not know our business. This can lead to matching the requirements to the system rather than building the system on the requirements.
i have been learning a lot about BA on site.. thanks Laura and the rest of the contributors. just wanted to know if there is something different with the way you elicit requirements for in house develop systems and contracted one, other than the contract
I recently facilitated a few requirement sessions with our client in a project that included an enhancement to a particular application. The enhancements were in the form of reporting metrics that the clients were looking at to better their reporting capabilities. I was called in to the project mid-way as a requirement analyst. As it is with most projects, we usually have a week or two to get ourselves acquainted with the project and that goes a long way in making us confident in facilitating sessions. However, this time around, I was asked to facilitate a session just 4 days into the project. As Laura mentioned, there is more to these sessions than just facilitation.
I was a little apprehensive initially but got over it by being confident in my preparation. There were few mockups that were forwarded to me and I started drafting a questionnaire on the basis of those mockups. Each question that was drafted was carefully being researched (research included reading articles pertaining to business intelligence, about the application etc). Additionally, I downloaded a free mock up software and started to draft alternative versions of the mock ups that were forwarded to me. Moreover, I drafted an agenda from a template that I already had from my previous project. Finally, I started to rehearse with vigor for at least 5-6 times to gain confidence in the way I speak. So basically, the actual elicitation session was like the 7th rehearsal and it went really well. I received compliments from my project manager and was asked to facilitate another session.
Therefore, I believe there is no short cut to do well in an elicitation session but to prepare really well. For 4 days, all I did was research, draft (questionnaire, mockups, agenda,) prepare and rehearse. I forwarded the agenda (included dial in conference codes, purpose, meeting participants, location, time, duration, scribe etc) and questionnaire (25 questions which also included mockups) to the meeting participants (10 onsite -7 remote) 24 hrs prior to the session, got a few extra copies to the session itself in case someone forgets, got to the session 30 min’s before the meeting, projected the agenda on the screen and subsequently projected the questionnaire with the mockup and started the session. One question lead to another and the fun began. The idea of course then is to get the session back in scope of the meeting. Finally, I liked eliciting the session by projecting the questionnaires on the screen because it saved us time and helped us to concentrate on writing the requirements than to actually think of what question to ask next and writing at the same time.
Sam, What a wonderful and detailed story. This indeed is an example of preparing for elicitation in the extreme and it sounds like you used it to meet a big challenge. Congratulations! I bet this has helped propel your career a bit forward as well as you already mention that the PM asked you to facilitate a similar session.
Thanks for taking the spirit of this series to heart and sharing the details of a specific project and experience. I look forward to reading your future contributions to this series as well!
Thank you Laura, I surely will contribute more to this phenomenal blog and yes these sessions will definitely propel my career in the right direction. I must say that I’ve not come across a blog where we have so many senior analysts contributing articles on real world projects. I actually was more of a reader than a contributor but then was compelled to contribute when I read the elicitation article because it related well to what I’m currently doing in my project. I also happened to adopt “Tony Heaps” functional specification document template in my current project and it worked wonders in terms of documenting requirements in an Agile environment.
Wonderful!! We are very lucky to have so many great contributors. I only worry that those not considering themselves senior will not feel their contributions are worthwhile. In reality, we all have something to learn from each other so thanks again for sharing your experience and going from reader to commenter! I’m sure Tony would love to hear about your experience with his template too!
Thanks for the detailed account Sam. I am actually glad to see that someone spent 4 days preparing for a workshop type session like this because that’s what I’ll be doing on my current project and that’s what I feel I’ll need.
I also use the as-is model or verify it, or even build it during the session.
Hi Laura, this is in prep for project requirements.
An information gathering plan (the key to efficient and effective elicitation) consists of four elements:
1. Determine what information you need (to define the problem or problem domain, to produce the solution, to perform an effective negotiation, to make or facilitate the making of a decision, and so forth)
2. Determine where that information is (looking first to hard copy as it will likely be more factual and less subjective assuming such hard copy exists and is current, then pursue people)
3. Decide what method of information gathering will be used to acquire the information (interview, meeting, observation, reading, survey, and so forth, using the guideline that information located in Hawaii, Paris or similar locations require an on-site observation and face to face interview, while information located in Butte Montana in January can be handled over the phone or by email.)
4. Determine the sequence of acquisition of the information (this is not the schedule of appointments. It is the order in which you will acquire the information noting that you need some information before you can understand other information Generally the order follows from the general to the specific.)
Brainstorm the questions you need answered and the topics you need information about; assign at least one source to each topic or question; determine how the information will be acquired from that list and finally, determine the sequence. Planning done (15 minutes) and you are ready to elicit a whole lot of information.
Thanks Steve. I like the bulleted list summary! Although I think that will take me more than 15 minutes to execute.
I prepare with an interview with keysme to understand the problem,pinpoints this project is trying to solve and learn more about the existing system. With this knowledge I then create an agenda and list of discussion points that I sendout to the groups for a meeting. I also try to have an asis and tobe process diagram to help lead the conversation. I am hv noticing i am not having enough time to put this all together or i am just really slow 🙂
Also i notice that more questions come to mind after the meeting. I try not to beat myself up for not have thought of the question sooner
Hi Kai, Thanks for sharing your experience. Elicitation is an iterative process – it will happen many times throughout the project not just once, so it stands that we’ll also prepare for elicitation again and again throughout the project. I wouldn’t beat yourself up for not thinking of the questions sooner. With more information comes more questions. Do you others agree?
I like to prepare an agenda before a meeting as well. I also think performing stakeholder identification or analysis is key in preparing for elicitation.
I will also “read up” on the business area’s purpose, goals or objectives as a way of preparing for elicitation. I will read information in the organizations annual report as well as reviewing any reports or stats from the business area related to it’s major outputs.
Katie, Thanks for sharing about reports and stats related to the business area. In what contexts have you found that to be especially helpful?
I think another big part of the preparation in the complex stakeholder environment, especially when you are new to the company – stakeholder list validation. We need to make sure that we address the right group of people – and not only functionally, but also culturally. I found with my recent project that having “politically correct” stakeholders in my group as well as “hands on” ones was vital to buying stakholders “in”.
Zoya, I totally agree and so does the BABOK. The BABOK actually has a whole separate task for Stakeholder Analysis so there will be an independent post on that later on! In the world of the BABOK, a stakeholder list is an input to preparing for elicitation.
I usually do research on the project (project charter, business justification) and if it is software – then the possible software company. Then I start writing down all my questions – including why are we doing this, why do we need this, how many people does this affect, what is the cost, what is the benefit?
Hi Michelle,
It sounds like this is the preparation you do in the context of eliciting the business case or business requirements? Does that sound correct? Is your preparation different when eliciting the details of the project requirements?
Like Ajay, I always have an agenda, and I include it in the meeting request so that the stakeholders can be prepared for the meeting. I will either provide copies of the agenda at the meeting, or I display it for all attendees (to help keep all of us on track). I will often prepare an as-is model also. In preparation for elicitation, I will also sometimes bring an interesting conversation piece to get the buzz in the room going…and that gets the stakeholders prepared to be in a good mood to answer all of my questions. 🙂
Interesting Karen. Do you have an example of an interesting conversation piece and how that helped get stakeholders in a good mood? I’m trying to wrap my head around it!
Sure. I once brought a photo of myself as a child, and my pet raccoon. It got a few laughs becuase of the clothes I was wearing, and everyone relaxed a little so that I could begin elicitation. On another occasion, I brought some football stats and placed them on the board. Since most everyone in the room loved football, I was able to get the room hyped up for the season AND the meeting.
I overlooked this comment, Karen. This is really interesting. I often am so wrapped up in keeping us on track I’ve never even thought of creating a meaningful diversion. I have a new tool to add to my tool box!
Also, Karen, was just wondering for our readers, since context is so important in how we do things as BAs. In what situations do you present an as is model? Is there a specific project story you could share where this was provided as a way of preparing for elicitation? I know sometimes I do this but sometimes I do not.
I generally prepare as-is models when I know, or sense, that a current process is going to change, or, when the meeting attendees may not have complete knowledge of a business process. One example I have is from an elicitation meeting with a sales team to determine how we might implement electronic signature functionality into their current process. I created the current state of the sales process, and then we were able to quickly identify what would change by adding in the e-signature piece. The meeting was much more productive by creating the model ahead of time.
Thanks for sharing the example Karen. Sounds like a great example of when an as is model was a very useful supporting document and helped shorten the elicitation process. And I like your criteria too for when one is necessary!
Preparation is key. I always add an agenda because it gets me prepared on what topics we are going to discuss on and gets the stakeholders prepared also on what they wish to contribute. In addition to the agenda, if they are supporting materials, I bring them on my own to distribute in the meeting.
Whenever I go into a meeting without Agenda not much is accomplished and I feel not only did I waste my time but the stakeholders time.
Thanks
Ajay
Thanks, Ajay. What a great point that a meeting agenda is a great way to pull all these aspects together nicely. I often do the same, but didn’t quite think about it this way when pulling together this post. Thanks for sharing. I’m sure others will benefit from reading your experience as well.