So we are at the business analysis planning and monitoring knowledge area, we went over the introduction chapter and the business analysis key concepts. So this is where we are now business analysis, planning and monitoring I. And those of you who are kind of wondering what will I methodology is here basically, I'm trying to help you guys identify the key points throughout Babcock because there's so much literature in here, I basically highlighted the parts that are a little more important for you to understand. So the parts that I have highlighted are things that are probably useful or most likely to be useful for you. For exam purposes, the business analysis, planning and monitoring knowledge area. This is basically what you're going to do in order to coordinate the business analysts tasks and the stakeholder tasks that need to happen in order for you guys to complete a project right.

So whatever needs to happen For Business Analysis work to be completed, we are going to plan those things out. And so this particular knowledge area has six tasks. And that includes plan, business analysis, approach, plan, stakeholder engagement plan, business analysis, governance, plan, business analysis, information management, and identify business analysis, performance improvements. Alright, so your planning business analysis approach, this is what most people think of when they hear a methodology or framework. So this is basically the overall approach that we're going to take in order to you know, execute our activities, tasks and deliverables. Now, in most cases, your business analysis approach needs to align with the overall project approach.

So if your project team has decided that you guys are going to do a agile or waterfall approach, Dan, your business analysis approach. So it really aligned with that. But it doesn't always have to, but it usually works best if it does. And now we're going to move on to our stakeholder engagement approach. This is where we are figuring out who the stakeholders are all that are relevant to the change, and what we need from them and what they need to do. So we need to plan those things out before we actually communicate to them what they need to be doing.

Then we've got governance, this is all about decision making. So plan business analysis, governance, is really about ensuring that the decisions are made correctly or in a way that works for the goal that you're trying to achieve. And also that you have a process in place for ensuring that those decision decision makers have the information that they need in order to make an informed decision as well. But in a nutshell, plan business analysis governance is all About decision making. And then we have plan, business analysis, information management. So this is how we're actually storing and saving our information.

So we're basically defining how the information or the artifacts that we've developed during business analysis, how we're going to capture, store and integrate that information with other information, specifically for long term use. And then identify business analysis, performance improvements. This is actually where the whole monitoring piece comes from when we talk about business analysis, planning and monitoring, so this one is a little bit separate from the other sections. But this is where we as business and business analysts are monitoring our own performance. So we're managing and monitoring how business analysis work is performed and ensuring that we're meeting commitments and basically Doing the activities we need to do in order to meet expectations. And then we're going to measure those and see where we fall and then take action to, you know, make any improvements that have been identified.

This section here just talks about the core concept model in relation to business analysis, planning and monitoring. It's not a big concept for the exam. But we did go over it last week. But just as long as you have a general understanding of the business analysis, core concept model, you should be good to go. All right, so this knowledge area has inputs and outputs, I would say largely overall, have an understanding of what the inputs are. But the outputs are more of a goal.

They're more tangible. So I would say understand the outputs of each task and eat Knowledge area in a little more detail than you would the inputs. So this image here is are the inputs and outputs for the entire knowledge area, not necessarily one specific task, but we'll get into details moving forward. All right. So, our first task that we have here is plan business analysis approach. Again, like I said, this is aligned with the overall project approach or the project methodology or the project framework.

And in general, like I had mentioned last week, and approach is more of an overarching term or as a plan is a little bit more detail on and when I talked about the structure of bedrock, I had mentioned that you're always going to want to understand the purpose of everything from your your, your knowledge areas, your tasks, down to your techniques. The purpose of these elements are very important. So, Plan B is a business analysis approach. The purpose is basically to define the appropriate method to conduct business analysis activities in a nutshell. And so, again, it may be defined by a methodology or some type of organizational standards. Some organizations might have a business analysis, you know, excellence center or maybe a team that structures all this for you maybe PMO depending on how the organization is structured.

And also, if there aren't any standards that exist, we fbas will look at the particular context of the situation and determining how the work will be completed. And so generally planning for business analysis or planning your business analysis approach should align with the overall goals of the change. Coordinate business analysis tasks with activities and the deliverables include tasks to manage any risk that are potential, and then select the techniques and tools that have historically worked well. But if you don't, you can pull pieces, like maybe the team members, or maybe the type of techniques that they used, that may have worked well, for something that might not necessarily be the exact same, but along the same lines. And so your input here is needs. So like I mentioned last week, everything starts with the needs.

And so when you're dealing with your business analysis approach, the needs basically shaped how the organization is looking at the problem, right? So this is going to be what we're considering and what we know and what we don't know as far as planning goes. And so your output is going to be the Business Analysis approach. So this is really more like a plan as far as a tangible deliverable, but back change the literature, it used to be called the business analysis plan. Now, it's called the business analysis approach. So we'll talk a little bit more about that moving forward.

The tasks using this output, that's not really something you need to commit to memory, so we won't worry about that. Okay, so now let's talk about the elements that are involved in business analysis, planning and monitoring. So your first element is planning the approach. So Bob Bach discusses two primary or arching approaches which is predictive and adaptive. So your predictive approaches usually focused on and these are things that you're going to want to understand, at least at a high level, is that predictive approaches focus on minimizing the upfront of certainty. ensuring that the solution is defined before you, you start implementation.

So basically, we want to have a plan before we send it over to it. And this is done in order to maximize control and minimize risk. Now your adaptive approaches, well, I'll take a step back. So if you kind of follow along your predictive approaches what we generally will call waterfall, and in a in the real world, right, and then we have your adaptive approaches, which is generally aligned more with agile. And so your adaptive approaches focus on rapid delivery of business value in short iterations. And in return, basically, you know that there is a higher degree of uncertainty of their overall delivery, but we build in that systematic ability to accommodate change.

And so you can use different approaches within the same initiative. This is what we call a hybrid approach. Or some people call it agile fall. And there's a bunch of other tongue in cheek terms for them. But most organizations that are implementing adaptive or agile aren't fully ready. So they they start by implementing small components.

And they do this by you know, doing a hybrid approach. And so when we're planning our business analysis approach, you're going to consider the formality and level of detail for the deliverables. So generally, your predictive approaches are more formal there, there's a lot more thought and time to put in, you know, you generally have templates, you have maybe some sign offs and things like that. Whereas your adaptive approaches favor defining the requirements as you go. And defining those requirements through frequent iteration. I'm sorry, interaction and collaboration right?

Because Adaptive, and specifically agile is all about getting feedback in a working solution. And so some of the things that you might want to keep in mind that also affect the approach are the complexity. You know, and risk, right. So usually things that are more complex and higher risk you, you know, want to plan those out a little more. So that might be a little bit more predictive. Also things that are heavily regulated.

Contracts are agreement, geographically distributed. So you know, it's harder to collaborate in an adaptive environment, if everybody's in different countries or different states, right. So a lot of the times you have to structure your meetings in a way that you would during a predictive or waterfall, temporary structure, things that are outsourced is kind of along the same line as the geographic dispersed, because you've got people that are not within the organization or not at arm's reach. So you typically have to plan something out a little more in depth, and also the experience level of the team members. So if you have got people who are need a little more hand holding, they might need a little more directive. So they might, they might do better in more of a predictive environment because things are a lot more planned out.

Also, whether or not you need a formal sign off, how long or how stringent the information must be maintained for future use, or future initiatives. And this is a good image here or a good figure here to take to memory. Basically, it just talks about some of the characteristics of predictive versus adaptive information. So when you're dealing with the solution Your predictive is defined before implementation whereas your adaptive is defined in iterations. Your family for predictive is formal, whereas adaptive is informal activities in predictive tend to, you know, identify the deliverables first and then divide them into smaller tasks that gets executed. And here, we know that we have iterations, right so we call iterations or if you're working in Scrum, we call those sprints.

So we know we have this fit a certain amount of information within that two week period or one week or four week period of what however, whatever the cadence is for that iteration, and then your timing. We know for predictive everything happens in specific phases, right? We have the initiation phase, the requirements phase, the development phase, and analysis phase and things like that. And then for adaptive, everything is iterative, which means that it happens continuously until we're done, or are able to deliver a product of a satisfactory product. Alright, so that's about formality. So now we're going to talk about the activities.

So basically, the activities are basically we're going to be determining, you know, how frequent we're going to be doing them, the types of activities that need to happen. And so, again, this is something that might be influenced by your organization's methodology, or the processes that they use, but it's greatly influenced by the, the approach or the framework that the project team has decided that they're going to go with. So you're going to talk about the activities that are required and the deliverables And then break those down into activities. And then you're going to, you know, for agile environments, you're going to divide the work into iterations and identifies the deliverables there. And again, you know, if you have a reference or a previous project that is similar to the initiative that you're working with now, you can use that as an outline for your plan for your current initiative.

So now we're going to talk about the timing. Again, your timing is something that is based off of your framework or your approach. So basically, as we as we determine the timing of business analysis tasks, when they need to get performed, and whether or not they will vary over time. So it might not seem like it because for most projects, Practicing DBAs you're working with a project manager and you've got the project manager building out the project plan. But bandbox feels that we should be creating our own business analysis plan, and then submitting that to the project manager as an input into the overall plan. So, you know, we should be having say so over the business analysis tasks, and the timing of the work.

So the things that are going to impact that are the availability of resources, resources, being people or tools or things of that nature or information, the priority and urgency of the initiative, a lot of times, we might, you know, be on a low priority project that has a higher priority project, you know, with the stakeholders that we need. So, um, our project might have to get, you know, play second fiddle to that so that, that impacts the timing of our work. And again, that goes in line with us. concurrent initiatives. Right? How many pieces or how far are our stakeholders?

How much do they have to divide their work throughout the day, and then other constraints as well. Okay, complexity and risk. So generally predictive and adaptive projects handle risk a little bit differently. Usually things that are a little more high risk, you want to do more of a predictive approach. Whereas with adaptive, it's kind of like, you know, because you are building in a you're mature model for uncertainty, you don't mind a risk as much. So if there's less risk, it's better to do adaptive, but if there's more risk, it's better to go with predictive that way you can plan things out a little more thoroughly.

So generally as complexity and risk increases the nature of the scope, the the nature of the scope of work becomes altered. So you typically move to things that are a little more plans. Also the number of stakeholders, right, because the more people that you have to work with, usually the more cording you have to do, and you have to make more plans. So other factors that could impact complexity are the size of the change the number of the areas or the number of people, geographic and cultural considerations, technological complexities, and any other risks. So in a technical, technological complexities can pay a big piece to one technology as far as the technology of the solution that we're looking at. Also, the technology capabilities of our organization, you know, do we have You know, access to web meetings and things like that.

Now, some of the factors that can impact the risk level might include the experience of the business analysts, right. So typically, a more novice business analysts would be considered more of a risk than someone who's a little more senior or seasoned. And then you've got the context of the extent of domain knowledge, right. So that's another risk. If a person is working in a new domain that they're not familiar with, they are more likely to overlook things that a person that is a little more adept in that in that domain, because they're, they're more likely to find or uncover issues that the person with no experience in that domain would. And then the level of experience with stakeholders in having to communicate their needs.

I have had so many stakeholders who have never really been a part of a project before. So they didn't really know the ropes I guess of a project. So, you that can be a risk because they aren't as familiar on the type of information that they need to be presenting to you. And then again the amount of time allocated by stakeholders. So, that goes along with the, you know, the, you know, the other, the other work or initiatives that might be going on at the same time. And then pre selected frameworks, methodologies, tools and techniques could also pose as a risk because Babak states that we should be not necessarily just going with a predetermined methodology or framework, we should really be looking at the context of the project and then catering those frameworks or those processes to the needs of this specific initiative.

And then cultural norms is another thing that can be risky to us because for us Now for instance, if someone if you're working in an organization where maybe development not used to collaborating or they're used to working in silos and then you're trying to work on this agile project, right. So, that could be a little bit of a conflict that could pose some risk to the project. Okay, acceptance. So, this is acceptance of the, the business analysis approach from the stakeholders. So, basically, you want to have the approach reviewed by whoever is deemed to be a, an approving stakeholder, you know, early on in the project, you may need them to sign off and you might not, but the stakeholders do play a key role in reviewing and accepting changes to the approach, you know, because you know, they have, you know, business knowledge domain knowledge.

So they might be able to identify things that might be useful for this initiative as well. Okay, guidelines and tools. So again, like I had mentioned last week guidelines and tools are something that are helpful to understand, but it's nothing that you really need to just commit to memory. Unless you're doing the ECB, the ECB is a little bit more fact based and knowledge base, so they might want you to understand these but for the CCB, a, and C bap, they don't really focus a lot on the guidelines and tools. And again, the difference between guidelines and tools and inputs is that the guidelines and tools are more like references and they're more optional, whereas the inputs are things that you need to actually begin the work. So for planning your business analysis or planning your business analysis approach You need your your performance assessment to provide, you know, the results from previous assessments, maybe some business policies to define the limits of how decisions can be made.

Expert judgment is always a good thing. So, you know, this is to determine, you know, the optimum business analysis approaches. And also, you know, it's a newer project or you're embarking on a new opportunity and you don't have anything similar to reference. Expert judgment is very much needed in order to come up with the plan. Then methodologies and framework, you know, we need those to be tailored in order to meet the specific needs of this particular initiative or challenge. And then stakeholder engagement.

Which, you know, we'll talk a little bit more about that later, but that's basically understanding the stakeholders and their concerns and interests. So planning business analysis approach has several techniques, but I'm not going to go through. And that's because I'm gonna talk about the techniques further when in one of the other weeks, I'm going to go through all the techniques in detail. But for those of you who are taking the exam, my advice to you would be to understand the purpose of each technique. You don't necessarily have to just know how you're going to be using a particular technique for that task, if you understand the techniques at a decent level, when you're approached with the situation you would understand, you will be able to understand which technique is the best out of those four options that you might be presented with. So I would say just have an understanding of the technique itself.

And then you will be able to look at a scenario that you're given and be able to determine the right answer stakeholders, again, stakeholders is not something that comes up a whole lot on the CCD or see that. Again, I will say you're going to want to understand the general definition, and role and responsibilities of each stakeholder. And again, when you're presented with those scenarios, you will have an understanding of, you know, who's the best choice for that. But I will talk a little bit more about the stakeholders than I did for the techniques just because there's less of them. And I think we can fit those in. And so for the stakeholders for planning the business analysis approach, your domain subject matter expert, you know, um, you know, you have to take into consideration their availability, right, because they're almost a source of risk.

If they don't have a lot of availability. The project manager makes sure that the business Analysis approach that we have developed is realistic for the overall schedule of the project. So it needs to be compatible with other activities that the project manager has outlined in the overall project plan. Regulators is an interesting one, because, you know, we think regulators, those are more like, you know, sometimes they're external people. But sometimes you might have someone in a house like maybe a compliance officer or a business controls manager officer or something of the sort. But these people typically look at different aspects that need to be included, into how decisions are made or how information is stored.

So they might need to be consulted for your business and office plant as well. Then our sponsor, we all know this is the push the money person, this is our funder. So they provide the needs and objectives to us and they're typically the initiator of the project, and they also ensure that You know, organizational policies are followed. And so your output for planning business analysis approach is actually a deliverable, which may be referred to as your business analysis approach or your business analysis plan. So, again, your business analysis approach is the overarching approach. So are you doing, you know, adaptive or predictive or agile or waterfall and then the plan is those that list of details of the activities and the test that you're going to do.

So your business analysis approach identifies the business analysis approach and the activities that will be performed across an initiative, including the activities, the timing and the sequence of the work, the actual deliverables that will be produced and any techniques that you go To use. So um, this is actually something that a lot of MBAs might not do in in the real world or in a practical setting. But it's definitely a good practice to have some autonomy over that. So our next task is plan, stakeholder engagement. So this is really all about how we are going to be establishing and maintaining effective working relationships with the stakeholders. Usually, you're going to be doing some type of stakeholder analysis.

So when you are on a project, you usually get with your sponsor and the project manager to determine, you know, potential sources of stakeholders. And then as we go through the project, you're going to do further analysis to call out some Additional stakeholders that we'll talk about down the line. But essentially, this task is focusing on, you know, determining how we're going to communicate and collaborate with the stakeholders and maintain effective working relationships. So you're going to be conducting your stakeholder analysis to identify all of the stakeholders involved. And then we're going to be looking at their characteristics. So, like I had mentioned earlier, you know, as the degree of complexity increases, that could be due to the fact that more stakeholders, right because you know, the more stakeholders you have, the more complexity the more complex things get.

So your inputs are your needs, we know that everything starts with a need and your business analysis approach we which we just talked about in our last task, So your output is going to be a stakeholder engagement approach aka a stakeholder engagement plan. So that's another deliverable. The interesting thing about this output is that this is actually a subset or captured within your overall business analysis approach. And so your guidelines and tools are going to be your business analysis, performance assessment, your change strategy, and your current state description. So the first element for planning stakeholder engagement is performing your stakeholder analysis. So like I had mentioned that you usually will start you know, with some type of stakeholder list that might be you know, in the project charter or the project or the business case that might have a list of stakeholders.

Or you can start with a sponsor or the project manager or whoever is available that might be able to offer something information to you in regards to potential stakeholders. And then, you know, again, your stakeholder list make sure that specific stakeholders don't get overlooked. Because we all know that if you miss a stakeholder, that means you're going to be missing critical needs or critical requirements down the line. And nobody likes to miss requirement down the line. And, you know, as business analysts, when we're doing our additional research on the state cutter list, we can use things like companies or chart, business processes, or even a business model canvas to be like an initial source of identifying stakeholders. And again, like I had mentioned, the sponsor may also be a source a source for that as well.

Rolls is another piece Once we identify the stakeholders, we need to know their roles. So basically, we need to understand how a particular stakeholder is going to contribute to the initiative. Because these are people, you know, they have various roles, are they going to be an approver or they're going to be a subject matter expert, things like that. Attitudes is another piece of identifying stakeholders because stakeholder attitudes can positively or negatively impact a change. So, we want to understand the stakeholders, attitudes about the business goals, the objectives, business analysis in general, I have worked with a lot of stakeholders who have had poor relationships or experiences with the business analyst role. So you know, I kind of had to go through the whole process of gaining their trust and making them feel comfortable and things like that and also the level of entry interest in the change usually the more interested and excited about a change the more accommodating they will be to assist you when you need them.

And also you want to know how those stakeholders feel about the sponsor, are they supportive of the sponsor, have they had a good relationship with the sponsor things like that? And also how they feel about each other and other, you know, stakeholders and other team members, right, because, you know, that all impacts the team morale. And again, like I had mentioned earlier, you want to have an understanding about how they feel about collaborative and team based approaches. You know, many people are, you know, many organizations are still stepping into this whole adaptive, or agile mindset. So you still have a lot of people specifically as well especially it people who want to really, you know, stay you know, to themselves or you know, they they're more focused on analytical things and data So they're not as comfortable with, you know, these meetings or people just popping up at their desk or meeting with someone every day and things like that.

So I'm generally stakeholders who are expected to serve in roles but have a negative view of the project. We might have to use some special type of collaborative techniques or approaches to, you know, gain their trust and, you know, be looked at as a trustworthy person, and somebody that they like to work with. This is where your soft skills are really going to come into play. decision making authority, whenever we identify stakeholders, we definitely want to know how much clout they have, um, because the people you know, there are so many people that can just talk and, you know, they have so much information but they really don't have decision making authority. So We just want to make sure that the we know who those decision makers are. Because when we get information from someone like an SME, they might have all of the knowledge, but they're not necessarily a decision maker.

You know, I mean, they might be in an agile framework. But in most traditional projects, SME might not necessarily be a decision maker. So we just make sure that the, we just have to make sure that we're closing the gaps in between that information. And along those same lines is the level of power influence. So someone might not have power or authority, but they might have influence. So we need to be able to distinguish the difference between those two and understand those dynamics.

And this is awful. also helpful for getting buy in from the team. If we can get the person that has a lot of influence under our belt on our side. We can use that we can leverage that to get the rest of the team to buy into the solutions that we're recommending. Okay, I know we went through a lot of components, these are these were all components under performing a stakeholder analysis. So that was actually just one element.

So our next element is defined stakeholder collaboration. So here we're just planning different collaboration approaches for both the internal and the external stakeholders for the different activities that we're going to be doing. So things that we as BMS have to consider is the timing and the frequencies, the location, the available tools to us the delivery method, you know, are we doing something in person or virtual, and then the preferences of the stakeholders so when I provide my students with a With the course, we have templates of each of these documents. And so you would see that within the stakeholder engagement plan, there's like a list of different stakeholders, and then there's a list of their preferences too. So that's just something you would that will help you when you're planning out those actual activities. And so planning considerations is documented in the form of a stakeholder collaboration plan.

So your stakeholder collaboration plan is a subset of the stakeholder engagement approach. And then your stakeholder communication needs. So this is almost in alignment with the preferences of the stakeholders. But this is basically you know, what needs to be communicated to the stakeholders, the appropriate delivery method The audience who needs to know what, further down in the sessions we're going to talk about views, right? Because we know that we have to present different things to different people. So we have to know the appropriate audience.

We also have to know when to communicate and the frequency. Again, the geographic locations matter, because that is going to impact you know, the type of information that we're able to do right if somebody is remote, or in another state or a different time zone and things like that. And then the level of detail that's appropriate for the communication as well. This is also dependent on the audience and their knowledge as well. And the level of formality, these two are pretty much aligned. And so communication considerations is documented in the form of a stakeholder communication plan.

So this This is another subset. So your stakeholder engagement approach is a subset of the business analysis approach. But you also have two subsets within your stakeholder engagement approach, which includes the stakeholder collaboration plan, and the stakeholder communication plan. I remember seeing those on my exam. So just keep those in mind. Guys and tools are your business and assess performance assessment, which we went over the chain strategy is basically how you're going to get from point A to point B.

And this is actually used for improved assessment of the stakeholder impact. So when we talk about our sticker activities and the activities we're going to do to collaborate with them your change strategy might be helpful to understand what that impact is going to be. Then a current state description, which at this point when we are may not have even done yet, but basically your current state description gives you context on the work that needs to get done, right. So this is basically the end goal. So that's gonna give you some information on what you need to do in order to get those goals or achieve those goals. Again, your plan, Business Analysis planning, and I'm sorry, Your planned stakeholder engagement also has several techniques that you can use that were we won't go over.

We'll talk about them when we talk about techniques. So customers are generally forms of external stakeholders. While your domain subject matter experts are internal, and they also help identify stakeholders so they might be A good resource for you in addition to the sponsor and the project manager, on end users are your internal stakeholders, the project manager, like I had mentioned earlier, they might help you identify or recommend stakeholders, then the regulator may require specific stakeholders for whatever compliance reason, you know, a regulator might have a specific specialty, or knowledge or skill set that might be needed for their project that so they might have to be included as a stakeholder. So again, a sponsor who is the, you know, the ultimate decision maker in waterfall are in predictive or waterfall projects, you know, they may request that specific stakeholders be involved as well. And then your supplier is a another external stakeholder.

So again, your supplier is usually like a consultant or a vendor of somebody of that nature, some type of partner that's working with us. And so your output again, this is another tangible deliverable. One thing I'll say is that most of the outputs for the business analysis, planning and monitoring knowledge area, most of those outputs are actually tangible deliverables that have templates and forms that you can, you know, actually see. And so your output here is the stakeholder engagement approach, which can be considered synonymous with a stakeholder engagement plan. So again, this contains a list of the stakeholders, their activities, their analyze and listing of roles, responsibilities of the change. I'd also include like their authority levels and things like that and identifies the collaboration and communication approaches.

So plan business analysis governance, this task is really all about decision. So whenever you see governance on the exam look for some type of either a decision being made or a change control. And so the purpose of planning your business analysis governance is to define how decisions are made about requirements and designs including reviews, change control, approvals and prioritization. So a governance process also describes how approval and prioritization decisions are made. So for us, when we're creating the business analysis, governance plan, we're going to be looking at how work will be approached and prioritize how a change is going to be proposed, who has the authority and responsibility to propose a change and also who's responsible for animals Those change, right? And then the who has the authority to approve those changes.

So this goes back to our stakeholder engagement when we're looking at their characteristics, their power, their influence, we want to know who actually has the authority to approve, and then how we're going to document and communicate those changes. inputs are your business analysis approach and stakeholder engagement approach. Just know that all of your approaches should be aligned with one another. Everything should really align with your business analysis approach because that's the overarching approach and all of these other tasks within that are almost like subsets of the business analysis approach. So your inputs again, are your business analysis approach and the stakeholder engagement approach. Then you're going to be creating your business analysis, or you're going to be planning your business analysis governance in your output.

It is your governance approach. So, tools or references that you're going to be using might be your business analysis, performance assessment, business policies, the current state description, or some type of legal or regulatory information. All right, and so your elements, I think I may have mentioned this last week too, but when you're studying, I found that the element sections of back is where a lot of the questions come from. So those the elements of each task is what you really want to have a good understanding of. And also, I'm in my workbook and study guide. We we kind of guide you on what you need to understand out of each of those elements.

Because you really need to understand after you've read something you need to know Okay, what am I supposed to get? That right. So, that's a lot about that's a lot of what our you know checklist and our workbook and study guide focuses on is to make sure that every section of bedrock, you read, you understand why you were reading it and the overall outcome of that. And so the first element of planning, business analysis, governance is decision making, right? So, a stakeholder can serve as a decision maker, um, in many different processes. So, you know, they participate in decision making discussions, you're a subject matter expert may be able to give some input on the actual decision making process.

They're often reviewers of information and they're often approvers of decisions, right. Um, so basically this the this the business analysis governance plan also defines what happens when the team cannot reach a an agreement or consensus. So how are we going to escalate that right? So that's something that you also need to consider whenever you are creating your governance process. And then the change control process this is what we all know when you know we're in the middle of a project. And you know, new information has been found out and we have to add or remove or change requirement, we need to create a change control form or process.

And within that, we're basically going to be determining the process for requesting changes. Sorry if you guys can hear this like a crazy loud muffler in the background here driving by. Um, so you're going to determine the process for requesting changes. So this typically comes in the form of some type of change control form or template or something of that nature. You want to determine the elements of that change request. That's typically going to include the costs and the time estimates, right?

Because the project manager wants to know about the cost and the time, you know, how is this going to impact the schedule? The benefits of the change? What risks are involved? Um, is this going to change the priority that we have listed? So, generally, predictive projects don't really do a lot of prioritizing. They do it mostly on an AS IS BASIS.

But you know, we're as adaptive builds prioritizing as a part of it. But in case you do have some type of priority and a change comes, you need to have an understanding of how this change is relative to other factors or other requirements in the pike. And then the course of action. So this is basically the different changes that could potentially happen in the NBA, impacts of those, usually you would have several different alternatives that are considered. And then you'll have a recommendation. Choose control for my also include my also determine how changes will be prioritized, how they're going to be documented, and how they will be communicated, right?

Are you going to be communicating it with everybody? Or are you going to be communicating it with just the you know, the people on the change control board. And then you also wants to determine who will perform the impact analysis. So, you know, it's a common practice that business analysts do a lot of the impact analysis but when it comes to cost and schedule, a lot of the times we have to hand over some of those pieces to like the development team, or somebody with some type of specialized skill set or knowledge You know, what babic would call the Implementation Specialist or implementation expert and then determine who will authorize changes. So again, when we go through and look at who has the power of influence and authority, those people are going to be our decision makers. So typically the people who approve processes and the requirements are going to be the same people who are deemed to be a part of the change control board, and they're going to be authorizing these changes.

Okay, our next element is playing prioritization approach. So this is something most of us are familiar with. Again, it's something that is more leaning towards adaptive approaches. But we do prioritize things in in the predictive world. So when we're looking at the prioritization approach, we're looking at the formality and the rigor of prioritization. Do we have to consider the cost benefits of every single change or every single requirement?

Um, who's gonna be involved in prioritizing? What's the process for deciding how to prioritize? What's the criteria? Generally, you know, criteria is based on cost, risk and value. And also like if there's some type of, you know, government government or compliance related risk, those you know, usually take priority over some of the other basis and prioritization and then planning for approvals. So basically, what is Our approval process is going to be.

So we're just determining the type of requirements and designs that need to have approvals and the type of information that needs to get approved, essentially, you know, what's the process who's going to approve them, and how we're going to track the approvals. That's, you know, the important piece of this. Again, your guidelines and tools are your business analysis, performance assessment is this policies, current state description, and any legal or regulatory information. Those are your techniques. And a lot of those. The stakeholders involved might be your subject matter expert, as a person that's going to potentially request changes.

Your project manager makes sure that the governance again aligns with the overall project governance, right. So we've got our business analysis governance, and then we've got our project governance. Then the regular layer may impose certain rules about the governance process, right, there might be certain standards that need to be abided by. And then the sponsor might also impose requirements on how, you know, information is managed and governed. And so your output here is your governance approach. Again, this is a subset of the business analysis plan or the business analysis approach.

And so this identifies the stakeholders who will be responsible and have the authority to make decisions about business analysis work, and also who's responsible for setting priorities and approving changes. Alright, any questions on business analysis? governance All righty, Alright, so now we are on to plan business analysis Information Management. So this is all about accessing and storing the the business analysis information that we're building throughout the initiative. It's basically comprised of all of the the documents or the artifacts, you know that we listed, create and compile throughout our business analysis process. So we're going to be identifying how information should be organized, the level of detail the information should be captured on the relationships between information.

The right so different pieces of information should they be stored together or how can one document lead to another and also we need to understand and account for how the artifacts in our report taury or whatever, is going to be used across multiple initiatives throughout the enterprise. And so again, that's how it's going to be accessed and stored. And then the characteristics about the information that must be maintained. So we're going to talk a little bit more about characteristics a little further down. So, this task, the overall goal is to basically make sure that the business analysis information is organized in a way that's functional for users down the line. So you've got a few inputs, that's your business analysis approach, your stakeholder engagement approach and your governance approach.

And then your output is going to be your information management approach. Again, this is something that you would document within your business analysis plan. Right, so your elements are the organization of the information. So we need to make sure that we're organize it in a way that allows for efficient access and use. And we want to plan this out at the start of an initiative, you don't want to wait until you've got all these different documents and then try to figure it out. So you want to plan this out at the top of the initiative.

Um, and so, again, you're going to be considering stakeholders access what they need, what they need to do with it, right, and the size and the complexity of the change. These are all things that we need to consider when we're building out our how we're going to organize our business analysis information. And level of abstraction is pretty much defined as the depth and breadth have, you know hear the talking about information but whatever it is that we're talking about. So, basically it ranges from highly conceptual or high level to very detailed or low level. So for us, we basically just want to account for that. So, present information with appropriate breath and level of detail based on each stakeholders role.

So we talked a lot about this throughout the series, you know, generally, executives and men and upper level management want high level information whereas the people that actually do the work, we you know, they typically need more specific details, right, like a developer needs details in order to you know, execute his code. Next element is planned traceability approach. We're going to talk a lot about traceability, as well. But basically, from this perspective, we're going to be Looking at, really whether or not we even want to trace, so we're going to be considering the complexity of the domain. Usually, if it's more complex, and there's more requirements and views and more people involved, we're going to be more likely to trace. We're also going to be considering requirements related risk organizational standards and regulatory requirements.

They may require us to do more tracing, and then the costs and benefits involved in tracing. So we want to make sure that the level of detail that the approach that we use to trace is at the level of detail to actually add value without excessive overhead. And that just means that Tracy can be it can take some time. And it can also take away from other activities. So we just want to make sure that we're actually getting value out of tracing if we're actually taking A time away from doing something else that might be more valuable. Planning for reuse.

This is a big concept for business analysis information or planning, business analysis, information management, planning for requirements reuse. So reusing requirements can save the organization time, effort and costs. So this should actually have a star by it. Because this is a pretty important concept for reusing requirements. I'm usually the candidates for reasoning requirements are candidates that are long term. So longer term requirements are requirements that are much more high level, right.

So typically, a business requirement is more something that we would reuse more so than like a solution requirement. So things that might be candidates for long term reuse Might be regulatory requirements contracts, your obligations, quality standards, right. So those are non functional requirements, right? And service level agreements, right? These are non functional requirements, business rules, that's the technique that we're going to go over that is actually a type of requirement, business processes and requirements describing products or enterprise or things that the enterprise produces. And so the thing about reusing requirements is that they may be used across different services, but they can also be used across multiple systems, processes and programs.

So you can use a high level requirement for your project and also another one at the same time or in the future. And in order for a requirement to be reuse, it must be clearly named, defined and stored in a repository that is available. to other business analysts, that's actually an important sentence. I remember something similar to that popping up on my exam for the C bat. storage and access. So basically, how we're going to information we got to have somewhere to store it right.

So this is all about repository. Um, basically, it just depends on who needs to access information, and what tools are available for you to use. So, usually, you want to have a repository that stores the information being the requirements and design and that repository should indicate the status of any sort information is a complete in progress, is it old, you know, do not use or something of that nature. And then earlier I talked about attributes, so requirements attribute are basically bits of information or pieces of information that allows us to see unique pieces or identify a specific requirement. So they provide information about requirements and aid in the ongoing management of those requirements throughout changes. So some common attributes might be your absolute reference, you know, you might have you know, Fr one for functional department one or something of that nature.

That's kind of like your unique identifier that should never really change the author. So that's the person who wrote the requirement, right? So if somebody found finds the requirement to be ambiguous or questionable, they need to go back to that author to get clarification. complexity is about how difficult that requirement might be to implement ownership is who the requirement is for. So that's like the business or the subject matter expert. Or if you're in a adaptive environment, you might be talking about the product owner.

Then risks right, so those are uncertain events. how risky is it? The source, you know, what's the original source of the requirement? Is it a person? Is that a document? Is it a business rule?

Um, and then stability is basically how mature that requirement is, you know, things that have a higher level of maturity are less likely to change than things that have a low level of maturity. Then we have status, that's basically just the state of that requirement. So you know, is it a pending requirement is an approved requirement, right? Things like that, and then our urgency. So urgency is a lot like priority, which is basically the relative importance of that requirement relative to other requirements, but urgencies a little bit different in the fact that if there's an deadline involve, it's a little more urgent. So you have to, you know, accommodate timing for for your urgency, whereas your priority is just putting one requirement above the other.

Guidelines and tools are business analysis, performance assessment. This is policies information management tool. So this is important for this task because, you know, every organization uses some form of a tool to store, retrieve and share business analysis information. So, just being aware of how that works is going to help you a lot. This is basically your repository. And then any legal information might help determine, you know, give you more specifics about who needs to access information and what information needs to get stored and how All right.

And some stakeholders that might be involved might be your subject matter expert, right. So they may need to access information and work inside of the repository. A regulator, again, may define rules, the sponsor will be the person that will back says the sponsor is the person that approves the business analysis information. But in a practical setting, you might not really see them getting too involved in that. And so your output is really just your information management approach, which is basically just a short description of how you're planning on storing, accessing, and, you know, utilizing information during the change. So again, this is something that that's captured inside of the business analysis approach or the business analysis plan.

All right. Our last task in this knowledge area is identify business analysis performance. So again, like I had mentioned, this one is like a little bit of an outlier from the other tasks in this knowledge area, because this specifically deals with the business analysts work and their performance. So the purpose here is to assess your business analysis work and plan on improvements wherever they're required. So, this is us basically establishing performance measures. And they already performance measures may already be established for us if you're come from an environment that has like I had mentioned earlier, a Business Analysis Center of Excellence, they might have that information, but if they don't, we can come up with that information and use it as a you know, something that we can align our performance to.

So basically We establish measures conduct performance analysis, report on those results and identify necessary preventative, corrective, or developmental actions. So this is actually an important thing to note that when we get feedback from that report, we're going to either do something preventative corrective or developmental. And this is actually something that should occur throughout the initiative. You don't want to just wait to the end or maybe just add a lesson learned activity, you kind of want to do it iteratively. So your inputs are your business analysis approach and your performance objectives external, which Ballack says describes the desired performance outcomes and enterprise that an enterprise or organization is hoping to achieve. So this is basically saying that whatever external goal the organization is, Looking to achieve that's going to shape you know what, how you need to perform and what your goals are for this particular initiative.

Again, those are your two inputs, performance objectives and your business analysis approach. And then your output is actually going to be a business analysis performance assessment. Alright, so elements are your performance analysis. So here, again, this depends on the particular context of the organization or the initiative. And it can be formal or, or I'm sorry, informal in verbal or it can be formal and fully documented. So, again, it's tailored to meet the needs of various reviewers.

And then you've got your assessment measures. So, the business analysts role has traditionally been very Hard to measure because our performance is so subjective. You know, because it really depends on how people perceive our effectiveness and things like that. So, again, you know, if current measures exists through a center of excellence, that's great, but if not, we can, we can, you know, come up with our own. Um, and so, things such as, you know, frequency of changes to business analysis work, the number of review cycles, task efficiency, quality, qualitative feedback from stakeholders and peers, regarding the deliverables are all things that, you know, we may use as measures for our business and also performance. And again, those measures may be qualitative or quantitative.

And I actually like this because I think kind of it gives a good roadmap for in even in the real world, things that you can kind of use as some possible measures. So that that includes your accuracy and completeness, right? How accurate are your requirements? And how able are you to kick out complete requirements, which are knowledge, right. So do you have the appropriate skill set? are using various tools, things like that effectiveness?

Are your requirements easy to understand alone? Or do people continuously have to come back to you asking you questions and questions and questions about what you've documented? And then the organization support so this is whether or not you've had adequate resources in order to complete the business analysis activities and then significance so are you doing the right things at the right time? Right, so are we getting benefit out of the documents or the analysis that you're doing? Right. So, this is whether or not the cost time and resources invested into producing work, whether or not it's justified.

So, this goes back to when I said you got to use context rather than just using a pre determined rather than just using pre determine you know, documents or activities, you want to go create activities based on the context of of the situation to give more significance, how strategic you are, are you good at looking at business objectives and problems being solved? And then your timeliness, you know, are you able to meet the deadlines? Are you able to quickly adapt to change while maintaining deadlines and schedules and things like that? So we need to analyze Why's this information. So, I have done in the past you know, I have done like surveys about my performance to various groups like the development team QA team, maybe some members of PMO you know, to ask him things about you know, my performance and how it can be improved.

And in sometimes you might not want to say my performance, you could also say the business analysis process overall, to take the heat off of you just a little bit. But you basically just want to look at the, the processes and deliverables, um, and compare the set of defined measures against your actual performance. So, um, you know, like I had mentioned, basically when you create a plan, your business analysis plan that becomes your, your measures, right, because you usually have deadlines, things like that, you know, a number of meanings In the activities, right, so are you completing them? Are you completing them by the deadlines that you, you create it right? So those are all measures that you can compare against. And again, the Center of Excellence might have some measures for you as well.

Oh, this is another important statement is that performance may be determined from the point of view of the stakeholders who are recipients of that work, right. So that's why I said that, you know, your soft skills are really important because the way stakeholders perceive working with you, often determines your success as a business analyst. And then we have to recommend actions for improvement. So based off of the feedback we got from those stakeholders, we're going to have to do some preventative measures to reduce the possibility the probability of something happening with the negative impact or maybe we have to correct something to reduce the net negative impact of something that has already happened and then improvement so how can we increase the probability of events happening with a with a positive impact. So, for this particular aspect and improvement might be you know, some type of business analysis, training, requirements, training, maybe facilitation skills training or something of that nature.

And also the results of your business analysis. performance assessment may change the overall business analysis approach that you've taken, either in the past on this current or existing project. Some some guidelines and tools are just any organizational performance standards that the organization may have, which might include some metrics or expectations of business analysis work. Your lesson learned is pretty a pretty common place. for recommending changes to business analysis processes, deliverables and templates, and other processes that are associated with that. But again, there's various other techniques that you can use for establishing your business analysis performance.

All right, so some stakeholders that might be involved or the subject matter expert who might set expectations regarding their involvement in the work, the project manager needs to be kept informed on the overall status of the business analysis work. And then the sponsor. You know, this is pretty uncommon, but the sponsor may require reports or business analysis performance to address any problems. And so your output would be your business analysis. performance assessment, which includes the comparison of the plan versus the actual performance, right. So this is like your business analysis plan is the plan work.

And then after an event occurs, you know, you compare that against to, you know, to see how it panned out, did it actually work out as planned? And then you want to identify the root causes of the variances and then propose approaches to address any issues for improving the work. All right, so we have gotten through our first knowledge area, which is does analysis, planning and monitoring. Thank you for joining me. I really appreciate it. And I hope you guys have a productive and prosperous week.