So we're going to be covering chapter four, which is elicitation, and collaboration. And to me, I think that this is where all the fun happens. Because this is where we're actually collaborating with the stakeholders. And you know, getting to know people when starting to build those relationships. So basically, in elicitation, and collaboration, you're basically obtaining information and confirming the results. And this is basically something that we're going to have to transform into actual business requirements later down the line.

One thing that's important to note is the difference between elicit eliciting requirements and gathering requirements. I think in a practical setting, many of us refer to gathering requirements which is really just collecting information, whereas elicitation is actually drawing forth information and receiving it from stakeholders and other sources. And it's also considered to be the main path towards discovering requirements and design. So the biggest difference between gathering requirements and eliciting requirements is that gathering is just taking what people are giving you and compiling it. Whereas eliciting requirements is you're actually pulling out information, asking smart, relevant questions in order to help the stakeholders think about things a little bit differently. And so listening might involve talking to stakeholders directly doing some research or experimenting, or simply being handed information.

One thing to note is that collaboration itself is the act of two people working together towards a common goal. One thing that bad luck reiterates is that elicitation and collaboration is not a phase. So it's not like a part of the sdlc phase where there's analysis and design phase and things like that. eliciting requirements is iterative. So you do it. It's ongoing as as needed, basically.

And it could really be planned or unplanned or both, maybe a combination of both. A lot of the times if something's not planned, you go back and plan some type of event around it, so that you can present it as a requirement later on. And sometimes Yeah, that's what I just said. So basically, sometimes, you know, an unplanned activity can transition into a planned activity for deeper exploration. So we've got five tasks that are a part of elicitation and collaboration, and that includes preparing for elicitation conducting elicitation confirm elicitation results, communicate business analysis, information, and manage stakeholder requirements and For those of you who may have had like the, I think the watermark study guide, they use a mnemonic called PC four. So you've got your your P and your four C's.

So the fourth seat is the collaboration here. So you've got prepare, and then your four C's here. So, preparing for elicitation basically involves ensuring that the stakeholders have the information they need to provide to you and also understand the nature of the activities that are going to happen during the elicitation or doing the elicitation exercises. Conducting elicitation is actually where we're doing the work right. So here is where we're actually trying to understand the needs and identify potential solutions that meet the needs of the stakeholders. And then confirming the results is making sure that the stakeholders and us have a shared understanding of the outcomes of the elicitation and that the information is recorded appropriately and is correct.

Many cases this might be comparing information from other with other information, right? So I might compare information from a stakeholder and then look at some type of document analysis or something of that nature. And then we're going to communicate the information back. So we're going to be communicating business analysis information, where we're providing stakeholders with the information they need at the time that they need it. And then managing stakeholder collaborations is basically working with the stakeholders and engaging them in the overall business analysis process. And we talked about the business analysis core concept model during week one, so we don't need to go for that.

So for this knowledge area, You have four needs, including needs, Business Analysis information, stakeholder engagement approach and your business analysis performance assessment. Now, again, these are the inputs for the entire knowledge area, not a specific tasks. And so these are your five tasks here. And you've got outputs including elicitation activity plan. unconfirmed elicitation results, confirm elicitation results, Business Analysis information that's communicated, and then general stakeholder engagement. Right.

Alright, so for our first task is preparing for invitation. So generally bad Bach, you know, they like you to prepare for things, which is, I mean, a good practice in a practical setting as well. But specifically in bad box, it's general consensus that you're going to want to prepare for things before you actually do them. So the purpose of preparing for this rotation is to actually understand the scope of the elicitation activity, as well as selecting the appropriate techniques and planning the appropriate supporting material, right. So you're not just planning the process, you got to make sure you have all the equipment you need, right? So is there a room available?

Do I need a screen or something like that, or different tools to help make the elicitation activity more productive? And so the general description of preparing for elicitation is basically defining the desired outcomes, right? So you always want to go into things with an actual outcome, knowing what the end result should be. And then considering the actual stakeholders involved, and what the goals are that you're going to meet for that particular those particular activities. So this might include you know, determining Which work products or deliverables, what work product is basically another term for a deliverable that's going to be produced when you're using the elicitation results and also which techniques are best suited for that particular in order to get a particular result. And so, the inputs for preparing for elicitation are your needs and your stakeholder engagement.

So, your needs are good to know because you know, elicitation is the purpose of it is to discover the needs. So, I thought this is an important statement because you do need to start with some form of a need in mind even though you are working towards discovering some need, but you have to have a general overall understanding of what the need is in order to effectively create and plan out elicitation activities. So your output is going to be your elicitation plan. So your elements include understanding the scope of elicitation. Right? So what's our outcomes gonna be gonna be, you know, who's involved, things like that.

So, you're basically gonna be determining the type of business analysis information that you're going to be trying to discover. Right? So which questions are you going to be asking who's going to be involved, and the techniques that might be used? So you're usually going to consider all of these things the business domain, the corporate culture, or the environment? The stakeholder locations, right? Are we all in one building?

Are we different states or different countries? stakeholders who are involved and the group dynamics right, so do we have people on the project team that have a little more authority than others? Um, we talked about the expected outcomes, the skills of the BA right so generally more seasoned MBAs are Are, we have a larger tool belt than maybe a novice or a newer business analyst. So we have to take that in consideration as well. A lot of times you'll see less seasoned DBAs prepare with more seasoned MBAs, you know, to achieve a particular goal, and then other elicitation activities that are planned that actually complement this one. So some elicitation activities serve as an input to others, or they might just complement each other once they're both complete.

You also want to consider your strategy or solution approach, right? So what's our overall goal and what steps are we going to outline throughout the process, and then the scope of the feature solution, and then possible sources of business analysis information, right, so and so some of this might be again, documents people, information from the market, things like that. Our next element is selecting elicitation techniques. So Oh, no, I'm sorry, this is not our next element. This is a part of our Oh, no, I'm sorry. Yeah, this is the next element.

So select elicitation techniques. So a general rule is that multiple techniques can be used during elicitation activities. Because babic is flexible, there's never just one way of doing something, it always depends on the content, the context I'm sorry, and it also depends on the cost and the time constraints right. And then the type of business analysis information sources that are available, and also the corporate culture and the desired outcomes. So you always want to consider techniques that are commonly used for The type of situation that you're in right now, um, and techniques that might be specifically suited for situations right. So for those of you who follow me on social media, I always give you guys you know, different techniques that you can learn and understand what they're good for.

So bad luck expects the same thing. And then the tasks needed in order to prepare, execute and complete each technique. And so we know that things change, right? Because a lot of situations can change over time. Sometimes your business analysis approach may need to be adjusted and you may need to switch to more appropriate techniques. Okay, our third element is setting up the logistics.

So logistics are basically you know, setting up the meetings, activity goals, who's going to participate with the roles are going to be the same Schedule resources right? So the people the rooms, the tools, the locations, communication channel, right? Is it going to be live? Or are we going to have to do something remote for the people that are in another state? Which techniques are we going to be using and different languages? So is it going to be oral or written.

And also creating agenda is always a good idea whenever you are facilitating or leading the discussion, be sure to create an agenda so that people know why they are meeting and what the expected outcome is going to be for that activity. And even if you are invited to a meeting without an agenda, and you're not facilitating it, sometimes I like to go ahead and just ask whoever the sender or the organizer is if they have an agenda and then secure supporting material. So sometimes, you know many organizations you have to share material or Share equipment. So you want to make sure you get your material early. And you want to identify the sources of information that's needed. Because sometimes, you know, that's going to include people's systems and historical data, materials and documents.

And a lot of times people or stakeholders need to prepare or do research before they can offer good or relevant or up to date information. So you don't want to just catch people off guard, you want to prepare them by letting them know what the outcomes are so that they can get the information they need in order to be a good resource for you during the elicitation activities. And so, when we talk about documents, some of those documents could be could be, you know, existing system documents, or business rules, policies, regulations, or contracts that might be impacting the solution or the solution activities. And then preparing stakeholders. So this is a lot about what I just talked About earlier is making sure that the stakeholders have what they need, but also educating stakeholders when needed on how a specific elicitation activity works, right. So, if you guys are doing some type of collaborative game or a survey or something of that nature, sometimes you have to just break it down a little bit so that everybody's on the same page.

And there's a shared understanding on what the expectation is from all of the stakeholders. And this is just saying that some stakeholders may be unresponsive or challenging if they feel that it's not aligned with their individual objective. So you want to let the stakeholders know how their objective is aligned with the overall objective of the activities. And it's usually a good rule of thumb to have some, you know, give stakeholders time to review Any supporting material prior to the elicitation activity, sometimes you know, it's good to give them a 24 hour notice, whenever you do expect them to do some prior research before the activity. And of course, elicitation can also be driven through research or exploration done solo, or by yourself. guidelines and tools, your business analysis approach, right, everything is kind of falling underneath that your business objectives, your existing business analysis information, we talked about that that might be a source of, you know, your supporting material.

And then the potential value is basically the value that's going to be realized from this particular event, and how it's going to be contributing to the future state. We've got several techniques. that you can use for preparing for elicitation. Some of the ones I just highlighted are just the ones that are really important. So a document analysis is a really good way to prepare for elicitation. Because it's used to.

Sometimes it can help you identify sources of information or even people that might be involved for a particular elicitation activity. And also interviews is a pretty common way of eliciting requirements. But it's also a good way to identify some of the concerns or the planning events that need to be accounted for when you're arranging or coordinating these events. And then also, you always want to reference your stakeholder maps list and personas because that's going to determine, you know, who needs to be consulted with during the elicitation so you're going to need to know Who to invite to these actual activities. Stakeholders might include your subject matter expert, of course, we need them because they might also help us arrange, you know, research or identify people who might be involved in the elicitation activities, but they also might help arrange research experiments, and they may help you know, with some of the facilitation of the activities, and then the project manager always wants to help make sure that the people and the resources are available.

And then your sponsor can has the authority to approve or deny plan elicitation events. And so your elicitation activity plan is a it is a document so it's basically what we're going to use for every elicitation activity. So it's going to basically plan out the logistics, the scope of the activities. The techniques and any supporting material. So that's kind of like your little mini project plan. But it's basically focused around the elicitation activities.

So now we're looking at conducting elicitation. So this is where we're actually drawing out exploring and identifying information that's relevant to the change relevant to the solution or the needs. So babba states that there's three key types of elicitation types. So there's collaborative, right, so this is the most common so this involves direct interaction with stakeholders and relies on their experience, expertise and judgment. And then there's research which might involve some type of studying information, we might be looking at different materials or documents, or sources that may or may not be known to the stakeholders involved in that change. And then we have accepted elements, which include some type of observable, observational study, or in most cases, when we're talking about experiments, we're talking about proof of concepts or prototypes.

So proof of concepts is a really good tool when we're in something that's a project or a initiative that's very new to us. And that we don't necessarily know what the Outlook or the outcome is going to be. So proof of concept will help us know whether or not it's actually feasible and doable. And then we might combine one or more of these types of elicitation types, we're actually doing our conducting. So our input is actually the output from the last task. So our input is going to be our elicitation activity plan to guide us.

And then our output is going to be the elicitation results. So we went Make sure that we're documenting what's happening. Alright, so our first element is God elicitation activity. So this is basically done in order to help facilitate towards the expected outcomes, so we want to make sure that the goals and agendas are clear. We want to know what the scope of the change is, what forms of output, what outputs will be generated by this activity, what other presentations and activities, this particular elicitation activity will support and how the output integrates with other information that's already known, who provides the information who will use the information and how the information will be used. This is actually a pretty important one So whenever you're producing something, you always want to consider how other people are going to use it.

And so we use this information to basically determine when we have enough information in order to stop the activity and move on to the next event. And then your next element is actually capturing the elicitation outcomes. So, this might be an iterative process that takes place in a series of sessions in parallel or in some type of sequence. So, basically, it goes according to the scope of elicitation how we should be documenting that and communicating that. So this is to help ensure that the information produced during the activities is properly recorded for future reference, right because, as the as we know that the much of the elicitation results and outcomes is going to transition into requirement. But some of it might just be inputs into a requirement as well.

So your guidelines and tools are your business analysis approach, existing business analysis information, right. So this may help guide some of the questions to the elicitation activity plan that we have, and the approach to draw out the information from various stakeholders. Your stick our engagement approach, and then supporting materials are also guidelines as well. And there are various techniques you can use to actually conduct elicitation. Just we know that interviews, surveys and questionnaires and workshops are very common techniques. And also collaborative games might be used in order to understand a problem and stimulate some type of creativity or if you need to build some type of trust or have Some type of icebreaker, a collaborative game is also a good tool for that.

Again, interviews is used to uncover need surveys is good when you have a large group of people and need to get a lot of information quick or it's also good when you have a lot of people in different locations. And you need to get information in a short period of time. And then workshop is good when you're trying to get a consensus or you're trying to get approval facilitate it right away. And our stakeholders, our customers and domains subject matter expert in end user so we know what we'll be doing with them is right getting information. Um, but I wanted to highlight a couple others is that the implementation subject matter expert, like I talked about earlier, this is a very technical role and they're also they usually, I'm concerned with implementation costs and design and things like that. But we might involve them in the conduct in the elicitation activities, because they're going to be concerned with the designs and implementation aspects of it.

Right, there might be specific areas of expertise that they have that we need to consider by asking, you know, clarifying questions and things like that. And then any stakeholder could really have relevant knowledge or experience to participate in, you know, elicitation activities. So confirming elicitation results, we might, you know, bump information up against multiple people in order to make sure that everybody has the shared understanding and the same story and things like that. And so your outcome for confirm elicitation results is going to be I'm sorry, your outcome for Conducting elicitation results is going to be unconfirmed elicitation results. So these are just, this is just the the results of the elicitation activities that we've documented and recorded at this time. So it's basically in whatever format that the specific activity was in.

So our next task for elicitation and collaboration is confirm elicitation results. So we've prepared for this notation and we've conducted the elicitation. Now we want to confirm our elicitation results. So this is to check the information gathered during elicitation session for accuracy and consistency with other information. So I talked a little bit about that earlier that we want to identify any problems and resolve them early. By checking for errors, omissions, conflicts or empty guity, buy one sing the information that we record it back to the stakeholders that were involved in the elicitation activities and say, hey, did I record this correctly?

Are we all on the same page. And also, you want to compare that information against the original source and other elicitation results in order to make sure that everything is consistent with one another. And so your inputs, again is the output from the last task, your input is going to be your unconfirmed elicitation results. Then we're going to go through the elicit the confirming elicitation results process, and our output is going to be confirmed elicitation results. So this one is pretty straightforward as far as inputs and outputs. We've only got two elements here, which is actually comparing the results against the source information.

So compared to against the source information is basically comparing it going back to The person or the stakeholder or the source, that you've got the information just to make sure that the information is correct. And then sometimes you can give it to them independently, right, they might just send it back to them in an email and they'll just go through it and make sure that everything looks good, or you can have a follow up session. And then your next element is comparing the elicitation results against other elicitation results. So this is again might be confirming the information up against multiple different activities, right. So if I have two or three elicitation activities, making sure that all of the information was consistent with one another, or you might be comparing it against documents or various stakeholders. Sir guidelines and tools are your elicitation activity plan and any existing information that we consider business analysis information.

So, again, this is any information that can be used to develop additional questions or draw out more detailed information. Some good techniques to use for confirming elicitation results might be a document analysis, interviews, reviews or workshops. So your reviews of workshops are a lot of the same, or you can do something independent and have an interview with someone. But again, if you're if you are, you know, comparing elicitation activity against some type of document information, you can use a document analysis for that. stakeholders, domain subject matter expert is the person that you're going to want to make sure that all of that information from all of the stakeholders looks correct. And then any stakeholder that provided information can assist with confirming that information.

Alright, so your output is going to be confirmed elicitation results. So this is just going to be a collective output. I'm basically confirming that all the stakeholders agree that the results correctly reflects the captured information. Alright, so we have paired, elicit for elicitation conducted elicitation, we've confirmed elicitation. Now it's time for us to communicate that information back to the stakeholders. So the purpose of communicate business analysis information is to make sure that all of the stakeholders have a shared understanding of the business analysis information that talks a lot about shared understanding.

And so we're basically going to be communicating the appropriate information to the stakeholders at the right Time and in particular formats that meet the needs of the stakeholders, right? So this is expressing the information in the language, tone and style that's appropriate to the audience. We again need we need to determine who the recipients are the content that's important to them. The purpose of the documents, we're going to be sending the context and what we want the outcome to be, how are they going to use this information. And so as the as we need to engage the stakeholders to ensure that they understand the information and a lot of times we have to make sure that they're getting we are seeking to gain some type of agreement or approval. And this might take multiple forms of communication.

We are basically we would have to send out information the same piece of information multiple times in different ways in order to communicate something specific to a particular group or audience. We'll talk about that a little for a little later down the line, we'll be talking about views. And so your inputs for communicating business analysis information is actual business analysis information, and then your stakeholder engagement approach. And then your output is going to be more of a state, which is business analysis information that is actually communicated. So your first element is actually going to be determining your objectives and the format of communication. So there's various packages of communication and reasons that we might send them but some of those reasons might be to communicate requirements and designs or to get some type of assessment for quality and planning.

We might want to be start the evaluation of Different solution alternatives, or maybe have some type of formal review process if we're more formal or more predictive. We can also we also communicate this information, what we're looking at, to distribute requirements as an input to solution designs or if there's some type of contractual or regulatory obligation that we need to meet. And also to maintain requirements for reuse. So, if we know people are going to be using them for other reasons, we want to communicate that business analysis information as well. All right, so some of the things that we want to consider when we are presenting information is, who the audience is, and then the type of The information that they need, right what they understand and what they need to understand. In our business analysis approach, we have what's called this communication plan, which talks a little bit about the preferred communication styles of the stakeholders.

And we also want to consider what information is important to those stakeholders. And that's going to drive you know the appropriate level of information, right? Do we want to get to some thing more formal, something more detailed or something more high level? And then how does that information support other materials, right? So if we're providing them information, that's going to be an input to something else, right. Like we mentioned, it might be an input to designs or it might be an input to help higher level executives make a decision.

We need to understand that and consider that. And then again, if there's any regulatory or Contract constraints that we need to consider. So packages might be formally documented or informal, or they might be in presentation form. So, formal documentation would include different templates or organizational standards that might include text matrices and diagrams, whereas informal documentation might include the same, but it just won't be as standardized and this one is a lot more flexible. And this one is a lot more aligned with what you might do in Agile or adaptive processes. And then we have presentations, so presentations are good for delivering high level overviews that are important for understanding goals of a change.

So presentations are usually good for executives who don't really need to get into the details. They just want to know the bottom line and the overall goal and results. And then we're actually communicating that package. So our our second element is communicate the business analysis package. So when we're doing that, we want to provide the, the information to the stakeholders at the appropriate level of detail. Or the appropriate level of abstraction, which we might say, um, using the correct platform.

So, the general platforms that Babcock discusses include group collaboration, right, where we are, where we would have a group of relevant stakeholders at the same time, and we want to send them all the information at the same time to allow for immediate discussion about a particular piece of information. Or we could do individual collaboration where we do send information to one stakeholder at a time in order to gain an individual understanding of something. If you have to specifically cater something to a particular need. You might need to do something in An individual collaborative collaboration approach. And then email is good, I think that's the most effective for me. And things that are a little more mature, that don't require a lot of verbal explanation or discussion around it right if you, the better you are at documented requirements, the less you need to discuss it.

So that's when you can use email or other nonverbal methods. guidelines and tools for communicating business analysis information might be your business analysis approach, right and then the information management approach. So we talked about this when we talked about our planning business analysis information, because this might help determine how the information will be packaged and communicated to stakeholders. So techniques that we might use when we communicating information might be in the form of interviews or interviews again, so when we talk about the individual collaboration, right, we could do that through interviews, reviews, you know, is an opportunity to get feedback or, you know, get adjustments made. A lot of times these are done during a group collaboration or individual. But either way works well.

And then workshop is when we're looking to gain consensus, or provide approvals. And this is usually a more collaborative type of business process information communication. So stakeholders for this would be the end users and the users of course, so we'll be we'll be dealing with them frequently, when we're communicating information as well as our subject matter information. I'm sorry, subject matter expert or domain subject matter expert. We'll be dealing with them quite a bit as also they're going to be confirming most of the work and validating it throughout the change. And also our implementation subject matter expert, testers need to be aware of this information, particularly for testing and design purposes.

But again, any stakeholder who has who's likely to be involved in the initiative at some point should be communicated with at various levels. And then your output is basically just the business analysis information that's actually communicated to the target audience. So we consider information communicated when all of the target stakeholders have reached an understanding of its content and its implications. So this particular task is a little Bit of the outlier from the other tasks. The other tasks deal specifically with the elicitation process. But managing stakeholder collaboration is a little more holistic, but it's just kind of with them for whatever purpose, but the purpose of managing stakeholder collaboration is to encourage stakeholders to work towards a common goal, and and actually to build positive, you know, working relationships.

But we basically do a lot of confirming, to make sure that the right stakeholders participate at the right times, that they're meeting obligations. And also, we start managing the collaboration as soon as we identify the stakeholders, but as new stakeholders come up We have to basically get them caught up to speed and basically do an entire type of analysis as new stakeholders arise. So, for each, you know, stakeholders roles, we want to understand the responsibility influence attitude and authority of that stakeholder. And we also want to consider the fact that all of that information can possibly change or you know, a particular stakeholder can leave the project or the organization. So, we have to accommodate for that as well. So, poor relationships can have very bad impacts on a project.

So, it could also, you know, have detrimental effects on a project or business analysis. So, some of those negative impacts can include failure to provide good or quality information, negative reactions to setbacks. Also, some resistance To change or lack of support, or, you know, just business analysis information be ignored all together. And so as business analysts, we can counteract this information through having strong positive and trusting relationships with the stakeholders. And your inputs are going to be your stakeholder engagement approach, which we talked about earlier and your business analysis performance assessment. I highlighted that here because, um, this could provide some key information about the effectiveness of business analysis task, right.

So, as I mentioned in week, two, you're performing business and office assessment is iterative and ongoing. So it's helpful to keep reviewing that information to basically course correct if you have something with a negative outcome. You can have a chance to fix that before you move on to the next activity. And so again, your inputs are your stakeholder engagement approach and your business analysis, performance assessment. We're going to be managing stakeholder collaboration throughout the entire process. And then your output is stakeholder engagement.

So this isn't exactly a in a tangible deliverable. This is more just like a state like saying engaged stakeholders. So that's not to be confused with your stakeholder engagement plan. Okay. So we've got our three elements, which is gain agreement on commitments. So this is important to us, right?

So if we have things that need to get approved, or we need some feedback, or we need them to be available a certain time, we want to make sure that we identify and get agreement on commitments as early in the initiative as possible. These can be communicated formally or informally depending on the situation. But we just want to make sure that there's a clear expectation of the desired outcome. Sometimes this might involve, you know, effective negotiation, communication and conflict resolution skills. Depending on how, you know, people interact with one another. And then monitoring stakeholder engagement, you always want to make sure that the participants attitudes and performance is either staying the same or increasing and that nothing's declining.

So you want to make sure that the right subject matter experts are participating effectively, and that their attitudes are staying constant, or that they improve and that the results are being confirmed timely, right, because we need that information quickly. And also that the agreements and commitments are being maintained, right. We don't want to put something in our business analysis plan. Then it just falls off the map, right? So we gotta hope, our stakeholders accountable for the commitments that they make. And so some of the risks that we're going to be looking out for is making sure that stakeholders aren't diverted to other work.

So a lot of times if we have competing projects are competing priorities, it can be difficult to, you know, get those stakeholders to meet their commitments, right. So, because, you know, just because they're part of this project, they still have their operational work or their business work to tend to as well. So we want to make sure they don't get to diverted and we also want to make sure that they are providing quality business analysis information, and that delays are not or that approvals are not delayed. And if they are delayed, then we need to, you know, work with them to our best ability to get to get that approval or if not, we need to escalate it. Maybe the project manager or the sponsor, but one thing that rabbit states is that escalation is something that we do as a last resort. We want to always do anything in our own power before we escalate to anyone else.

And then your last task for manage stakeholder collaboration is the actual collaboration, right? So genuine collaboration usually involves the stakeholders feeling that they are heard and that their opinions matter, and that their contributions are recognized. And this could be done through relevance or through regular frequent and bi directional communication. So again, your guidelines and tools are your business analysis approach to describe the nature and the level of collaboration required for each stakeholder. The business objectives can help you focus on the common vision and the desired business outcomes and then your future state description recommended actions. recommended actions is basically communicating what should be done to improve the value of a solution and can help gather support and focus the stakeholders on a common goal.

Another guideline can be your risk analysis results. So techniques that can be used for collaboration. Managing stakeholder collaboration, like I mentioned earlier is collaborative games, which might be used to stimulate teamwork or collaboration. You know, if your need to do some type of ice breaking or to gain trust, lessons learn is a really good practice because it helps you understand how satisfied stakeholders have been or dissatisfied with previous activities and help make improvements towards those. You could also use a risk analysis and management stakeholder lips, maps and personas, right? Because that's going to tell you who to participate with, or collaborate with.

And then all stakeholders involved in the project might be collaborated with during the change. And so again, your output is a stakeholder engagement. And so again, this is not necessarily a deliverable. It's more like a state of the stakeholders being willing to engage with the business analysts during business analysis activities. Alright, so we have gotten through our elicitation and collaboration, knowledge area and all of the tasks within that. I bid you guys a good night.

I hope you guys have a prosperous and productive week. If you guys have any questions throughout your studies, feel free to contact me on Facebook or you can email me at info at the va.com Feel free to check out the website the va.com For additional resources and information, you guys have a great evening and