Complete guide on Requirement Elicitation (incl. techniques)

1. Welcome to the course: Hi, and welcome to the course Business Analyst, the compact requirements elicitation guide. My name is T Bodhi book and I'll be your instructor throughout the remainder of the course. Now, before you commit to the course, you might want to know what my credentials are, which is totally understandable. I am a manager in one of the largest consulting firms in the world and I'm currently active as a consultant in business analysis. My expertise in business analysis and more specifically, requirements elicitation comes from many high profile projects in the financial sector. In terms of Academical record, I hold two master's degrees, one in financial economics and another one in general business management. On top of that, I also holds many certifications related to business analysis, project management, agile, and analytics. You might want to know what's in it for you. Well, you won't be disappointed. After the completion of this course. You will be able to confidently use the four-step requirements elicitation approach to drive the recitation activities. This in just under two hours. In those two hours I will cover every step of the elicitation journey in greater detail. Starting off with the first step, planning your elicitation activities thanks to a robust strategy, followed by the second step, conducting your citation through a series of battle tested techniques such as interviewing, brainstorming, prototyping, and much more than in the third step, we will go over how you can confirm your understanding during and after elicitation sessions. And we will then conclude with the last step where you will acquire the rights or skills to communicate elicitation results to your stakeholders in a format that is adapted to their needs. On top of that, the content of the course, you will also be able to test out your newly acquired skills with a fun project. And as a bonus, you will have access to the handouts and all sorts of useful templates to facilitate your day to day elicitation activities. And last but not least, you will also have access to my expertise in case you have questions related to the course. Now, who is this course for? Are you a recent graduates looking to start a position as a business analyst, business consultant, product manager, product owner, or even UX designer, then don't go anywhere because this course is definitely for it. The same goes for existing Junior business analysts who are looking to strengthen their knowledge. The course is also for senior business analysts who are looking to brush up their skills. And finally, the course can be useful to anybody who is actively doing requirements elicitation in their field of expertise, and who are looking for ways to formalize their way of working. But that's enough from me. Now it's your turn to act. If you feel that this course is something for you, then hop on board. And if not, maybe next time. In any case, I wish you a wonderful and educational day and hope to see you soon. Bye. 2. The need for requirement elicitation: Hi, and welcome to the course on requirements elicitation, solving the right problem. This is quite a title, but what does it exactly covered? I will first explain why we need elicitation and what it is. Let me start off with a quote from a fairly renowned professor that goes by the name of Albert Einstein. What he said was, if I had an hour to solve a problem, that's been 55 minutes to think about the problem, and five minutes to figure out how I will solve it. What Einstein industries that he highlights the relative importance of solving the right problem compared to solving the problem in the right way. Solving the right problem means that you have to do a lot of research and reflection around your problem. This brings us to the requirements elicitation part. Requirements elicitation is about obtaining information and needs from various stakeholders, including customers, and confirming whether you understood the problem correctly. You have to understand that requirements elicitation is a mandatory step when you want to solve a specific business problem or any problem really, the field of requirements elicitation can be really broad and covers many elicitation techniques such as interviewing, user testing, experimenting workshops, brainstorming, focus groups, etc, etc. Gustation is also something you should keep doing on a continuous basis. It only stops when all the needs have been uncovered. And the problem is well understood. When I do requirements elicitation together with my clients, I always apply a four-step approach. This ensures that the quality of my work remains consistent. If there is one thing that stakeholders don't like, it is bad surprises. Having a structured approach will already benefit you in a lot of ways. What is this four-step approach? So first step is planning for your elicitation. Here you make sure that the stakeholders have the information that you need before actually doing in elicitation session with them. We will also give them a heads up to what you plan to do during elicitation. Step to conducting your elicitation. Here you go on the field to understand your stakeholder needs and identify potential solutions that may meet those needs. This may involve direct interactions with stakeholders, doing research or running experiments. Step tree, confirming your understanding. Here, you can make sure that you actually understood what was said during the elicitation. This step will help you avoid ninety-nine percent of community miscommunications. I should not be skipped step for the last step, communicating your elicitation results. You share the results of your research with the people that are involved as a way to be transparent about, to be searched, and also to receive their feedback. In the remainder of the course, I will cover every step in great detail in order to provide you as many best practices as possible. At the end of this course, you can expect to become a real detective. I hope to see you in the next session where we will cover the first step which is planning the recitation. Hope to see you there. Bye. 3. Planning - introduction: Hi and welcome back. In this section we will cover the first step of requirements elicitation, which is planning your elicitation. First of all, what is burning for elicitation and why do we need it? Looking for needs and turning them into actual requirements is quite a task. You want to do that task as efficiently and exhaustively as possible. Hence, while you need to have a plan, planning your recitation activities will ensure that you, all your stakeholders don't lose their time. That you reduce the risk of missing any major requirements. You elicit information from the right stakeholders. You're able to factor in stakeholders attitudes towards your project. And you're also able to account for certain political factors. 4. Planning - defining the scope: What are now the building blocks of that plan? The first building block is the scope of your elicitation. Here you will define what information you are looking for four, and from whom you will need to get that information. The second building block it has to do with the elicitation technique. In here you will determine the appropriate method of how you will get the information. The final building block is to sort out the practicalities of your elicitation. You want to make sure that everything goes smoothly. I will now go over every building block in more detail. The first building block, the scope of elicitation. When determining the scope of the elicitation activity, you should try to list the objectives of that particular activity. This exercise can be done by asking yourself this simple question, what do I want to know at the end of the elicitation session so that I can consider it to be a success. When determined, determining the scope of fish, you should keep the following in mind. First, the excitation objectives or deliverables, clearly define what information you are looking to discover it. Don't hesitate to be really practical and formalizing your need. It can be something as simple as knowing the key steps of a QR payment process. How will this bring you closer to what you need to deliver? Something else you have to consider are any if there is a need for any elicitation prerequisites, identify what material should be collected and analyzed and delivered before the elicitation activity starts. The popular phrase of garbage in equals garbage out is quite applicable in some elicitation techniques. To give an example, in the many brainstorming sessions that I attended, I could easily distinguish between goods and bads. Brainstorming session purely based on the preparation that was done prior to the brainstorming session. Further, you also need to consider your own capability as an illicit or how comfortable are you in running in elicitation activity? Are you sufficiently knowledgeable to run elicitation session? Do you know enough about business domain? Your questions sufficiently clear or are they misleading? Has certain questions already been answered through another mean, such as meal, meeting minutes, report, or presentation. Try to not go back to your stakeholders with similar questions that have already been answered in the past. Next, you should also consider the stakeholder. Make sure that the stakeholders have the right information. You could send out an email, for instance, in advance and mentioned what's the content of your elicitation session is going to be about that way the stakeholder know what is expected of him or her. Tried to locate a stakeholder within the organization. In other words, try to find out what their rank rule and who they work for. This can often be found on the company's intranet. I remember when I started, I didn't always do this and I ended up in a meeting with an important executive. These kind of situations are tricky because you have to be very well-prepared. And because these people have a lot of influence and could actually derail your project if you're not careful. What you should also check is the attitude of the stakeholder towards your project. Because sometimes it could be that you're solving a need and that they don't want to be, they don't want it to be solved. I remembered that in one of my projects, I was looking to automate a process which was on manually at a time in order to better understand the process. I was having an interview with one of the employees. It was executing that process. Of course, that person was very wary of me and quiet against projects and neither tried to solve. And so as a result, they were not very collaborative. This creates four awkward situations that can be avoided. If I had done a bit more research. For instance, I would've taken a more change management type of approach and take their emotions into considerations. Another one you could check is the level of maturity of the stakeholder. Ask yourself whether you should educate a stakeholder first before going into an elicitation session with them. I once had an order stakeholder in a design thinking session. And notice that that person was quite counterproductive as he was breaking down other people's IDs. Now you have to know what it's okay to break down IDs in a design thinking session. However, not in the expansion part where the goal is to generate as many ideas as possible. But I decided to do was to split the designs thinking session into two separate sessions. And in-between those sessions took some time to educate that older stakeholder on how a design thinking session works. I was explaining him that the feedback that he was giving was quite valuable, but attempt to soon in the process. This was a good move as the stakeholder was now very productive during the sessions. Finally, you need to consider the culture of the company. Thus, the company loved to do meetings or do they prefer to communicate via meals? In companies with many political influence since they tend to prefer meetings. The reason for this is that the stakeholder wants to measure you and your motifs in greater detail. It's harder to get a good sense of somebody through a simple e-mail. 5. Planning - techniques & practicalities: Moving on now to the second building block, the elicitation techniques. In this part of the plan, you need to think of how you will get the information. What techniques will you use to get the right type of information? Choosing the right technique will depend on the scope of elicitation. Some techniques form a better match for certain types of information. Another one to think about is the cost of the elicitation. If you need to interview many stakeholders, the cost also goes up. This is often an important constraint when your stakeholders are executives, for instance. Another one to take into account our timing constraints. Often in consultancy projects, you have to work with limited amounts of time, either between, often between tree weeks and six months. As mentioned before, the company culture is also an important factor. The availability of your stakeholders is also something to think about. It's quite hard to pull off a meeting, brainstorming meeting with somebody who is at the other side of the country. You should also consider your own expertise as a facilitator. If you never did the job shadowing interview, perhaps you should try another technique first. In the next section, I will cover different elicitation techniques in greater detail, such as their pros and cons, their best practices and how to execute it. It will also provide you with a small overview of which techniques to use in what type of situation. Moving on now to the third building block, the elicitation practicalities. Prior to the elicitation activity, you should make sure that the practical side is covered. What works for me is to think of all the things that could go wrong. The first set of problems have to do with technical problems. The laptop doesn't start at battery's dead, or you have to make sure that you have a backup for that. Or for instance, mine, my password has expired. The sound quality is quite poor, so in that case it's important. It could be helpful to wear headsets as it really improves the quality of your meetings. Another one I can think of this PowerPoint that doesn't open or you have connection problems to connect to the network. There is an echo in your core here. Your best move is to ask everybody to put themselves on mute if they're not speaking. Another set of problems can be linked to the location of the elicitation session. For instance, if you're organizing a physical meeting and it turns out that the room is not available. Tried to make sure that you reserve too room beforehand. Or it turns out that the room is not big enough or there is no whiteboard, new screen or Beamer to share the presentation on orders new audio device, if to facilitate when people are joining remotely. And the last string of problems that I can think of are grouped under the organization. Topic. For instance, a stakeholder or can't make kids, or they are joining late. Here it's important to ask yourself if you want to reschedule the meeting or put some topics higher up on the agenda. Stakeholders have no time to review the documents in advance or the material to send them. Here, it's good to plan a little reminder in your head to get everybody back on back on track. Another one I can think of is that there's not enough time that has been foreseen during the meeting. Here, try to organize a second session immediately during the first session so that you don't have to ask people to move their agenda. And it also often happens that people get off track. Here. A subtle trick is to ask everybody is to, is to mention all the other topics that are on the agenda and the time that's left to tackle those topics. These are a couple of the things that I could think about that might go wrong. It's of course not possible to avoid all these problems, but being prepared for them and knowing that they exist is already a very good start. At the end of this step, you should have a document describing your elicitation objectives. Any prior information that's handy to have prior to the session and recitation session. An assessment of the solicitor, That's yourself, an assessment of your stakeholder that you are going to interview or having a recitation session with an assessment of the company culture, the elicitation technique or techniques that you will use, and any practical preparation that you deemed to be necessary prior to the session. This concludes the planning. In the next session we will discuss the second step which is conducting your elicitation. I look forward to seeing you there. Bye. 6. Conducting - introduction: Hi and welcome back. In this section we'll discuss the second step of requirements elicitation, which is conducting your elicitation. The natural step after planning your presentation is to go out on the field and to actually conduct deal citation. You want to find the answers to the questions that you listed and defined during the recitation plant. There are many techniques that help us to elicit information in a standardized format, and I will cover the most important and effective ones in this section. Before we dive into the different techniques, the first one to draw out a framework that structure as the techniques into three main categories which are collaborative techniques, research techniques, and experimental techniques. Within the collaboration. Elicitation techniques, you will elicit information by interacting with stakeholders or their work and use their knowledge as input for your requirements. In other words, the information you are looking for is already available, but you have to collect it, structure it, and format it in such a way that the answers to questions that you had within the researcher elicitation technique, you will elicit information by going through raw sets of data. The data exists and has been captured, but it is not processed into a usable information. This type of research often involves the analysis of historical data to statistical inference. Within the experimental hesitation techniques, you will elicit information by setting up a controlled experiment to collect information to data or information doesn't exist yet. And it has to be captured by constructing an environment where certain parameters are controlled and others are very good. Examples are proof of concepts and user attach user tests which are often used in an IT context, intestine, concepts and products. When eliciting information, you will most probably use a combination of different techniques that are drawn from these three categories. I've added a small overview in the resource section where you can see when to use which technique. That's it for the introduction of this section. In the next sections we will cover the techniques to characteristics, the pros or cons, their way of how to execute them and what their best practices are. See you there. Bye. 7. Conducting - interview: Hi, and welcome back. In this lesson, we will cover the first collaborative elicitation technique called interviewing. Let's first look at the definition of an interview. An interview is a conversation between an interviewer and interviewee where information is obtained, the interviewer will ask a series of questions and interviewee will provide answers to those questions. Since quite straightforward. But interviews are what makes the world go round for consultants and business analyst, you could say that conducting interviews became like a second nature for them. As it is such a powerful tool. Let's go over some of the characteristics that we can distill from this definition. It involves two parties, the interviewer and interviewee. Note that multiple settings are possible here. It's possible that you have one interviewer and multiple interviewees. It's possible that you have multiple interviewees and one interviewer. It's possible that you have multiple interviewers and interviewees and simply want interviewer and wanting to Huey. Another characteristic is the fact that an interview is a conversation, meaning that both parties are allowed to exchange words. Next, the goal of an interview is to obtain information. In our case, it is to elicit requirements and find answers to the questions that were listed in the elicitation preparation phase. Characteristic that is not included in the definition is whether interviews are structured or not. There are three types of interviews structures. The first one being you have interviews that are not structured. The interviewer just has an ID of the main problem that he or she wants to solve, but no further preparation was done in terms of questions or sub-questions. Let's meet at the interviewee has all the freedom to go beyond the scope of interview questions. Another type of interview is a semi-structured one. The interviewer has prepared in main problem statement and a couple of sub-questions. This allows the interview to provide additional information beyond the scope of the interview questions, but they can't completely go off track. The last type of interview consists of structured interviews. The interviewer has prepared a main problem and a strict set of sub-questions. Note that the interviewee is not allowed to go beyond the scope of the interview questions. My personal favorite is the semi-structured interview, because it gives you the best of both worlds. You can. You're certain that you will receive an answer to your questions and you are less likely to omit information that the user might have wanted to provide. It's also less time consuming compared to a structured interview. In terms of preparation. When would I use an interview? I would opt for an interview if I'm trying to further my understanding on a specific topic and the knowledge has already been captured by experts. How can you best execute an interview? I hear you ask, I will walk you through the generic steps that an interview shoot half. Let's assume that I want to organize a one-hour interview which happens remotely. This setting happens quite frequently nowadays. First, there is a preparation phase of ten minutes before the interview where I do the following. I ensured that I rehearsed my elicitation plan and the context of the interview, I check whether the person has accepted the invitation or not. If not, I send them a message to all squared, I should reschedule the meeting. Or if it just goes true next time, make to make sure to be in the coal on time. If I'm late, I let the person know in advance so that they are not waiting into coal for nothing. Next, there is an introduction phase of five minutes where I do the following. I introduced myself, my rule and what the goals of the interview. Then I'll let the other person introduced themselves. Also often do some small talk to create a friendly environment. Doing this helps me to build trust with the interview and it enables Richard interviews as the person who is more at ease. After the introduction phase, the content phase finally starts. I tried to limit his face to 15 minutes. If I need more time, it's best to plan a second meeting. During this face, I keep the following in mind. I go through the body of my questions. I confirm understanding whenever it's needed, and I take notes and detect next steps and action points. Now we're almost step. We have now arrived at the conclusion of faith of the interview. But there are a couple of important steps that can be emitted. This part should take about five minutes outset. I make a quick summary of what I learned. I go to the next steps and action points that I was able to identify. And I check if I miss something in my summary and next steps, I organize a second meeting if required. I asked whether the interviewee still has questions or information they would like to share. I checked with the interviewee if I should speak to someone else that also has valuable information. And lastly, I think the interviewee for their time and I will close the call. Now for after 40 after care phase, which should take around ten minutes. I go through my notes and structured them if needed, and I finally send out the meeting minutes to the interviewee and ask them to react if there is something not correct or if something is missing. The volume, these are the main steps that I follow in each interview. Moving on now to the pros and cons on interviewing. Starting off with the advantages, interviews allowed to do a deep dive on a specific topic with a subject matter expert. During interviews, you can easily identify conflicts or discrepancies about certain needs or requirements. You can also quickly confirm your understanding with the interviewee. You can easily avoid miscommunications. You can build a relationship of trust with that person. It's quite easy to organize as it mostly involves just too people. It allows you to observe nonverbal communication and interviews and not expensive to organize. What about the disadvantages? Interviews require access and commitments from stakeholders. Creating structured interviews can be quite time-consuming. It's possible that stakeholders might have difficulties describing their future needs. So the focus is usually on what they do today and not what can be done better in the future. Interviews are prone to subjective mindsets of people. So be careful when people say, I think that inserted 0 and opinion. Fact check this. The resulting documentation is subject to interpretation of the interviewer. That's you or me. It can become time-consuming. If I do multiple individual interviews, perhaps I should consider workshop, which might make it go quicker. There's also not a possibility to do co-creation since there's only one person involved in the room. And I finally, the interviewee might provide wrong information due to lack of knowledge, which is hard to crosscheck, As you might not know that information is wrong in the first place. These were the main pros and cons of interviews. I would I would now like to offer you a couple of tips and tricks that helped me to make better interviews. First is do your homework, meaning that you should be prepared for the interview. So rehearsed the questions and your elicitation plan. Check the role of the interviewee in advance to make sure that what they rank is in the organization. Schedule interviews at least two days ahead of time. Some people might not appreciate that you schedule a meeting with them the same day unless they asked you to respect the person by being on time and display interest in the subject. Also, don't interrupt the interviewee. Match the pace of the interviewee. If there are cautious, try to talk slowly. If they are in a hurry, talk quickly. During this might seem weird, but you will unconsciously build a relationship with that relationship of trust with that person. You should also check your understanding as often as possible. In order to avoid misinterpretation, you need to let the interviewer know what will be done or what will happen to the information that they provided after the interview. When the interview we explains a need or an issue. Try asking them to give a concrete example. This will make this one and show that you understand their situation better. Try to interview two or three users with the same questions to ensure that you're able to do a cross-check and find any contradictions. Be sure to interview end-users who have more practical and real life insights. If you were just interview senior management about a process, you will get a fairly theoretical explanation. But it's big. This can be quite far removed from what's happening in reality. Allow time in your schedule to debrief and finish documentation of the rich interview. If the interviewer happens on site, try to conduct the interview in a separate space of the interview is usual workplace that's not distracted. Make questions open-ended to get richer answers. Close ended questions. Meaning that's, those are questions that can be answered with a yes or no. Do not provide a lot of information. Avoid questions that may present judgment or a conclusion to, not necessarily the interviewee. And my final tip is to structure your questions in a storyline format so that the interview feels more like a natural conversation than just a list with bullet points. With this information, you should be able to handle interviews easily. Let's move on now to the next technique. See you there. Bye. 8. Share your thoughts!: Hi, TiVo here. Sorry for the small interruption. I just wanted to let you know that if you're liking the course up to here, that you can already leave a review. Read use are extremely helpful to me as they let me know what is already good and what I should be improving. And it's also very helpful to your fellow students as they know if this course is worth following. Well, that's it for me. I wish you a nice educational day. Bye. 9. Conducting - observation: Hi, and welcome back. In this lesson we will cover another collaborative elicitation technique called observations. But first, let's define what I exactly mean with observation. Observation is the act of careful watching and listening is the activity of paying close attention to someone or something in order to get information. What are some of the characteristics that we can distill from this definition? Careful watching and listening hints towards the act of staying hidden and to observe what somebody or someone is doing. Now, don't worry, we're not going to spy on people. There are two types of observations IS job shadowing and task analysis. In job shadowing, you observe someone in their day to day activities and document everything they do, even the obvious steps regarding a specific process. You don't want to disturb the person as you might influence them when they do their task. And they might make do the task differently. As a result, the information that you collect is not as relevant anymore. The other type of observation is task analysis. It's slightly different from the job shadowing as there are. There you are allowed to distort a person to ask questions and or clarifications, for instance. Another characteristic that we can filter from the definition is to get information. Observation techniques are often applied in order to gather information on existing processes and to identify how to improve them. When would I use observational citation techniques? I would opt for job shadowing or task analysis if I want to quickly understand an existing process in order to improve it, observation is the best form of data collection for existing processes. It is almost unbiased. However, I would not go for this technique if I were asked to completely innovate an end-to-end process, observation techniques are very focused on what exists today and not what could be in the future. How can you best execute an observation? Let me walk you through the steps that I take when doing observations. First, those who preparation phase, which usually happens one week in advance. I make sure that I'm allowed to observe that person by checking with them and their superior. I explained what the purposes of the observation and I prepare my observation material, which could be a camera or recorder. Next, during the observation, I do the following. In the case of job shadowing and make sure that I don't disturb the person. I record everything and make notes of elements that surprised me or where I have questions about. I can't ask these questions later. I think the person for their time as well. Please note, depending on the process, that the duration of an observation can vary from a few minutes to literally days. If you need to follow up, say the onboarding of a retail customer in a commercial bank, it can take multiple days before the user is fully onboarded. They have to wait for the credit card and code reader for instance. There are also multiple legal and compliance checks that have to be done. Now for the final phase of the observation, the aftercare of observation, there is still some work to do here. So for instance, I convert the recorded data into usable information by mapping the steps in a process flowchart, I delete any sensitive and personal data. And finally, I send the results to the concerned stake holders for review and approval. Moving on now to the pros and cons of observation. Regarding the pros, observations are able to provide an unbiased view of how a process works. You, it's also very rich in the amount of information that you can get a true observations. It's easy to detect workarounds that have formed throughout the years. A workaround is often an indication of a possible improvement. The cost of observations can vary somewhat based on the process that is being analyzed. From the perspective of the person that is being observed. Observations can be considered to be quite cheap because the person is doing their work anyways. However, from the perspective of the personalised observing, it can become quite costly, especially if the observance is following and analyzing a process over the course of multiple days or even weeks. And the last advantage of observation is that it is very customer or user oriented because you follow them along every step of the process. Moving over now to the disadvantages, observations can be quite time-consuming when it comes to processing the information that has been collected. As mentioned before, observations can be quite time-consuming. If the observation session spans multiple days or weeks, not everyone might be willing to cooperate in this type of elicitation session because people in generally don't like to be observed. Another disadvantage is that during an observation session, especially during job shadowing, it's not always possible to confirm understanding or to ask questions. Another one is that you often can only observe what you see and not what happens behind the scenes. So additional elicitation is often required to create a full picture. The last disadvantage that I can think of is that observations are very focused on existing processes, the improvements that you would find that quite marginal. I would advise to go for another approach if your task with completely innovating a process from end-to-end. I can't let you go with a couple of best practices. Here's the first one. Try recording using a camera or a microphone as to make sure that you don't miss anything. You often don't get a second chance to do an observation. It has to be right from the first time. Next, try to map the full process after the observation using a process flowchart enter to detect possible improvements. Also try to show that process flowchart to the person that you observed because you might have missed something and they can point it out and they can also already provide some improvements. Then explain to the person that you will observe that they are not the ones that are being tested, but the process is the one that being tested. You are there to make their lives easier and more productive. As you follow along list of questions that you have with an indication on which part of the process it is related to in order to quickly find it back. And finally, explained to the person what will happen to the information that you collected. The more transparent, the better. Now we have arrived at the end of the observation elicitation technique. You're doing great. Let's move on to the next technique. See you there. Bye. 10. Conducting - brainstorming: Hi, and welcome back. In this lecture, we will cover another collaborative elicitation technique called brainstorming. Now, what exactly is brainstorming? Brainstorming is the act of generating ideas by one or more individuals to find a solution to a problem. Going through the definition, it's possible to further break it down into a couple of characteristics. One of them being generating IDs. This is actually one of the main strengths and uses of brainstorming technique that's focused on generating as many ideas as possible in a rather short timeframe. There are no wrong or bad ideas in a brainstorming session by the IDs will be filtered out at the later stage. The definition also mentioned by one or more individuals, you have to know that there are multiple types of brainstorming types. One is conducting individual brainstorming sessions. You pretty much generate ideas on the road. This can be useful to prepare a brainstorming session to spark people's creativity. Another type is group brainstorming, which can again be subdivided into two categories, being open group brainstorms and structured group brainstorms. The open brainstorms are open in the sense that everyone is just throwing in IDs in a group and someone is documenting those IDs as the group goes on, there is no real facilitation going on to direct the groups sinking. The opposite of open brace storms are structured brainstorms. During these types of sessions, the facilitator will direct the brainstorming efforts in a structured format, right down and group IDs together and ensure that everybody is being heard. This last part is quite important. As you can imagine, that strong-willed people might intimidate others to share ideas. If you don't pay attention to that, you might end up with a one-sided set of IDs coming just from a few people. Next, the facilitator will also ask so-called what-if questions to keep the session going until all IIT's are depleted. In essence, the facilitative provides hypothetical scenarios to keep the session going. Moving on now to when you should use a brainstorming session. Personally, I would use brainstorming sessions for the following reasons. The first one would be if I need to solve a problem that requires creativity and out-of-the-box thinking. The second one would be if to gain more buy-in. You can imagine that an ID that came from a group of people, it's usually more credible and has more weight than if it came from individual person. What about the execution of a brainstorming session? As an example, I will go over the steps of organizing and facilitating a structure type and brainstorming session over the course of two hours. You might have guessed it. First, we start with the preparation phase. The length of this phase can vary quite a bit. If you want to start to brainstorm from scratch, then the preparation phase can go quite quickly. You just need to clearly state the problem you're trying to solve. But be careful. When you do this, the level of ideas created reflects the preparation of your brainstorming session. If your participants don't get any information prior to the meeting, they will generate IDs which are limited by the knowledge they possess on the topic. If however, you want to increase the quality of the IDEs, you might want to research a topic more in depth and share your findings with the participants prior to the session. As the result. As a result, they will know more about a topic and come up with potentially better IDEs. The saying of garbage in equals garbage out is quite applicable in this setting. So in summary, the preparation phase can vary from a few minutes to many days if you decide to do some research up front. So that was the question on the duration. Next, we also need to figure out who to invite. You have to make sure that the group is diverse enough. Since it has been proven that diversity enriches degeneration of IDEs. Think here of the saying to the man with a hammer, every problem looks like a needle. Meaning that if you only invite people with the same background and skills, they will solve a problem with the tools they have. As a results, the solution becomes very unnatural and perhaps sub-optimal. Then there is also the how many question I will try to keep the amount of participants limited to, let's say, eight or ten people, too many. It's not ideal as some people might not feel the need to participate and it's also more difficult to manage. Moving on now to the where question, I would advise to have a brainstorming session in a bright room away from people's usual workplace. You need to create an environment that allows creativity. Also, you don't want people to be disturbed by their day-to-day activities. Also, don't forget to foresee post-its pens. A whiteboards and available walls so that people can write down their ideas and put their posts itself. Finally, how long should a brainstorming session take? I believe that sessions of maximum two hours provide the best results. Sessions that take more than that tend to be counterproductive because people don't stay creative for that long and are just not motivated anymore. It's better to organize multiple sessions of maximum two hours, ten, just one big brainstorming session where you lock up people in a room for the whole day. That was the preparation phase. Now we go into the introduction phase. They should take about 15 minutes. During this introduction phase, you introduce yourself and let everybody introduce themselves as well. After that, you proceed to the problem statement and summarize the main findings of your research if you did anything upfront. You also explained the structure of the brainstorming session. What will happen with information afterwards? Be transparent. Finally, you should explain the rules of the brainstorming session. For instance, it's not allowed to break down IDs or interrupt people that are sharing their 80s. You can write the rules on the whiteboard so that everybody can see it at all time. I often like to start off with a brainstorming session, icebreaker that makes people more comfortable and more creative. You have to understand that people are often not participating in these types of sessions. It's quite outside our comfort zone. People don't want to be judged when opening up and being creative. As an icebreaker, I prefer it to be quite practical and productive. Ask people to already come up with not their best, but the worst ideas they can think of. It's quite a funny exercise as there is no shame involved. And it might surprise you that some ideas are actually quite good and can be used in the actual brainstorming session later on, this part should take around ten minutes. Let's now go into the expansion part of the brainstorming. During this phase, you facilitate to brainstorming session and aim to have as many ideas as possible. I usually proceed as follows. First, I let everybody do an individual brainstorming session, meaning that everybody is writing down their ideas without discussing or sharing them. This is more efficient to generate more ideas quickly. I would say it takes around ten to 15 minutes. Next, when I see that most people have stopped writing down, I opened the group brainstorming session and let's everybody share their ideas. During this part, it's not allowed to break down other people's ideas. You're only allowed to build upon the parties that are shared. This is part this part is about a co-creation, which is also one of the main strengths of brainstorming. While people are explaining their ideas, are already starting to group IDs that go together and try to detect patterns or coherent solutions. This whole part takes about 30 minutes. Now's a good time to have a little break and let everybody stretch their legs. Having a break is very beneficial because your subconsciousness is still busy processing information and could come up with even better IDs when the brakes over, I would say a ten minute break should be more than sufficient. During the focus phase, it's time to find that specific ID that will help us solve our problem. The first thing I do during this focus phases, I asked everybody to discuss the ideas and argue why they're good or bad. The goal is to have a list of pros and cons per ID. This should take around 20 minutes. Then I ask everybody to vote on the IDs, are they liked the most and should also be further refined. Typically people get three votes and the idea with the most votes wins. This should be about 15 minutes. Now that the group has identified the solution, you need to explain what's going to happen with that solution. This usually involves more desk research and refinement on your side. Be careful not to throw away other IDEs as they might still hold some value. This phase should take around ten minutes. And after that, I think the people for their active participation now comes the aftercare phase. During this phase, I will document all the findings of the workshop and an Excel or a Word document so that I can share it with the group and any other relevant stakeholders that are interested in the results. Also don't forget to tidy up the room, and this should take around 30 minutes. That concludes the execution part. What are the pros and cons of brainstorming? Some of the advantages are generating many ideas quickly, quickly detecting solution and capture consensus from the group. It involves multiple perspectives. Remember the more diverse the participants, the DID, if done correctly, it also promotes equal participation. There's also an element of co-creation. Participants are asked to enrich their colleagues IDs. It promotes over the box and creative thinking. And the last PRO that I can think about it is that you get a strong buy-in from participants as. The idea is essentially there's, remember, an ID coming from multiple people carries more weight compared to an ID generated from individual. What are enough? Some of the cons, drink brainstorming sessions, IDs are often not explored in great detail. They are just identified and listed. Perhaps with a bit of more time and research, a good idea could even become agreed ID. The preparation work can be quite lengthy, especially for structured brainstorms. There is also a strong dependence on the expertise in the room. As I mentioned before, garbage in equals garbage out. You have to be careful of BI solutions. Do two strong-willed people, make sure that everybody gets a voice during the session. You have to also to make sure that you create a safe environment. Inviting a participant's boss, for instance, might hinder the participants creativity as it might not want to come across foolish. It requires a strong dose of facilitation skills to run a structure group brainstorming session. Finally, it creates an environment where it is easy to judge people and be judged. As always, I will disclose some of the tips and tricks that helped me during my brainstorming sessions. First, determine the type of brainstorming meeting ahead of time. Publish an agenda prior to the brainstorming session to ensure that everybody is up to date. Clearly state the objective of the meeting and the problem statement. If people are solving the wrong problem, the brainstorming session for any much becomes irrelevant, creates environments that encourage participation and creativity. When people explain their ideas to make sure that the environment that everybody gets their turn. Establish ground rules at the beginning of the meeting and write them down somewhere visible. Some examples of rules or do not discuss ideas during the brainstorming session to the expansion phase. Do not dismiss or discount an ID or a person and do try to build on other people's suggestions, and most importantly, do have fun. Another best practice is to establish roles prior to the meeting. If you're lucky enough to receive help. The roles you want to define are a facilitator, a timekeeper to ensure that we do not go over the timebox to gender and describe that collects the participants IDEs. This will drastically reduce the aftercare work. If you feel that you need more time, create multiple sessions with some time in between to keep motivation high. Finally, have a voting system in place to choose to final IDs that will be further analyzed. This is the most democratized way and it creates the most buy-in from everybody. Voila, you now have all the necessary knowledge to conduct a brainstorming session successfully. Let's move on now to the next technique. See you there. Bye. 11. Conducting - workshop: Hi, and welcome back. In this lecture, we will cover the next collaborative elicitation technique called workshops. I call ways. Let's have a look at the definition of a workshop. There isn't simply one correct definition. But the one I found to be the most accurate goes as follows. Workshop is a meeting where a group of people engage in intensive discussions and activity on a particular subject or project. When breaking down the definition, we can identify some workshops characteristics. The first characteristic is about towards a group of people. Unlike brainstorming, you always need multiple people to do a workshop. You can't really do a workshop by yourself. Who you want to invite mainly depends on the topic of your workshop. You do not necessarily need diversity, but rather expertise. You want to invite people with the right set of skills and knowledge to have in-depth discussions. For instance, I did workshops with only IT developers, and that's completely okay. As the goal was not to generate many ideas to solve a problem, but to discuss, say, the technology we would like to use to build an app sales flows. The next characteristics we can distinguish in the definition is about the project on the subject. This part of the definition refers to the scope of workshops as a whole, you can virtually conduct workshops for any type of topic where you need input from multiple people. However, for generating main ideas, the brainstorming technique would be a better choice. There's not really a standardized type of workshop, but there are some workshops that are more relevant for business analysts than others. You have the formal requirements workshop. This workshop typically is highly structured and quite formal as it also serves as a validation moment for requirements. During this workshop, you define, create, refined, and reach closure on business requirements. The group of stakeholders is carefully selected and depends on the requirements that are tackled in the workshop. Another type of workshop is the business process improvement workshop. This one is semi formal. During this workshop, you analyze existing business processes and you try to identify possible improvements for that process. And the last one is the Agile requirements workshop. This one is usually more unstructured and informal. In this workshop, you go over the requirements with the product owner and the development team. Based on your requirements, the product will do the product rule and we will create user stories and puts it in his or her product backlog. There was a definition. Now, when would it be appropriate to use a workshop? You might have noticed that there are quite a few similarities between workshops and brainstorms. However, they are used for completely different reasons. To put it simply, where brainstorms are used to generate many ideas to solve a problem in a creative way. Workshops are used for everything else that involves a group of people. If you want to create a better way of working between departments, do a workshop if you want to define new objectives for your product, to a workshop, if you want to build a ScreenFlow for selling a product, I want to make sure that everything is correct from a legal perspective. You guessed it, do a workshop. You want to do a cost-benefit analysis around to IT components. That workshop. I hope that with all these examples, you understand that the scope of workshops is actually much broader than brainstorming sessions. How would I execute a workshop? Well, given that there is not a single type of workshop, I kind of adapt to the execution of set workshop in a way to best match the situation. But there are some parts that should always be done. So let's go over them. I will go over the steps I would take to give a requirements workshop as this is the most formal 1. First, we start with the usual suspects, the preparation phase. The main preparation that needs to happen prior to the meeting is to have a clear definition of the ASIS and to be situation when needs were trying to solve today and how does the ideal situation look in the future? You should aim to have these two analysis deliverables prior to the meeting and shadow with, share it with the stakeholders to fuel the workshop. This can typically be done by creating a concept report, but this falls outside the scope of this course. The preparation phase can take quite a while if you take those aspects into consideration. Now, who should you invite you to workshop? Expertise is the main driver behind choosing the right participants. If your problem looks like a nail, invite people with hammers. It can be an ID to hold multiple workshops, one for each type of requirement. So you could set up a workshop with legal to create a legal requirements and have a separate workshop with data analysts to create the data requirements, for instance. Next, you need to ask yourself, what is the maximum amount of people you should invite? If we're brainstorming sessions, I would try to limit the maximum amount of people to eight or ten. As mentioned, you can split two workshops by business units and type of requirements as to where the workshop can happen. It's a group discussions, so a simple meeting room should do the trick. The next phase you have to consider is the introduction. This phase should take about 15 minutes. Like always, introduce yourself and that everyone around the table introduce themselves. Then you go over the problem statement and explained the main findings of your concept, of your concept report. Next, we arrive at the content phase of the workshop to create requirements, there are many types of techniques. One that I like to use is the customer journey mapping. It's a technique that is often used in an agile environment. It helps to build solutions that are very user oriented, and it helps to prioritize requirements to build the right Minimum Viable Product. This technique definitely deserves a lesson on its own, so we'll go over it quite quickly. The first part of the journey mapping exercise, you define the main activities that the user tries to do. This is the backbone of your customer journey. Then you define within each activity the different user tasks that the user has to execute. Next, you draw a line, a horizontal line, which separates what user tasks should be done to reach activity and which are not actually meet it. What's above the line is required for the solution to function and what's under the line can be done at a later stage. This helps to prioritize and create the MPP of your solution. Let's use a practical example to better illustrate this technique. Imagine your morning routine. When going to work. The main activities are waking up, taking care of your gene, dressing up, eating, and traveling to work. Within each activity you have a myriad of tasks. Under hygiene, for instance, you have showering, brushing your teeth, putting on a few, etcetera. If you were to run late, can you think of certain user tasks that you might want to skip? Well, for me, for instance, I would skip the perfume port. However, I would keep the brushing teeth task as, as I consider it to be an absolute must. Skipping breakfast could also be an option. What I tried to illustrate with this example is that you have to see the user tasks as requirements. When defining the first increment of your product, you really have to think whether or not you need this requirement from the start. But as I said, this falls outside the scope of this course and deserves our lecture on its own. After the content phase, we can now move on to the conclusion phase. In here, you summarize what you learned. Go through the next steps and action points. Organize a second workshop if needed. And of course, thank the participants for their time. This typically takes around between five to ten minutes. After the workshop, you go through the customer journey mapping exercise and create a digital version of it. Finally, you send out meeting minutes to the participants and other stakeholders that are interested in the results of the exercise. This typically takes 30 minutes. As always, let's discuss the pros and cons of workshops. The good news goes first. There is a greater chance of obtaining consensus because issues and questions are asked directly during the meeting, you can quickly check the accuracy of the requirements which participants it allows to successfully gather requirements from a large group in a short period of time. Documentation is completed within hours of the session and shared with the participants for review and approval. Finally, the scope of the workshop uses. The workshop uses is very broad and flexible. Going on to the bad news, it can be difficult to get all relevant stakeholders in one room at the same time. Big workshops can be complex to organize and posts logistical issues. Success of a session is also highly dependent on the expertise of the facilitator. It can be expensive, especially if there's more than one workshop. To finish the preparation can be quite time-consuming, especially if you need to build a whole concept report. What are some of the best practices, tips and tricks that I can give you? It's important to have a good idea of the type of requirements workshop ahead of time. Clearly state what you expect from the workshop. What are the deliverables? Don't hesitate to be very visual when facilitating the workshop. You have all the experts in one room or cool. Use that as an opportunity to visualize model structure requirements. As you move forward into the discussion, you will need to do this anyways. So might as well do it now. Makes sure that you feel comfortable to run a workshop, especially larger ones with people that you usually don't work with. Also makes sure to limit meeting to the key stakeholders. Don't invite half the company as it will make the results of the workshop sub-optimal and quite costly. Remember that you are an analyst, not just a scribe or a facilitator. You also have to actively participate in the exercise follow-up. This concludes the bottom workshops. Let's move on now to the next technique. See you there. Bye. 12. Conducting - documentation review: Hi, and welcome back. In this lecture, we will cover the next collaborative elicitation technique called documentation review. Now, for documentation with you, there is not a clear cut definition, but I will try to describe it as best as I can. Documentation with you is the activity of going through existing documentation in order to obtain information on a specific topic with existing documentation or inferring to all the documentation that has been written on the topic and which can provide you with a better understanding. In order to find requirements, consider looking at documents such as user guides, IT architecture documents, concept reports, wireframes, user test reports, marketing presentations, project briefs, backlog of user stories, product descriptions, online content, benchmarking, surveys, etc, etc. There's really no limit to the amount of documentation that you can analyze. As for the activity itself, it's mostly desk research, but I would strongly advise you to set limits for yourself as to how far you want to go. This can really be a task without ends. So it's important that you define a personal barrier. When I'm doing documentation review, I will try to limit the amount of research I do two period of maximum two weeks for instance. That way I don't get lost in too many details. The goals of documentation review can be very broad. So I defined upfront the pieces of information that I need to better understand the problem and the current situation. Here are some of the categories to look for. The first category is about information related to the products and services relevant to your need. You should try to find the answers to the following questions. What is the current offering of the company? What is the distribution sales model? What is the revenue model and the main costs drivers? What are the objectives? What is the marketing and go-to-market strategy? What departments are involved to enable the offering of those products and services? The next category is about information related to capabilities. You should try to find answers to the following questions. What is the high-level process to create those products and services? What IT components are impacted to enable the products and services that are in scope. What skills or requirement from a human capacity, human capital perspective. The third category is about information related to the company itself. Here you have to ask yourself, what is the organizational structure of the company? What is the high level strategy regarding the products and services? The fourth category is around information related to the market for those products and services. You should try to find answers to the following questions. What are the best practices on the market? What are the high-level market trends? What are the main suppliers? Water customers? What segment is accompany targeting? Who is the main competition and what products and services are they offering? The final category is about other sources of information that you also should consider. One of them is possible abbreviations. So understand what are the abbreviations that are used inside a company? You want to have an understanding of the historical context that was run decisions that were taken in the past. You want to capture lessons learned from previous and similar projects. You want to find out who the experts are that work on the project so that they can further help you define your project. I also wanted to know if there's any ISO, ISO standards that are replicable. Now when would I use documentation review? I would use it when I just started on a project. That way I can quickly build up a certain basic level of understanding which I can later use on preparing other elicitation activities. In terms of execution, there is no real structure, but I will try to timebox the activity as a whole to maximum two to three weeks, just to make sure I don't get lost in the analysis. Here's a possible way to execute the documentation review following the scopes of deliverables. In the first week, I would try to find information on the company, the market, and the competition. In the second week, I will try to find information on the products and services, the technical capabilities, and also the skills that are needed. From a human capital perspective. I would also have third week as a buffer if I uncovered any type of documentation needs to the previous two weeks that you need to have access to this information. So you will first have to find the right stakeholders that can help you and point you in the right direction. Moving on now to the pros and cons of documentation review. What do we have in terms of advantages? First, it's a source of information that gives a good view on the SAS situation. It's a way to quickly get up to speed when you are starting on a project. Current process documentation provides a good overview of the context and past decisions. You can also spot SMEs that, that worked on it more quickly. Now what are some of the disadvantages? Often existing documentation is old and outdated. Additional elicitation is also required. The reviewer needs also domain and technical expertise to understand the content of the documentation. Finally, it can be quite time-consuming. Amy not provide the desired results. As always, I will also provide you with a couple of best practices that I found to be helpful when doing documentation review. First advice would be to use this technique early on in the project to quickly get up to speed. It's important to define upfront information you are looking for. It's also important to get self-imposed a time limits. I gave the example of two or three weeks. Maybe you can take it to a month, but I would not go over that. Try to figure out who the experts are that worked on the documentation and who can interview with them to see what is still relevant today. Finally, if you have the opportunity tried to create a small glossary of abbreviations that you encounter. This will make your day-to-day communications with employees easier to manage and to follow. That says for documentation review, we have covered already quite some grounds, but there's still more to come. I will see you in the next lecture. Bye. 13. Conducting - interface analysis: Hi, and welcome back. In this section we will cover the next collaborative elicitation technique called Interface analysis. Put quite simply, interface analysis is the act of doing analysis on existing interfaces in order to obtain information about the situation. When breaking down this definition, we can distinguish multiple characteristics. The first characteristic is linked to the act of doing analysis. There are multiple ways to do analysis on interfaces. There is the self analysis. So you do an analysis of the interface yourself and write down everything that you see happening and try to find gaps in terms of functionalities. You also have the customer or user review workshop. During these workshops, you showcase the interface to a group of users in order to study the interface and to identify possible improvements in terms of user experience and functionalities. Finally, you have the developer review workshop. During these workshops, you present your interface to developers in order to identify what technical calls are made to the back-end. This last one makes sense if you want to create a proof of concept based on the screens that you see at the competition, for instance. The second characteristic is existing interfaces. By existing interfaces, we consider any type of user interface that connects a user with a system. There are two large groups of interfaces. You have interfaces that are used by accompanies customers. And you have interfaces that are used by the company's own employees, also known as internal users. For both groups, we want to make sure that the customer or internal user is able to execute a task in a user-friendly way. For customer interfaces, you can imagine any type of app that you're using. The platform on which you watch this very video, for instance, is a user interface. For internal users interfaces, you can imagine the interface at your bankruptcies, for instance, when he or she is consulting your accounts. The third and last characteristic is about obtaining information on the situation. With interfaces. With the interface analysis, you have the latest view on the situation. You have a good ID of 40 active functionalities are off the solution. I say active because sometimes companies choose to create Dorman functionalities that still needs to be activated. You also get a clear view over d interaction points between the user and the system. You get a clear view on the inputs that are needed and the outputs it produces. And you also have a view of what part of the solution is manual and what part is automated. When would I use interface analysis would use it to get an up-to-date view on the functionalities and the processes linked to the existing products and services that are offered to customers or used by internal employees. I would also use it to have a clear understanding of the capabilities that enabled those functionalities. This I do by creating a process flowchart that includes the user, the frontend interfaces, and the back-end components. How would I execute an interface analysis? It depends on what type of interface analysis you are running. If it's a self analysis, then it follows the same approach as documentation review. If you choose to do a review with users or developers, then it's a little different. Let's assume that I want to organize a user review workshop with some external users for customers. The goal of this workshop is to find gaps in the functionalities and ways to improve the existing user interface. As always, it starts with a preparation phase to do face analysis in a focused and non-count equate, I would opt for a task-based approach, meaning that I would create a set of tasks in advance and ask the user to execute those tasks. First, need to figure out what functionalities I want to test and create a tasks that envelopes those functionalities. Once I have the tasks, I need to create a scoring board that I will use to score the functionalities and the user interface. This will help me to easily identify improvement points and missing functionalities. Next, I need to invite the different participants. Large organizations often have access to user researchers who can contact external users. So I would go via them and ask whether they could schedule multiple user tests. It's important to provide them with a briefing in advance which describes what you want to test. Often they will also do the facilitation. You might also want to think of certain demographics or segmentation criteria that you want to account for in your user review workshop. Be mindful that the more criteria you include, the harder it becomes to organize a test. It might not be able to find the right participants. I remember that, for instance, that we wanted to test a specific interface that was only available for wealthy customers of the bank. This is quite touchy, touchy topic as this important customers. And you can't just directly contact them. We first had to inform their relationship manager in order to check if we are allowed to invite those customers or to the workshop. In terms of sample size, I would opt for a total of five to six sessions with just one user each time. This way you get a qualitative feedback where you can identify patterns and you make sure that participants are not influencing each other. I would also foresee some type of reward for completing the recession. But again, this might be arranged by the company. The preparation phase can go quite quickly. So I would say it takes about two days to set up the tasks, create a scoring board, and brief the user researchers if there are any. Next, we go into the introduction phase of the workshop, which should take about ten minutes. If you happen to do the facilitation yourself, it's important to keep the following points in mind. Introduce yourself and let the participant introduce his or herself. Explained that you are testing the solution and not the participant who don't want them to stress out. Explain the content of what you're about to test. Also mentioned that users will get a reward after the session. If one has been foreseen. Then there is the content phase of the review, of the review workshop, which should take about 45 minutes. During the content phase to user executes the different tasks that you defined and the preparation phase. Moving on now to the conclusion phase of the user review workshop, which it should take around five minutes. During this phase, you ask the participant what they liked and this slide and what they would improve. Don't forget to sign them at the end of the session. Note that if you have six participants, you have to do this workshop six times already, which amounts to six hours. Closing off with the aftercare of phase, which should take about 40 minutes. Here I create a user test report with all the findings. Possible structure for your report could be as follows. First, I'd have an executive summary with what was tested, what went well, and what could have been improved. Followed by a section to explain who the participants were and some of their demographics, which is then followed by a section for each task. And also write down what all the users did during that task. I include the screens that were tested as well and finalize with a conclusion section, including the next steps. After creating the report, I send it to the relevant stakeholders. Moving on now to the advantages and disadvantages. Starting off with the advantages, interface analysis provides a crystal clear view on the ethics situation with T existing functionalities, the inputs and outputs of the solution and the user experience and their interactions. It's easy to detect missing functionalities and points of improvement. And it's easy to understand the link between the front-end and the back-end. Lastly, it's also good technique to capture user experience as you get information directly from the source. What are now some of the disadvantages? The elicitation might quickly get very technical. It focuses also too much on the existing situation and minor improvements. So it's not an ideal elicitation technique if you want to go for more radical innovations. As mentioned, six review workshops already amount to six hours. So it can become quite time-consuming to conduct. It might sometimes be redundant with quantitative research based on historical data. Here are a couple of best practices that I can give you with regard to facilitating your review workshop. Try to minimize the amount of guidance who give to the participants as you don't want to have biased results. If they can't complete a task, there might be an issue with the solution. Make sure to record all steps that the user is going through or not. Write down any suggestion that the user has made sure to workshop. Also remain as neutral as possible. If the user is raving about how much better to competition solution is, let them, you might want to take a look. That's why that's a competition solution is so much better. Map the user journey with the links between the user, the interface, and backends. You might even go as far as mapping the user experience on the different steps of the user journey to really visualize where improvements can be made. Follow. This concludes the interface analysis elicitation technique, but we're not done yet. I'll see you in the next lecture for even more techniques by. 14. Conducting - survey: Hi and welcome back. In this lecture, we'll cover a research elicitation technique called surveys. I'm quite sure that you've all heard about what a surface, but let me just go over the definition again. A survey is a large scale, qualitative or quantitative examination of opinions, behaviors, knowledge made by asking people a set of questions. As always, let's break down the definition into its characteristics. The first characteristic we can look into is large scale. Often surveys are sent out to a large audience. This has to do with the fact that the sample size needs to be big enough in order to form an accurate representation of the population. Sample size larger than 30 is set to be statistically significant and can be used to run statistical inference. If the sample size is smaller than this number, it's not really safe to generalize the findings in your sample to the rest of the population. But then again, there are exceptions to this rule. For the sake of simplicity and the scope of this course, let's take minimum sample size of 30. The next characteristic is qualitative or quantitative. Quantitative data is about data that have numeric variables like how many, how much or how often. On the other hand, quantitative data is data about categorical variables. Notice survey can be both quantitative and qualitative at the same time. It depends on the questions that you ask and how you ask them. For statistical inference, it's preferable to use quantitative data and use qualitative data to make more sense of the patterns that you find. The third characteristic is linked to a set of questions. We distinguish two types of questions, which are open-ended and closed-ended questions. Open-ended questions are questions where respondents have complete freedom to answer questions. It gives them the opportunity to include information such as opinions, arguments, connotations, a tone of voice, emotions, etc. This in turn allows the survey taker to capture more information than if it were simply a close ended question. But it takes a lot of time to process. It doesn't lend itself to statistical inference. This brings us to the next type of questions which are close ended. These are questions with a finite amount of answers. There are multiple types of close ended questions, such as a simple binary answer, such as yes or no. You also have multiple choice questions. It's more efficient to process, but it provides less freedom to the respondent. Another one is ranking questions where the user has to indicate a degree of agreement or disagreement with a certain statement. This often is measured on a scale of seven possible answers which range from I completely disagree too, I completely agree, or form, or from NADH very important to very important. Next, we have the question of when it's best to use surveys. Personally, I would use a survey if I'm interested in studying a population or a large segment of users or customers. I would like to know what the popularly, what the population of users, things of the product or service, how would I execute a survey? And the preparation phase, you will basically define your questions, build your survey storyline, define your population sample and send it out. Plus also set a deadline. When you define your questions, make sure that your questions are not leading to a certain answer. And also makes sure that they are easy to understand. If your questions are hard to understand, you can be sure that respondent's answers will be biased. Don't hesitate to ask a colleague to do a cross-check as it can take up the role of a respondent and get feedback on your survey. When you build surveys, the survey storyline makes sure to first start with easier questions and keep the harder questions towards the end. People will tend to not stop midway because they already came this far. Also finish your survey with demographic questions to make it easy, again, it makes sure that the overall duration of the survey doesn't take longer than 30 minutes. If the survey takes too long, people tend to lose motivation and won't answer questions at the store ugly as they did in the beginning. Define your population sample. This should be as random as possible to avoid any type of bias unless you want to have answers from a specific group of respondents. Also, if you have a target amount of responses in mind, try to send out a survey to a sample which is ten times the size of your response targets. It 10% response rate is to be expected in service. Though that you can increase this response rate by also having a reward. You can send out your survey using free online tools that give you a large reach. Those tools will also allow you to easily study the results of your survey and to send reminders if needed. Survey Monkey or Google forms are good candidates. Make sure to include a deadline, I would say two or maximum three weeks should be sufficient to fill in a survey. You will most likely not receive any additional answers after three weeks. Now, let's move on to the execution phase. There's not much to do here, apart from the monitoring of the numbers of responses and sending out reminders if necessary. As mentioned before, this phase should take around two to three weeks. In the aftercare face, you can go through the responses of the survey. If you made a quantitative survey, it goes quicker as you can use statistical inference to identify patterns and other types of inflammation. If it's qualitative, then you will have to go through all the answers of your surface. So the duration of this phase tends to vary depending on whether it's qualitative or quantitative. Now, what are some of the advantages and disadvantages? Let's go with the advantages first. It requires a limited amount of time to fill in a survey for the stakeholder. It's very effective at reaching geographically dispersed users. Surveys are easily scalable for large audiences. You can have a good understanding of what your population once or thinks of your product or solution. There are relatively inexpensive to administer. And surface can enrich more subjective information coming from interviews, such as opinions. Next, what are the disadvantages? Surface usually have a relatively low response rate. You have to mind how your free, how you phrase your questions. Poorly worded questions may provide inaccurate information. The use of open-ended questions requires more time and analysis by the business analyst, and it's this also more time-consuming. Finally, incentives for responding might come inexpensive. What are some of the tips and tricks that you can apply when creating surveys? First, focus your questions on high priority risks that have been identified. Identify users as satisfaction levels with existing systems. To set a baseline. Questions should be directed and an ambiguous, safe, complex questions for later in the survey. And also saved demographic information for last, create rewards for participating and create a survey with inexpensive online tooling. And to conclude, notify the participants when the survey is available and continue to remind them to participate. Follow-up. That's it for the survey elicitation technique. There is also another research elicitation technique called analysis of historical data. But I will not cover this technique in this course at is, as it deserves a course on its own. That's something also for the data analysts among us. Sorry guys. I will see you in the next lecture. Bye. 15. Conducting - prototyping: Hi and welcome back. In this lecture we'll be covering an experimental elicitation technique called prototyping. What exactly S prototyping to begin with? Prototyping is user-based experimental process where design teams implement IDs into tangible forms of varying degrees of Fidelity called prototypes. Now what's that beast? Let's go to the different parts of this definition. The first characteristic that we encounter is user-based. Put a typing isn't elicitation technique where the user is central. Prototypes are updated, adapted, transformed based on what's users experience and say when using the prototype. The next characteristic that we encounter is experimental process. This points towards the fact that prototyping is not a one-shot exercise. You do prototyping on incremental and iterative basis until you have a prototype that perfectly matches what's your customers or users want. Prototyping is inherently a process of trial and error. The very course that you are following now has been following an experimental process. It is being updated constantly based on the feedback that I receive from you, the users. So please don't forget to leave a review. Furthermore, I would like to highlight the design teams characteristic. This can be a little misleading as you might think that only user experience designers are doing prototyping. That is of course not true. Everybody who is creating a new product or service can be considered to be a designer, can be an architect, a product manager, a data analyst, and operational engineer, a business analysts, etc, etc. Then we have implemented these into tangible forms. This now is the essence of prototyping. You want to create a proxy of the product or service so that you can test it with users. Many great products have been created that way. Dropbox is a good example. In the beginning they were testing the concept of Dropbox through a janitor type of prototype. This means that the users were testing out the functionalities of the product when it was actually a human behind the scenes that executed tasks. So users who are giving feedback on Dropbox functionalities and not a single line of code was written yet. That way Dropbox was able to capture customer feedback very, very early in the development process. Lastly, we have the grease of varying fidelity. You need to know that there are multiple types of prototypes that you have to consider. These types distinguish themselves based on how closely they mimic the final product. This is called prototypes level of fidelity. Let's look closer at the two extremes, low fidelity prototypes and high fidelity prototypes. Low fidelity prototypes are very simple and limited version of the solution. Think of prototypes made on a piece of paper like a comic, for instance. Will often find these prototypes in the early stages of software development lifecycle, where the concept is tested as a whole. On the other hand, you have high fidelity prototypes. These types of prototypes are already closer to what the actual solution should look like. Think of software generated wireframes, which are actual screens of the solutions interface with the right colors, labeling information architecture, and so on. The only thing that's different from the real solution that is that there is no code behind the screens. You will often find these types of prototypes towards the later stages of the development life cycle. When should you use prototyping? Quite frankly, in a world that's revolves around customer centricity, I would always use prototyping whenever building or updating a product or a service. It's a cheap and quick way to see if what you're building is the right thing for your users. So the question is really, why wouldn't you use it? Moving on with the questions on how to execute prototyping. Creating the prototyping itself falls outside the scope of this course, as we are only interested in the elicitation technique linked to prototyping, which is user testing. You might be happy to learn that you already know this technique as it is very similar to the user review workshop, which you can find in the interface analysis part. So I invite you to re-watch that lecture if you're unsure about the execution steps. Moving on now to our trusty pros and cons, I will especially zoom on the pros and cons of low fidelity versus high fidelity prototypes. Starting with the pros of low fidelity, it can be done at almost no cost. There is no need for any skills. In prototyping software. You can get feedback from users with very quickly. It's best to, its best fitted to test concepts and IDs. It always allows for very rapid trial and error if it's helps to structure discussions with users and stakeholders. Now, moving on to the low fidelity disadvantages, the lack of realism linked could temper with the elicitation results as you might not get relevant users feedback, they could start filling in the gaps with their own imagination. So to say, there is the issue of oversimplification. So some aspects of the prototype might actually not be possible to develop. There is also the lack of actual interactions with the limits are for the elicitation results. Next step, we have the high fidelity prototypes that very closely resembled the final solution. What are its pros? It's a very rich source of requirements. You can use high fidelity prototypes to list all the requirements that you see and enrich it. If you find gaps. It provides a very good picture of the solution which makes it easy to use in discussions with all kinds of stakeholders, such as your business stakeholders, legal and compliance developers, user designers, etc. It allows for rapid trial and error at a low cost. It can be used in user tests where you can already collect feedback early on on the solution. We will also highlight less obvious areas of improvements, such as unforeseen user behavior, user usability issues, etc. To conclude, what are some of the cons linked to high fidelity prototypes? The first one is that it's often costlier and it takes more time to make than low fidelity prototypes. You might receive feedback during user tests on superficial details rather than on the inherent aspects of the solution. You need to have some skills for the prototyping software to create a prototype and stakeholders. And also developers might confuse the prototype with the final solution and actually go ahead and start to form their assumptions based on that and even develop it. And the last column I can think of is that there is sometimes a misplaced attachment to the prototype which could interfere with making changes. Remember, you need to feel fast, it's trial and error. Don't attach yourself to the prototype. Regarding best practices, I again advise you to have a look at the user review workshop in the lecture on interface analysis. Voila. This concludes the lecture on prototyping, and it also concludes this section on requirements elicitation techniques. If you want me to cover other elicitation techniques, don't hesitate to let me know. I will gladly cover them as well. The next section we will cover the next step in our elicitation journey, which is confirming your understanding. So confirming what you, the information that you just contact it. True. Oldest nice takings. I hope to see you there. Bye. 16. Confirming - introduction: Hi and welcome back. In this section we will cover the third step of requirements, elicitation, which is confirming your understanding. First, I will cover what exactly I do mean by confirming your understanding and also why this is an important step in the elicitation process. Confirming your understanding will make sure that the information that you collected is accurate without errors or information gaps, and also without contradictions with other information sources. Imagined the consequences if a certain piece of information turns out to be wrong, in the best case, you might be able to pick it up and confirm it with a subject matter expert before it gets developed. He or she might perhaps get annoyed because you bought them again with the same questions, but that will be the end of it. However, imagine if nobody was able to pick it up and it goes straight to development. It then gets presented to your stakeholders who of course won't be very happy because it's not what the expected. I can tell you that they will be very angry with you at best. And you can't really resent them for because of it's, because development is something that's costly. And also developers have a limited capacity. There could have been working on something else, but instead they will have to do rework and cause delays in other projects. So quite a chain reaction. Key message here is to always take the time to confirm your understanding. It can't spare you a lot of headaches down the line. 17. Confirming - techniques: There are two ways to confirm your understanding. The first way is to check the information you collected with the expert from who you got information from in the first place. The second way is to cross-check the information with a different source. You can of course, combine both approaches to create even more certainty. As I just mentioned, in the first approach, you will check the information with the initial source. There are two moments to confirm your understanding during the elicitation and after DLC taken. During the elicitation, you can apply active listening techniques such as paraphrasing and follow-up questions. With paraphrasing, in fact, you will reiterate what the person said, but you will use your own words. You will quickly notice that you can't properly paraphrase without actually understanding the information that you collected. On top of that, paraphrasing has a few additional advantages. It gives you an opportunity for stakeholders to correct your understanding. It shows two stakeholders that you have been listening actively and attentively to what they said. And you will notice that people often feel valued when you listen to them. And as a result, you're able to create a positive bond, which is always good to have. Finally, it gives you a small break to digest information and documented properly in your notes. Another technique with the same advantages is asking follow-up questions. You might also be able to uncover more information when compared to paraphrasing. These were some of the techniques that you can apply during the elicitation session. But you can also apply something after the visitation session to confirm your understanding by sharing your meeting notes with the stakeholders. The default, the advantages of doing that is that it gives stakeholders the opportunity to reflect on what was said during the meeting. And it can also correct your notes if necessary. Meeting notes can also be used as a validation tool. If stakeholders don't react to your meeting minutes or to a meeting notes, then you can assume that they agree and does also provide their validation. Validation component is quite important as you can consider your meeting minutes or notes to be your shield against stakeholders who tend to change their mind. Unfortunately, it often happens that stakeholders don't agree with information that you collected from them while they did validated during the recitation session sometime ago. It's not a nice situation to be in. But luckily, your meeting notes are your ticket out of that situation because you can confront your stakeholders with it. The information might still get corrected. It at least you won't take the blame for it. You can tell that this happened to me a few times. I have to say there was always happy to pull out my trusty meeting minutes. Another advantage of taking meeting minutes is that it can serve as input to your analysis requirements. Later on. You can simply add the meeting minutes to your documentation and is still the requirements from it. In summary, taking meeting notes can be quite a high efforts activity as you have to listen, understand type, structure, paraphrase, and ask follow-up questions all at the same time. But with enough practice, you will eventually get there. It's also a great mental exercise. Moving on now to the second approach, checking the information with other sources. As you do more recitation, you will be able to link information coming from different sources and check whether it all adds up. Most inconstant inconsistencies are often found by cross-checking the information coming from different sources. These inconsistencies have to be discussed and resolved with the owners of the conflicting information. There are some ways to crosscheck information with different sources. First, I would run the same elicitation session multiple times with one or two stakeholders. That way I can incorporate contradictions or Philip information gaps. Another way is to cross-check the information you elicited with any documentation that you might have collected in the past. Think of emails, requirement documents, user manuals, existing interfaces, enterprise documents, reports, etc, etc. Water. This concludes the section on confirming your understanding. In the next section, we will cover how to communicate your elicitation results to your stakeholders. I hope to see you there. Bye. 18. Communication - introduction: Hi and welcome back. In this section we will focus on the last step of requirements elicitation, which is communicating your results to your stakeholders. I will first explain what it is and why we need to communicate the elicitation results. And then I'll go a bit deeper into the building blocks of the communication. Why do we need to communicate or elicitation results? It ensures that stakeholders have a shared understanding of the information that was collected and that there are no disagreements left. In a way, you're educating your stakeholders on what you've learned. This is really your time to shine as a teacher. The way you communicate also has to be considered. Remember, the ultimate goal is to make sure that your stakeholders understand the message. The way you convey that message has to support the goal bead via email, information sessions, presentations, status reports, etc. It's very likely that you may need to adapt your message and the way you deliver that message to different groups of stakeholders. Communicating the elicitation results consists of four building blocks, being communication objective, the content of your message, that communication container, and the communication platform. 19. Communication - objective: When we look at the first building block, the communication objective, you should first establish the reason of why you want to communicate to your stakeholders. There are two types of objectives, which are for status and for approval. Within the force Status Objective, you want to inform the stakeholders in order to receive feedback and reorientation if necessary. Subtopics might want to, you might want to do an update on such as the project's scope, the results of the elicitation sessions, the planning, the alone, the alignment with the strategy, the alignment are two regulations or departments, etc, etc. Within the for approval objective, you expected decision from your stakeholders. You might want to receive an approval before moving to the next stage of your analysis, or you want to receive a decision regarding some options that presented themselves during the elicitation sessions. Little trick, when I give a presentation, I will always mention what I expect from my stakeholders. It's a good practice to state your objective in the meeting invitation at the beginning of your presentation and also at the end. 20. Communication - content: The second building block is about the content of your message. The content of your message changes in function of multiple factors, which are your audience information needs, the level of maturity of your audience, and the amount of time that you have allocated. Let's take a closer look at the audience information needs. You need to adapt the content of your communication to meet those needs. Here are a couple of scenarios to illustrate a bit better. What I mean, say that you want to give a presentation to management and then you need to put yourself, it's important to put yourself in their shoes and think of what information they might be interested in. Management will often know what the business cases, what the alignment is with the strategy of the company? What is the planning? What is the competition doing? Is there a needs? Is there a need for their support to increase collaboration with other departments, etc. On the other side, imagine that you give the same presentation to, let's say developers, they might be more interested in knowing what the technical impacts are, what the dependencies are with existing IT components are new components. What is the complexity of the services behind the screens? What is the process to develop it, et cetera, et cetera. Now, taking the same presentation to, let's say, more operational teams, they will again have different lens and needs, such as they want to know who to contact person who says something goes wrong, what is the volume of users? What is the exact process to follow? Marketing teams also have different information needs. They might want to know what he competitive advantages. They want to know what the customer needs is that we're going to answer or solve. They want to see how it fits with the value proposition and with the other products that are being offered today. What I'm trying to say with all these examples is that each group of stakeholders, each audience has a different lens to look at your elicitation results. And it's your job to make sure that you adapt your communication to fit their lens. Another factor to account for is the level of maturity of your audience. How much do they know about your topic? The level of contexts in detail that you need to give depends on the origins level of maturity. If your audience is very well informed about your topic, you might want to skip ahead and directly go through the details of your presentation. When I see new stakeholders in the meeting, I always ask if everybody is familiar with the topic. If not, I will first give some more context before going into the subject of the meeting. If your audience happens to not be very matured, then you often need to explain why this project was needed. You need to do sort of Z move. So you move forward with a certain group of people, but you also need to take a step back to bring another group of people forward as well. You make a z. Also something to think of is how much time you have to present. Try to adapt your presentation IF function of the amount of time that you have. If you only have, let's say 30 minutes, then you need to get to the core of the discussion quite quickly. So sending information prior to the meeting doesn't hurt. I would also not go over all the content, but I'll mention that they can access more contents in the rest of the documentation if they want to. They can always refer back to me if they have questions. If you have, let's say one hour or two hours, then you can take your time to introduce the subject. I explained it in bit more detail. 21. Communication - container: Moving on now to the third building block, the communication container or formats. Here you need to reflect on how you will wrap your elicitation results and community communicated to your stakeholders. There are many options out there, but I will cover the three most important ones. You have. The presentation, often via PowerPoints. This format is used to deliver a compelling story around the topic. You really focus on the key points that matter to the stakeholders. Try to avoid going too much into details only go whenever asked, are requested. Because this is something that the stakeholders can also do on the room if they want to. You have also another format called formal documentation. Here you follow a fixed template provided by the organization. This is often the case for architectural documents or strategic lending options or business requirement documents. The last one is informal documentation formats. This is often used for documentation or this often changing or being updated, such as diagrams, models, business requirements, drafts, meeting minutes, etc. 22. Communication - platform: The last elements you need to think about when communicating is the platform of your presentation. This answers the question of where you will present your elicitation. Again, there are many possible settings, but I believe that it's best to focus on the tree main ones, which are grouped platforms, individual platforms, and nonverbal platforms. In a group platform, you will present your results to multiple stakeholders at the same time. Now, what are some of the advantages you get to when presenting to a group? First, you automatically capture a lot of feedback and validations with relevant stakeholders in one session. There is also cool constructions with multiple stakeholders that also increases the quality of the feedback you receive. Moreover, it creates credibility and buy-in for later, if the meeting was to success. After you've received an approval in these types of meetings, you can use it as a kind of batch which you can stick on the project. It means that your project has become officially recognized within the organization. It has become the real deal. You might even notice that some stakeholders are no more open to helping you because they know that there is momentum and management support behind your project. Where there are pros, they often are counts. Group platforms can be difficult to organize, especially if the group is quite large. It also depends on what type of people aren't being invited to the group. Business people tend to have lots of meetings while IT people are easier to meet with, but you don't want to bother them too much unless it's really necessary. Quite a predicament. Luckily, in large organizations you often have steering committees, also known as TO Coase. These are recurring validation meetings where all the necessary stakeholders are present. The only thing you have to do is to pick your topic on the agenda and go ahead and present it. Also another con is to do pre alignments with all the participants. It is unnecessary evil in larger organizations. When you want to present your results to a large group, you should already concert with all the members on an individual, individual basis and to get your approval before the meeting starts. The reason for this is to avoid a collective loss of confidence in your project. Imagine you present your results to a group without meeting with everybody individually. It's quite possible that one of the stakeholders completely disagrees with what you are presenting. This could negatively affects other stakeholders opinion. They might lose confidence in the project and cause a reprioritization. You can anticipate and avoid this by checking with everybody beforehand. Another con, of presenting to a group is that it often requires a lot of preparation and it's always valuable. Often this is a problem in larger organizations where a lot of effort is spent on getting everybody to face the same direction. Its life turning a large cruise ship, it simply takes time, but once it's launched and turns, it's quite hard to stop switching now to the individual platform. In here, you present your results to just one person who has the mandate to make decisions on their own about certain topics. What are some of the pros? You can go into more detail with that person. It's easier to organize because you just need one person to accept. And finally, it creates a bond with that person. This is all sounds nice, but what are the cons? It can be quite time-consuming if you have multiple stakeholders that you want to meet. There is also no co-construction, and there is also no large-scale buy-in. And you only get to them as its amount of feedback. Finishing off. Now with the nonverbal platform, here you present information to a report, an email and memo, etc., something written. This information should stand on its own and doesn't require any voiceover. What are the pros? It's low effort considering that your stakeholders have a high level of maturity. If not, you might need to add more explanation to your document in order to avoid Ms comprehension. It can also be used as input for your analysis. Looking now at a cold site, nonverbal platforms and not always ideal to receive immediate validations. You often need to chase people to get a written approval. Your stakeholders are somites not interpret your elicitation results correctly and thus make wrong assumptions. This is quite problematic as you might not even be able to act on it because you don't even know these wrong assumptions were made. The last one is that people tend to be lazy and they might not go through every detail of your documents. This concludes the part on elicitation communication. You should now be ready to tackle your first requirements elicitation activity. In the next section, you'll be able to test your skills through a project. I hope to see you there. Bye. 23. Project Intro: Hi, and welcome back. In this section, I will introduce a project you can work on to apply the skills you've learned throughout a course. For those who are already doing elicitation activities as a business analyst, a product manager, a UX designer, etc. I strongly encourage you to apply what you've learned in your professional environment. Doing so will not only solidify your knowledge, but also see if you can improve some of your existing workflows already. Plus there is the added bonus of showing off those skills to your colleagues. For those who are not yet involved in requirements elicitation activities, I created a project for you which I believe you will find quite fun. From now on, you are the lucky organizer of a holiday trip with your best friends and or family. The goal is to closely simulate in the dissertation experience in a safe environment where you're allowed to make errors and to learn from them. However, don't worry, you do not actually have to go on a trip, but it would be nice if you did organize and do the trip in the end. In any case, let me know how twins, I'm quite curious. Now, maybe you might ask the question why organizing a holiday trip is a good target practice? Well, it's a perfect storm for elicitation, as you will deal with multiple stakeholders like your friends and family, who are likely to all have different needs and wants when it comes to holidays. Also, the way you collect information has to be considered given that people tend to influence each other's decisions. At the end of the project, you will have plenty of elicitation activity conducted multiple lists elicitation sessions using different techniques, confirmed your understanding and communicated your elicitation results in the right format to your friends and family. Before you randomly start calling people, perhaps you might first want to have a look at some of the steps I've listed here. They will guide you on how to approach your stakeholders. And just to set the scene a bit more, just unpause the video when you're done reading them. Okay, The last disclaimer I want to give you before we start as the following. In this project, we will only cover the elicitation part. It's not to go to analyze results and to come up with your dream trip. As this is outside the scope of this course. In order to find a dream trip, you would need to do requirements analysis and also solution analysis to very interesting topics that are definitely plan to cover in other courses. But in this case, let's just keep it to collecting information which is already sufficient. Of course, nothing holds you back if you want to move further. 24. Project guidance part 1: Okay, now that that's out of the way, I will give you some tips and tricks on how to start your project. First, you should apply the four-step approach, starting with planning your elicitation. During this step, you will have to define the scope, the site under techniques and sort out the practicalities. When you define the scope of elicitation, you should first think about the objectives or deliverables of your elicitation. In other words, what information do you want to receive from your stakeholders? In case of a trip, you could ask about the availability of your stakeholders. What are their budget constraints? Do they prefer hotels or campaigns or hiking? What type of trips to delight in the past? Who do they want to go on a trip width, or who they do not want to go on a trip with? Are they afraid of planes or other transportation means? They have some food allergies. Do they have some hidden disability you might want to take into account, etc, etc. On top of the deliverables should also ask yourself whether there are any prerequisites that you should need to know prior to doing the elicitation sessions. In the case of a trip, you could just document the information that you already have on the different participants. You could see it as creating a sort of summary card or a trade card. Some of the things that could go on that guard, our family, family name, name, relationships, gender, language, age, children, hobbies, likes, dislikes, favorite food, etc. Another aspect you need to consider in your scope is you yourself as the solicitor. Are you comfortable doing elicitation activities, other questions you could ask yourself or do you already have experience in organizing trips or similar events? Are you comfortable to socially interact with people? Are you comfortable to take up a leading role in organizing and trip? Moving on now to the stakeholder next to the information you have on them, you should also try to figure out the following. Are certain stakeholders more difficult to approach or to manage than others? Do some stakeholders require more care? And patients, think of all the people who might perhaps, who are not used to doing these type of exercises, they might require a bit more explanation. Do your stakeholders possess the right type of maturity for certain elicitation sessions or do they require some additional education? Make sure to not forget about anybody in your elicitation. You should of course, consult the participants that will go with you on the trip. But you should also think about the people that are not going but which are impacted by you going. Think about cleaning personnel, the babysitter doctor appointments that might need to be moved. These are people that have to be informed at least. Now please. If you plan to keep this project on the other stage of an exercise, don't actually call these people and cancel your appointments. I wouldn't want you to miss any next step. You might also want to consider how shy or introverted your stakeholders are. These stakeholders tend to keep information to themselves, especially in group settings. As a facilitator, it's your responsibility to gather everyone's feedback. Hence why it's important to make sure that everyone gets a voice. Also the ones that prefer to remain silent, but might have very good suggestions. Not a point to consider is the level of influence that stakeholders have over others. As facilitator, you want to avoid to have an elicitation results that only reflects what's one strong-willed stakeholders set, chances are that other stakeholders might not agree. Finally, what is the level of involvement required of a certain stakeholder? Do they just need to be informed? Think of the babysitter? Or do they need to be heavily involved? Think of your participants. Should provide you with a very solid scope for your recitation plan. Now, you will need to choose the most appropriate elicitation technique. First, you need to consider what's the best way to approach your stakeholders and get their needs. This depends on the scope of your dissertation, the cost, timing constraints, the availability of your stakeholders, etc, etc. Personally, I would plan the elicitation activity as follows. First, I would do my own research. Where do I want to go on a trip? That way I built empathy with the participants when I'm collecting needs and I'm able to better understand them, then I would interview everybody, everybody individually to collect their needs. That way they can speak openly without being influenced by others. Note that everyone doesn't only include the people that will go on, on a holiday with you, but you should also consider the ones that are impacted and not coming with you. Later. I would in the communication part, I will present the findings of the individual interviews with all participants and discuss altogether. Last but not least, take the elicitation practicalities into account. Think back on the problems that I listed in the course with regard to IT, location or organizational problems. And make sure that you're well-prepared for them. 25. Project guidance part 2: Right, step two, you elicitation plan is ready and now you're about to go on the field to conduct your elicitation magic. The tip that I can give are as follows. Don't hesitate to, again go through the difference pros and cons of the elicitation techniques, especially the ones that you've chosen. Also have a look at how to execute his techniques properly and revisit the best practices. Make sure to be there on time and prepared. Have your plan in your mind. Don't forget to take notes or record a session. Always repeat the context of the elicitation session as well. There's already this is already done a step treat, but don't hesitate to confirm your understanding with paraphrasing and follow-up questions whenever necessary. Great. You don't conduct in your recitation sessions and are now about to start step treat while you want to confirm your understanding. Here, I would simply share the meeting nodes with the person and ask if they could correct or enrich if needed. Also tried to search for inconsistencies in the information that you collected. To give an example, imagine that a good friend of yours said that he knew about certain travel restrictions to go to Belgium. And it might not be a good idea to go over there. Very nice country to go to, by the way. It's always good to fact check this with other sources of information to make sure that this is correct. You could check it with the official website from the Belgian government, for instance. The final step is to communicate your elicitation results with your stakeholders. During this step, you will have to define the communication objective, the content of the message, the communication container, and the communication platform. Starting off with the communication objective. Before actually communicating, you should first define why you want to communicate. What are you, what are you expecting from your stakeholders? Remember, there are two options you had for status and for approval. Personally, I would immediately go for approval of the elicitation results. You expect your stakeholders to approve the needs that were identified during the elicitation sessions and also acknowledged the constraints. Moving on now to the content of your message, you need to keep in mind what information needs are. If urologists, I assume that your friends and family will want to know more on wherever you want, wants to go, how long your trip is going to be, when the trip would take place, who's coming, how to get there, how much it can cost, what activities would be plans, etc. Knowing your stakeholder information needs will shape the content of your message. Also, consider your audience level of maturity and how much time you have to present. Next up is about defining the communication container. You need to think of what format you want to bring your elicitation results. Remember that we identified three types of containers. Presentations, formal documentation and informal documentation. Personally, I'm a big fan of fancy PowerPoint presentation. I'd go with that option, but really it's up to you. And lastly, the communication platform. You need to establish whether you will communicate the results via a group platform and individual platform or a non-verbal platform. It of course depends on how many participants they are. But if it's a group, I would suggest to go with a group platform. That way you get everybody's feedback all at the same time. Follow. That should be about it for the requirements elicitation project. The only thing that's I still have to do is to wish you good luck and have fun. I will see you in the next section where we will wrap up the course. See you there. Bye. 26. Conclusion and key takeaways: Congratulations for finishing the course. You can tap yourself on the back. You deserved it. Before leaving you, I just wanted to wrap up with three key takeaways. The first one being, whenever you collect information to solve a problem, remember to use the four elicitation steps, which are to plan, conduct, confirm, and to communicate your elicitation results. This will stretch through your approach and it shows professionalism to your clients. The second takeaway is that there is not a one-size-fits-all recitation technique. There are three categories and each category has its pros and cons. Here's a small reminder. The collaborative elicitation you have, interviewing, brainstorming workshops, Documentation Review and analyzing existing interfaces. In the research category, you have surveys and analysis of historical data. And the experimental category you have prototyping combined with user testing. And a third takeaway is, it's always important to confirm your understanding. This has many benefits, such as affording miscommunications or wrong requirements. And it also enables you to gain trust. Also makes sure to always communicate openly about your elicitation results. You can't do anything wrong by communicating openly. Even on the contrary, your stakeholders will thank you for it by being transparent. And I still have one more bonus takeaway, which is to relax and do something fun. Indeed, it's now time to give your brain a break and do something else because now you have to solidify your knowledge and make it stick longer. Don't forget to also revisit your summary from time to time. Now, that's all from me. I sincerely hope that I was able to teach you something valuable in any case, let me know by leaving a review at the end of further course, I would greatly appreciate it as it enables me to improve as well. The last thing that remains me, or for me to do is to wish you a wonderful and educational day. Bye. 27. Share your thoughts!: Hi TiVo here. Congratulations for finishing the course. I hope you got something out of it and it will be helpful in your future career. In case you'd like to course, please leave a review and let others know what you liked about it. That seems extremely helpful to me and it's also helpful for other students. Now, if I go have a nice and educational day, Bye.