Alright, so we are on chapter six of Babcock. So this is our strategy analysis. And strategy analysis is actually one of my favorite chapters to teach on or knowledge areas to teach on because a lot of business analysts don't actually have a lot of experience with the strategy analysis, because many vas work at the project level where, you know, they come in after the requirements have already been determined, and they're basically just trying to document them. So this knowledge area talks is a little more holistic in the BA role because it talks about actually identifying the needs and refining those needs and things like that. So, um, in a nutshell, the strategy analysis is, well strategy basically is what we use to define the most effective way to achieve capabilities. For an enterprise in order to reach some type of desired goal, or objectives.

And so the strategy analysis knowledge area is the work that we do as MBAs to collaborate with stakeholders to identify the needs that are either strategic or tactical, those strategic or tactical business needs that enabled the enterprise to meet those needs or address those needs. And so, the knowledge area really focuses on defining the future state and the transitions to get to those states. So it's work that is defined both by the need and the scope of the solution space. So this knowledge area really gives us some inputs or some context into the requirements and design definition in the future or for the future initiative. And I think this illustration here is a really good illustration of what they call the business analysis value stream. So value is apparent at different states.

So when we're in the strategy analysis value is potential, we're looking at the potential value of a solution. So needs are identified. And then we try to define the boundaries of the solution scope. So this is all potential value, because we don't know exactly what the outcome is going to be. So we're assessing the potential value here. And as we go through requirements analysis and design definition, and then solution evaluation, we start seeing different areas of actual value.

So when we're doing our proof of concept, our Baila or our pilot sessions, we can see you know, A minor bits and pieces of value. And then when we do our full on full delivery, we can start monitoring to see the full value of the solution that we've delivered. So just take you to this diagram there, because it's really good for helping you understand, you know, value because value was kind of hard to define, you know, from a practitioner perspective. So I think this Doc, this image here is a good demonstration of the transition of value over the life of a project. And so, when we are doing strategy analysis, there's a couple of different types of changes. We have predictable outcomes, or we also have outcomes that are not so predictable.

So predictable outcomes are Are those that can be clearly defined, right? And we can clearly define some type of strategy to plan that out. Whereas something that's not easy to predict or is something that we're going to want to focus in on mitigating the risk. So, for instance, if we are simply just making a system upgrade, or we are making some enhancements to an existing system, those are things that are predictable. But if we are doing something that is like entering a new market, or you know, deploying a brand new product, those things are new to us. So we are going to be focusing on mitigating risks, and you know, getting good amounts of testing around it that way.

We can, you know, identify any issues up front, as early as possible, and we really want to be able to course, correct As early as possible as well. Now, the strategy analysis knowledge area is composed of four tasks, including analyzing the current state, defining the future state, assessing risks, and defining the change strategy. So analyzing the current state is really one of my favorites tasks to do. And it's basically where we're understanding the needs and how it relates to the way the enterprise is functioning today. So this is where we're doing, you know, we're probably going around shadowing with people may be doing some process maps and things like that. And this is really the baseline of what we compare our value against and our measures against and then define future state is where we're actually defining the goals and objectives that demonstrate that the business has actually satisfied the need and what parts of the enterprise Need to actually change.

So this is where we are basically identifying the ideal state, and then making plans in order to march towards that. And then once we've defined the future state, we're going to be assessing the risks. So there's always going to be some uncertainties and babba basically refers to risks as anything that's uncertainty or an unknown. So those uncertainties around the change, we're going to consider those and then make recommendations to address them. And then finding the change strategy is where we're going to be performing the gap analysis. And so basically, that's where we're going to be comparing the current state and the future state and creating a gap analysis to discuss what basically what steps we need to take in order to get from the current state to the future state, and then assess options for achieving that future state.

And here, we're also going to be Making a recommendation of the option, the solution option or the sorry, the approach that has the highest value based on what we've assessed so far. And again, you know, Babcock talks about the core concept model as it relates to or it's within the context of the strategy analysis. And so, again, like I say, in every one, we always went through this in the first week. So I would recommend going and getting familiar with your tasks in the strategy analysis, knowledge area and then going back to just look at this just to have a high level understanding of how it how all of your core concepts relate to this particular knowledge area. All right, so overall, we have several inputs including needs influences stakeholder engagement approach elicitation results, unconfirmed and confirmed. And then we've got our prioritized designs of requirements and these are the inputs for the entire knowledge area of strategy analysis.

So, our outputs for this knowledge area are the current state description, the business requirements, the business objectives, the future state description, the potential value, risk analysis, change strategy, and our solutions scope. So, first task is analyze current state. And the purpose of analyzing the current state is to understand the reason why an enterprise needs to change some aspect about how he operates today, and what would be directly and indirectly affected by that. To change. And so it's really the starting point, basically, the starting point of any project is a need, right? So understanding the why of the change is usually a good place to start.

And so it's usually triggered by problems or opportunities that can't be addressed without making some type of change. Right. So we, as MBAs, we're going to be exploring and articulating the business needs that drive the desire for that change. And so when we talk about the current state, we're going to be exploring it in just enough detail to validate the need for the change. Now, what that means is we're not going to know exactly what the future looks like, right? So we really just want to know the components that are going to be impacted.

So we want to know the current process, but not the entire process. We want to know the process that is going to be impacted by the things that we believe needs to change at that time. So we don't want to go too much in detail, just enough detail to allow us to know be able to assess the value and it's also enough to be able to make informed decisions moving forward. Alright, so some inputs include elicitation results, so we know what those are. And that's basically used for defining understand the current state, and also the needs and we already know that is the problem or the opportunity that's faced by the organization. We've got our inputs here, and our task is analyzing the current state.

And our outputs are going to be the current state description and the business requirements. So our first element is business needs. So we've talked about needs and business needs are really just the problems and the opportunities that are of strategic or tactical importance that's faced by the enterprise. And typically your problems need to be resolved and your opportunities need to be addressed or taken advantage of, or see something like to say. And there's various levels of, of identifying needs. There's typically your your your top down, approach your bottom up, your middle management, and your external drivers.

So these are all really sources of needs. So when you are working from the top up, that means you're working from us to a strategic goal that needs to be achieved in so this means something that has come from a top level executive If that's been passed down to the people that need to make the project happen, and you know, come to fruition, and bottom up is the opposite where the problem is identify with maybe a current state or a process function or a system. And that's usually identified by like a lot, you know, somebody in operations or frontline worker who is actually doing the work. And then they escalate that problem up to a manager and then that gets escalated up to senior leadership. And then middle management needs are those exists where the manager needs additional information in order to make or additional functionality in order to make decisions or to make something happen or to perform a certain function to meet a specific objective.

And then external drivers, right. So these are things that come from business competition or customer demand. As vas this defining the business can be the most critical step because it's really our constant reminder of what we're marching towards. Right? So it's also going to, you know, the, our baseline to see, are we meeting this need, right? So any solution that we have must satisfy the business need in order to be considered successful.

And one thing that might be important for you to keep in mind is that when we talk about business needs, we always talk about business needs from the perspective of the enterprise, not a particular stakeholder. So, you know, when we do stakeholder requirements and user stories, we do talk about a specific stakeholder, but overall, you express business needs from an organizational perspective. And there will be cases where you have to look at the greater good Because some changes might have a positive impact to a lot of people in the organization, but have a negative impact to a few people in the organization. And because the good outweighs the bad, we would still go on with that need. And so some of the things that we look at when we're doing strategy analysis, or assessing the business need is when we're considering our needs a solution to those needs.

We're going to be trying to look at any adverse impacts that the problem is causing within the organization. Right. So how can we quantify these things such as lost revenue or inefficiencies, um, as well as the expected benefits of the potential solutions, right? how quickly the problem can be resolved, or how fast we can take advantage of the opportunity. And then we're also going to be considering the underlying source of that problem, or that need. Right, so our next element and strategy I'm sorry, our next.

Yeah, our next element in the analyzing the current state is our organizational structure and culture. And so this is where we're basically looking at how the organization is structured. Right? So we're looking at the form of relationships so that you know, who managers who reports to who things that you basically find on an org chart. And then the organizational culture is really the beliefs and values that shape the norms within that organization. Right.

So, you know, some companies believe in lots of collaborative collaborations whereas some organizations aren't big on collaboration and people work in silos. So those are all things that can impact the success of a solution. And so when we perform these cultural assessments, we're going to be identifying if cultural changes are required, and whether or not the stakeholder understand the rationale of the current state. And that basically means do they believe that there's an issue with the current state or do that? or Are they aware that a change needs to happen? And then we want to know, um, yeah, again, you know, if the stakeholders view the current city is satisfactory, are they able to identify a change or the need for change?

Alright, so your next, your next element is capabilities and processes. And these are basically just the activities that the Enterprise Performance on a daily basis which really, you know, Your core capabilities. These are the things that people within the organizations do in order to differentiate it from one another. So core capabilities are things like your competitive advantage, things that contribute to your competitive advantage. And so something that is important for the exam, I know there's probably going to be a question to about these is the type of views that we're going to be looking at or making or considering, you know, our organizational changes, and that is your capability centric view and your process centric view. And the capability centric view is when we're looking for innovative solutions that you know, where we're basically combining existing capabilities in order to produce a brand new outcome.

So we are finding ways to do something that we have not done before or maybe somebody else hasn't done before. The process centric view is where we're really just looking for ways to improve the performance of things that we're already doing today. So, you know, a lot of the times, this is like, you know, into an MRI engineering, things like that, a lot of times we're trying to have the same outcomes, we're just trying to do it more efficiently. So that's your process centric view. technology and infrastructure, so we know what technology is. And that's just the systems we use to support the activities we have throughout the day.

And then our infrastructure describes the environment with respect to the physical components of those so that's like our system hardwares you know, physical plants, the buildings, we sit in, logistics, you know, meeting times, meeting rooms, things like that. telephones as well as you know how they're operated. Another thing we're going to be looking at or analyzing the current state is the policies. Now, policies are important because these add these define the decisions that are made throughout the organization. So, that define the scope of decision making at different levels. And it usually addresses some routine operations, but there can be some that are strategic it policies generally just make sure that decisions are made correctly and give guidance on the the the activities that are most important.

Our next element is the business architecture. So all of the things that we talked about how they relate to one another and how they support one another. These are all considered to be business architecture. So you know, usually your business are Architecture meets stakeholder needs, right? And if a potential future state does not meet those same needs, then or the change results in a loss of value that is not considered a valuable future state or a viable future state. So we want to make sure that we are continuously meeting those needs, that we're meeting today and then maybe meeting some additional needs in the future.

The next element is your internal assets. And these are the resources that are either tangible or intangible. So tangible assets might be your people. intangible assets might be financial resources, patents or your reputation. Basically things that are more conceptual and do a lot more with the image of the organization are Right, so our next element for the analyzing the current state are the external influencers. And so these are things that happen outside of the organizations that impacts the way the organization works or needs to work.

So some sources of external influences might be industry structure, right? So this involves, maybe, you know, entering a new industry or new market competitors, right, we always want to stay ahead of the competitors or at least keep up with them. So when there ever there's a new competitor or a competitor leaves the market, that's something we're going to want to know about also customers right. So the size and nature of the existing customers influences, you know, their negotiating power and then the price sensitivity. So typically, if there are a lot of options, people tend to be more sensitive to price, whereas if something is rare, people will will pay whatever you ask for. And then supplier.

So these are just our vendors, the people that work with us, you know, that offer supplies, and then political and regulatory environment, right. So these are the laws and regulations, they impact our industry, as well as technology. So any recent and innovative technology has the capability to provide additional capabilities to the organization. So we want to keep that in mind as well. And then our macro factors are macro economic factors, right? So macro means big, right?

So these are constraints and opportunities that exist as you know, a result of issues such as trade, unemployment or inflation, basically things that are too large for the organization to really have control over. Okay, so our guidelines and tools include our business analysis approach. We know what that is the enterprise limitations. So the enterprise limitations is basically challenges that exist within the enterprise. Why is it that the enterprise cannot meet a certain need or reach a certain objective? This could be things like culture, training, knowledge, skill set, things like that organizational strategy, and this is basically the goals and objectives that guide operations.

So this is almost like your mission statement and things like that. And the solution limitation, so, this has not been developed yet. Because we're still trying to figure out what the solution is, but if there's an existing solution, or an existing system We're going to be looking at those systems in the current state, and the challenges that exist with those. And then the solution performance goals. So we want to measure current performance such as term times, costs, and processing times and things like that. And those will be the baseline for setting the goals for their future state.

And solution performance measures similar to the performance goals. But these are just the actual performance of the existing systems or solutions. And then your stakeholder analysis results. So that's something that we perform to, you know, once we're trying to figure out who should be involved in the organization for this project or this initiative, who's going to be impacted and understanding those individuals will help us better understand the current state that as it exists today, And how the future state will need to be impacted. So there's quite a few techniques you can use during your when you're doing you're analyzing the current state. So I just want to highlight a couple.

So benchmarking and your market analysis will help give us an understanding of what competitors are doing, but also any opportunities for improvement in the current state. So, things like your five forces step steep, and the catwalk analysis are some of the basically approaches you can do to enhance your benchmarking and market analysis. Business capabilities analysis also helps identifies gaps and allows us to help prioritize those. Business Model Canvas is another good tool to use when you're modeling or analyzing the current state because it provides an understanding of the value proposition so What value are we providing to customers? And what do we want to provide to customers. This is cases capture information regarding the business need and the opportunity.

So that's really a staple for analyzing the current state. Data mining is good because we could get information on performance. financial analysis will help us understand the profitability of the current state or the lack thereof, if there's a problem a financial problem. process analysis helps us identify opportunities for improvement in the current state risk analysis and measurement. Management I'm sorry, identifies any risks that are apparent in the current state, and then your root cause analysis provides an understanding of any underlying causes for those problems in the current state. And a SWOT analysis is a good way to evaluate your strengths, weaknesses, opportunities and threats in order to identify what needs to change Alright, so stakeholders.

So we see that the customer domain should matter expert in user implementation subject matter expert, operational support project manager, regulators, sponsor, supplier, and tester are all involved. But I'll just highlight a few of these. Your customer is a person that uses the existing system. So they might have some input into the current state, your domain subject matter expert. Obviously, they have expertise, as well as the implementation subject matter expert. Your end user directly uses the solution so they might have some input about it as well.

The regulator might inform you or the team of regulations that apply to the current state and catch The supplier is an external influencer because they can help us achieve additional capabilities. And your tester might be able to provide information about issues with the existing system that might need to change for your output or your analysis of the current state is the current state description. So, this helps gives us some context of the Enterprise's scope, capabilities, resources, performance, culture, dependencies, and all these other things in relationships between these elements. So this can be documented in a couple of different ways. Um, you know, it can be a process map, it can be a write up. It can be like a side path diagram.

So there's a few ways you can you can document a current state description, and then your business requirements, right. So this identifies the problem. The opportunities or the constraints that had been defined based on the understanding of the future state. So your business requirements are usually represented in your business case, or even a, you know, Project Charter, that's not really a document that gets mentioned in bapak. But in a practical setting, you might, you know, document that in a project charter. So defining the future state, this can be a little complicated at times, because a lot of the times we don't know exactly what the outcome is going to be.

It can be difficult to navigate, or to steer the stakeholders through that. But the purpose of the funding the future state is really just to determine the necessary conditions that actually meet the business need. And so we know that if something is purposeful We need to have some type of definition of success. What does success look like for this particular change. And so that's what defining the future state is really all about. Because we want to make sure that the future state is well defined So, and also that achievable.

And that is achievable. So, you know, the resources that we have available now aren't strained, and also that the key stakeholders have a shared understanding of the overall outcome and that there's a shared vision of what the future is. So when we're defining our future state, we want to make sure that we're defining and a level that allows for competing strategies to be assessed, right. So there's usually multiple strategies that will allow us to meet that need. So when We're doing this we're going to be comparing different strategies to see which one is going to add the most value. And we also want to make sure that the future state description provides a clear definition of the outcomes that will satisfy the need, and define the scope of the solution space.

We'll talk a little bit more about the solution space, and also allows for value association with the future state to be assessed. And again, again, when we talk about value, it's hard to talk about value. But we'll talk a little more about some ways to make potential value a little more meaningful. We also want to make sure that the preacher state enables consensus to be achieved among the stakeholders as far as decisions that are being made. So one thing to note about the future state is that it describes new remove and modify components, processes or systems right throughout the enterprise. So What I usually like to do is, you know, I'll have a process model of the current state, a process model of the future state.

And then also another process model that highlights things are getting removed, things that are being added. So that that there's a clear understanding of the changes that are being made. And so changes might be needed at different levels or different components. So changes might include business processes, functions, lines of the business, staff competencies, knowledge and training facilities, desktop tools, organization locations, applications and Systems Technology, data and information. So there's a lot of different elements that can be included and an organizational change. So, like I had mentioned earlier A description of a future state might include some type of visual model, and also text to show the scope and the boundaries and details really want to be able to demonstrate the outcomes of the change and maybe include some specific metrics as early as possible as we can throughout the project.

And so whenever we talk about changes that are predictable, we are going to be working together information in order to make the best possible choice amongst potential options. But if the future or the value is difficult to predict, we're basically trying to create a future state that identifies performance measures and with some type of agreed upon value and also something that the the organization can actually support right. So we Want to enable the team to explore multiple options? Alright, so our input is really just our business requirements. And we know that those are their problems, opportunities and constraints that the future state will need to address. And so our task is actually defining the future state.

Our output is going to be all these three, which includes business objectives, future state description and the potential value. So this is an important section here. During the exams, you you probably need to know the difference between goals and objectives. And goals are much more long term They are also usually qualitative. So, you know, they're not really measurable just yet. It's really like an overarching statement of what the organization is seeking to establish or maintain.

So here's some examples. Examples of a goal would be create new capabilities, such as a new product or service, increase customer satisfaction, comply with new regulations, and then reduce time to deliver a product or service, right. So very high level statement, those are goals. But then we take those goals and then we break them down into things, much more objectives, and measurable and so when we break them down into things that are much more measurable, that's when we start transitioning into our objectives. So objectives are usually linked to measurable metrics. And so, objectives typically need to follow the smart criteria.

If you've never heard of that, you can have smart goals you can also have smart criteria. But basically smart is what we do to determine whether or not we have a good objective. And so smart is an acronym for Specific, Measurable, Achievable, Relevant and time bound. And specific means that it has an observable outcome, right? So if you can reduce the time of something that has an observable outcome, measurable is tracking and measuring the outcome. So similar to observable, measurable means that we can tie it to some type of metric to determine whether or not something has increased, decreased, improved or something of that nature.

Achievable is something that is testable. So we want to make sure that whatever objectives that we had is something that can actually be testable. So that we can know whether or not it's feasible. And then relevant is that it aligns with our overall goals, visions and missions. So we don't want to just have, you know, objectives that don't go with our strategic overall strategic mission. And then time bound is something that we can define some type of timeframe that's consistent with the need.

So you typically want to include a measurable outcome. So something like you know, increase the number of high value customers in that 30 to 40% age bracket 30% within six months is the meaning of these criteria, right? So your six months is your time bound, you're relevant is because their customers achievable. So your 30 to 45 age bracket, you know, those, that age range is a little typically tends to be a little more affluent than, you know, 20 year olds. Right. So, those are usually your more high revenue customers.

Um, and then we said measurable so right, we've got really wants to increase those numbers by 30%. And then specific, right? So customers between 30 to 40, that are high revenue customers, right, so that's a little more specific. All right, our next element for defining the future state is the scope of the solution space. And so this is Lucius space basically defines the kinds of option. That's the types of options that we're going to be considering when we are investigating these possible solutions.

So, this might include changing organizational structure, capabilities, processes, changing or getting new technology or infrastructure, maybe adjusting policies on new products and services, or even changing the relationships within the organization. So, this is kind of what we talked about earlier when it is possible for multiple future states to meet the needs of the business needs, goals and objectives, then we need to determine which ones need to be considered and then finally come down to a final selection. And your next element and defining the future state is your constraints. So your constraints are basically aspects of the current state. That cannot change. So these are things that need to stay or, you know, persist through the building of the new solution or the future state.

And so some constraints might be budget restrictions, time restrictions, technology, infrastructure policies, limits on the number of resources to use or compliance with regulations. So usually, policies are a source of constraint. So we want to take those consideration when we're looking at are constraints element, feature state. organizational structure, capabilities in processes, technology and infrastructure. And policies are all the same as they were in the default or analyze the current state so I won't go over those again. It's the only thing that's different That you're going to be looking at all of these elements from the context of your future state rather than your current state.

Of business architecture as well. assets as well, we talked about that really the same thing as it relates to your current and future state. Again, these are just the existing resources that need to be increased or require increased capabilities. Or it might be some type of new resource that needs to be developed. Now 1011 these are things that are not talked about in the current state. So when we're defining the future state, we're want to identify assumptions right?

So usually things that are strategic or new. We usually have to make some type of assumption In order to determine whether or not the strategy is going to be successful or valuable. And so when we make these assumptions, we must make them clearly understood. And we also need to communicate them in order so that we can later validate those assumptions or prove them invalid. Our next element is potential value. So a little earlier, we looked at the value scale in business analysis, and now we're looking at the potential value because at this point, we haven't developed a solution.

And so it typically needs to be evaluated to see if that potential value justifies the effort of making that change. And so potential value or the future state is really the net benefit of the solution after all costs have been occurred. So it's really Benefits minus costs is your net benefit or your potential value. And so we always want to make sure that the change results in greater value or greater benefits than the actual cost that, you know, we incurred when we're making that change, or if there was no action taken. Again, when we're defining the future state, we're looking at increase or decreases in value. And when we're looking at that we're going to be looking at, you know, we're going to be considering, you know, external opportunities, from the external influences, any unknown strengths of new partners or vendors and things like that.

Any new technology that's emerging, the potential loss of a competitor, so usually if a competitor leaves a market that sets up an opportunity for us to acquire As customers or any mandated adaption of a change component, so, usually, you know, government agencies or governing bodies come up with new regulations that need to happen. So, those are things that we are considering when we are assessing the potential value of something All right. So our guidelines and tools are our current state description. So we talked about that earlier that was our output from the last task, key metrics and performance indicators or KPIs. These are our performance indicators and metrics and these will be good because this will show us these will be used to basically determine whether or not the future state is actually achieved. So once we implement it, the so let us know Know how successful it is.

So we want to define those as we define our future state organizational strategy. So this describes you know, the path method or approach that the enterprise will take to achieve desired future state. So again, this is something like your mission statement, things like that. So, again your your guidelines and tools you know, you probably won't have a lot of exam questions on them for the CCB NC bap. But it's good to understand how they fit into developing your actual task. Again, your guidelines and tools aren't necessarily required to complete the task where your inputs are required.

Alright, so techniques that might be used when you are defining your future states. So there's quite a bit of them. I'll just highlight a couple Your balanced scorecard is a good way to help set strategic measures for the future state. And then your benchmarking and market analysis is to help you make decisions about future objectives. brainstorming is usually good, depending on how predictable the future state is. decision analysis might be used to look up different states have different strategies or approaches that you might need to consider.

Always want to consider your financial analysis, right, because we want to know for potential financial returns or benefit of any strategy that we have. We talked about our metrics and KPIs that are used to determine how successful the business objective or how successful the solution is and meaning the business objective. Organizational modeling, right that might be helpful when we talked about the organizational structure, knowing which roles and responsibilities are going to be impacted. Process Modeling will help us demonstrate what the future state looks like. And then prototyping might be a good way to monitor the future state option if we have the resources for that. in scope money modeling scope modeling, I'm sorry, helps define the boundaries of the enterprise in the future state.

We also would probably use some type of SWOT analysis to evaluate our strengths, weaknesses, opportunities and threats, and that may be exploited or mitigated by the future state. These are all of the same stakeholders in defining the future state that we discussed and defining the current state so I won't go over those outputs. Okay, so this is where the good stuff happens. So your outputs for defining the future state These are business objectives. So we talked about what the objectives are. Our objectives are measurable, right, and they meet the smart criteria.

And these are basically the desired direction of the business wishes to pursue. And then we're going to have a future state description. So this includes the boundary of the new removed or modified components or elements of the organization, and then the potential value that's expected from the future state. So this might include you know, the future capabilities, the future policies, feature resources, dependencies, infrastructure, or external influences, and then the relationship between them. And then our potential value is basically like the assessment of the benefits that we think the future state is going to have. So this is the value that may be realized by implementing the proposed feature State.

Alright, so assess risks. So this is our next task and strategy analysis. and assessing risk is really where we're trying to understand any undesirable consequences of internal and external forces that could happen to the enterprise, while in the future state or while we're transitioning to the future state. And so we're going to be using these risks to make a recommendation about a course of action. So risk is usually analyzed for any possible consequences. If the risk occurs, we want to know the impact of those consequences.

The likelihood of a risk so is it something that can happen every day on every cut to every customer is or is it rare and in the potential timeframe of when the risk of might occur. I think that's important about assessing risk is that choosing to accept risk is, is something that's possible. So if a risk doesn't have a big enough negative impact, we might just choose to accept that risk. But, you know, monitoring it in some type of way and try to, you know, minimize the impact of that risk. Another thing to keep in mind is that risk is anything that's uncertain, Babrak, considered to be a risk. So, you can have positive risk and negative risk, but Babrak only recognizes the negative consequences of a risk.

All right, alright, so your inputs are your business objectives, which is We talked about that earlier, that's your desired direction to go in, and the future state. We know what our elicitation results are, but we won't confirm results influences from that are internal and external, how those are going to impact the organization. potential value, right, we want to know you know, how he was going to be realized. And then the requirements prioritized. So again, these are inputs, influences internal, external elicitation, results, designs, requirements, both prioritized business objectives and potential value. And our task, again, is assessing risk.

And so our output for this risk should actually be a risk analysis results. And so, you know, for those of you who may not be familiar with that, when we take the course we actually have templates of all of our tangible deliverables. So this is usually documented or represented and maybe a risk registrar or something of that nature to help keep track of the risk and making sure that they continue to be monitored. Alright, so now let's talk about our Oh, wow, sorry. Now let's talk about our elements that are included when we're looking at risks. So again, risk are basically unknowns.

So when assessing risks, there's almost always going to be some type of uncertainty that occurs so ba typically collaborate with the stakeholders to assess risks, based on what we know today are our current understanding of the situation. We also want to impact you know, the or estimate the potential for those risks or uncertain events occurring. Typically, a way to identify risk is to look at historical information, you know, things like lessons learned. Or we can look at the expert judgment of people who are familiar with that type of change with these types of projects or the organization who have basically seen it all they might be able to help identify risks as well. Our next element is our next element in assess risk is constraints, assumptions and dependencies. And so these are analyzed for risk and sometimes manage as a risk themselves.

If they persist so the constraint can be a risk You know, if, for instance, there's a policy that needs to be maintained, it can serve as a risk if we don't have the resources to, you know, meet that policy within a designated period of time or something of that nature. assumptions are always risks until we validate them. And dependencies can be risks as well, because if one requirement is depending on another requirement, if the requirement that's dependent upon is not feasible, that can cause problems for us to meet our goals. So essentially, if constraints assumption and risks persist, basically just restate them as risks, put them in the risk register, and then identify, you know, the, the actual consequences of those risks. Impact value so again, we're looking at risks. From a negative perspective, so what is the negative impact if that risk actually occurs?

So we're basically looking at the severity of the negative impact of value is it going to decrease the value, decrease customer satisfaction, things of that nature. And then you can estimate the total risk from an add an aggregated set of risks. So, if there are, you know, I don't know six risks that could potentially cost $1,000 each, that is a total risk of $6,000 right. So it can be quantified in financial terms or in an amount of time, effort, or some other measurement. So you want to make sure that your negative impact to risk is quantifiable. risk tolerance is another important element for the exam.

Put the CCB and see that there's typically three types of attitudes. So, risk aversion is a person that is they want to avoid risks at all costs, they are unwilling to accept a lot of uncertainty and they are willing to avoid a course of action or per or avoid a potential benefits if the risk is too high. neutrality is a person or the attitude or an organization that can accept some level of risk. As long as once the risk occurs, it doesn't result in a loss. And then risk seeking these are gamblers. These are people that are willing to accept or even take on more risk.

If you are taking if you know that there's a higher potential return or a higher potential value. So we know we knew your stocks Things like that, that these people are more risk seeking. And regardless of the attitude that the organization has about risks, you typically are always going to address the highest level risk regardless of the risk tolerance. So, whatever risk is going to have the most negative impact or that is most likely to happen, we will address that in most cases. And then our next element and assessing risk is a recommendation. So, based on our assessment of risk, we need to make a recommendation on a course of action based on you know, the organization's attitude towards risks, so, you know, if they're risk averse, neutral or risk seeking will make recommendations such as Yeah, go ahead and pursue that change.

But also, you know, invest in reducing the risk. Or, you know, we might say hey, you need to identify ways to manage and optimize opportunities or positive risk. Or we can say, Hey, we are risk averse, we do not want to pursue that benefit or change at all. Or also you can say seek out ways to increase the benefits of the change to outweigh the risk. So typically from you know, top down, Oh, another one would be pursued the benefits of the change regardless of risk. So from the top, these are our most risk seeking down to our most risk averse responses.

And so whenever we have risk, you always want to make sure that we have some type of action Plan usually want to designate a stakeholder to monitor that risk. And as well as the consequences of that risk occurring. So a part of the recommendation is to have an action plan for those risks. And some tools are business analysis approach to business policies, change strategy, current state description, future state description, which we talked about. And then identify risk, right. So these can be a starting point.

For more, you know, a starting point might be if we got something from, you know, a lesson learned or somebody's using their expert judgment, but then we take that as a starting point and then dive deeper into it. And then, you know, we do a full blown risk analysis and then we have our risk analysis results from elicitation activities or you know, previous business analysis experience. Other another guideline, I'm sorry, is your stakeholder engagement approach from way back when and that basically just helps us identify, you know, groups that we need to have involve in order to assess the forces that might impact risk. All right. Lots of techniques you can use when you're assessing risk, I'll just talk about a few. brainstorming might be used to, you know, identify potential risk in a collaborative setting.

Your business case is good because it usually captures risks for each alternative change strategy. So every so if you if there are three, potential change strategies, you might have three separate business cases. And all of those business cases should include risks. The potential risks of execution. And then your financial analysis is, you know, again, we're always trying to understand the potential effects of risk on financial value, right? financial value is a big impact has a big impact on the overall benefit or financial value, or I'm sorry, potential value.

And then our lessons learned might be used as the foundation of past issues that could be risk in the current event. Risk Analysis and management is used to identify and manage risks. And then root cause analysis might help us identify the underlying problem that is creating a specific risk. All right, so most of the stakeholders listed here are really just providing input. Your project manager helps assess risk because the project manager Is chiefly responsible for managing the overall project risk. Whereas the business analyst is responsible for monitoring the solution risk.

Your regulator also might identify a risk that's associated with adherence to laws, regulations or rules. Your sponsor really just needs to understand the risks. And then your tester really identifies risk from a validation and verification perspective. All right, and so your output here is your risk analysis results. So this is really just an understanding of the risks that's associated with achieving the future state and the mitigation strategies that should be used in order to prevent them reduce the impact of those risks or reduce the likelihood of those occurring. So this is information but it also is a delivery.

Which could be you know, your risk register. Alright, so now we're looking at the change strategy. So this is the last task of the strategy analysis. And the change strategy is really just the plan of getting from where we are today from where we want to go. So the purpose of defining the change strategy is really to define and develop and assess alternate approaches to the change and then select a recommended approach. And so when we are doing this, it's usually best when you have your future state and your current state defined, and he also wants to define them in using the same process or strategy So that you can easily compare them.

And you usually describe the change in terms of the context of the change, any identify alternate change strategies, the justification for why are particular changes needed, what the investment of resources is required to move towards the future state, how the enterprise will realize the value key stakeholders and then the transitions along the way. So, these are typical things that you want to include in your change strategy. And so, usually, your change strategy would be included in your business case, your statement of work or some type of enterprise strategic plan. also involves identifying several strategies, but again, like I mentioned, because there can be multiple Ways to meet the need, but you, you know, define a chain strategy for all of those and then you compare them to ultimately select the one that has that is going to present the most value. Alright, so your inputs are your current state description, your future state description, your risk analysis results and your stakeholder engagement.

So none of those are new. Password performing is the finding the change strategy. And so I'll put here is going to be our actual change strategy and then our solutions scope. All right, so elements. So first element is the solution scope. So we know that we're going to have multiple solution options that we need to evaluate.

And then we're going to be trying to identify the best solution approach to justify the change. But the solution scope really defines the boundaries of the solution. So basically, you know what new technology, we're going to be doing things like that. But we want to describe it in just enough detail to allow the stakeholders to understand the new capabilities, and also to allow them to have a solid understanding of what the future state is going to look like, and determine whether or not it's going to help us achieve our future state goals. And so the solution scope may discuss capabilities technologies, business rules, data processes, different models, or markets, different functions network. workflows events, on business logic might change.

So any of these types of things might be included in our solution scope, basically what's in scope for the solution to satisfy the need. And then it's usually good to have some type of description of out of scope components, because our rule of thumb is to say, you know, and lets us note it as out of scope. It's in scope. All right, so your gap analysis, your gap analysis really is what we use to identify the differences between the current state and the future capabilities. So again, like I had mentioned, it's usually good to use the same techniques to describe both the future and the current state so that it's easier to do a comparison between them So what you should see is the gaps that prevent the organization from meeting the business needs that are defined in the future state. And so your gap analysis might again be similar to the things that you include in the solution space.

But it would include processes, functions, lines of business, organizational structures, locations, data, knowledge, training, facilities, staff, things of that nature. Again, what I like to do is, like I had mentioned earlier, sometimes I'll have a current state process map, and then a future state process map. And then I'll have another process map with different colors, indicating things that are being removed things that are capabilities that are being added, so that the stickers have a clear understanding of what's changing. Okay, your next element is your enterprise readiness assessment. And this is important because we want to make sure that the enterprise is actually ready to not only make that change, but that they can sustain the change. And so we want to look at the enterprise readiness from a cultural readiness and an operational readiness perspective.

We talked about culture earlier. So that's the your norms and beliefs, where as your operational readiness, that's things like your technology and, and, you know, processes and things like that. And so the change strategy is a high level plan of key activities and events that will be used to transform the enterprise from the current state to the future state. So these are like steps, you know, hire a new vendor. You know, get licensing for new application or something like that. It's a lot more high level than an actual solution approach.

Again, we will be exploring several different options. And so we want to make sure that, you know, you can come up with those options through some type of brainstorming exercises or conversations with subject matter experts. Ultimately, you want to assess them and come up with the the best approach. And in order to come up with the most with the best approach, the most value approach, we're going to be considering the organizational readiness to make the change major costs and investments, the timeline to make the change the alignment to the business objectives, timeline for realizing value, and then any opportunity costs that could come into play for each of those. And so this is an important concept because your opportunity cost is really the cost of not doing, you know, another option. So a lot of the times if your most valuable approach isn't feasible, right, you can make the most money but you don't have you can't meet the timeframe, you have to go with option B, and that the opportunity cost could be the additional revenue that you lost as a result of choosing option B instead of option A.

And then you also want to include in your chain strategy, the expected benefits costs and the key key components to making your business case. So again, you know, include the descriptions of the potential value the measurement have actual value so that the stakeholders can have an understanding of how those measures would look in the future. So a lot of the times you tie a future metric or measurement to something that exists today. So if you have a current turn time have 20 minutes to process a loan application. You know, your future. Turn time is expected to be 10 minutes, right.

So that's the value we've gained of a reduction in time of 10 minutes. And so our next element is our transition states and release planning. Now most of the time, you're not going to just have one huge you know, change a lot of the times you have to Do several different releases in order to, you know, make incremental changes for the overall project. And so your release planning is really concerned with determining which requirement is going to be included in which release phase or iteration. If we're practicing adaptive or agile, we know a lot about release planning or sprint planning or iteration planning. And we also use our understanding of the budget deadlines, time constraints and resources and training schedules in order to consider the, you know, the release plans.

And so for us as VA we typically help with implementing these things or getting these things implemented with causing the minimum amount of disruption to not only our business activities, but also you know, The overall project activities, their guidelines and tools, we know a business analysis approaches your design options. So design options are descriptions of ways to satisfy the business need. And each option will come with its own set of changes. And then our solution recommendation. So once we've compared the design options, we're going to be having a solution recommendation, which identifies the possible solutions that can be pursued in order to achieve their future state. And we've got several techniques that can be used for defining the change strategy.

Business cases one, usually your business case has a change strategy embedded in it, and it's used to capture information about the recommended change strategy and potential and other potential strategies. Your decision analysis is what you're going to use to compare the different change strategies to one another. Your estimation is what you use to determine the timelines of each of those activities. financial analysis is considered to understand the potential value associated with the change strategy. from a financial perspective, functional decomposition, right, so we talked about how your change strategy is a high level plan of the actions that need to get taken. But we also need to break those components down in order to develop that change strategy.

And then lessons learned is used to understand what went wrong in the past in order to improve this change strategy. Under a system a might be used in order to determine if there's any vendors or partners that needs to be, you know, incorporated as a part of this change strategy. And they might have Help us implement things. workshops are usually good for developing a change strategy in a collaborative environment. Hey, our stakeholders, usually your customers, the person that may be purchasing or consuming the solution. So they might be involved in the change as a tester, maybe some type of focus group member, your subject matter expert, again, that's the person with all the expertise so they're going to be a good source for developing the change.

Your end user is the person that actually uses the solution. So they might be another source of input. Um, they might also they're usually testers as well. You know, we might use them during the change for whatever reason to help us identify user acceptance and then implement entation subject matter experts. So that's our technical role. Right?

So they usually have some type of expertise in regards to the technical components of the change. operational support, can you help us provide information on their ability to support the feature state right. So if we're making these changes, will we be able to support it in the future. And then the project manager is, again responsible for managing the overall change and planning the detailed activity. So all of our business analysis activities serve as inputs to the overall project plan, your sponsor needs to authorize the overall change and ensure the funding. Remember on the exam, anybody that's the sponsor is the money person, they authorize the funding so the project really can exist without the sponsor.

And then the supplier might help implement the change again, they'd like our vendors or our partners, and then a tester is concerned with the change strategy from the you know, through validating components of the solution. So, they need to understand the change strategy to know, you know, to help develop their test cases. And so our output, plural is the change strategy. Again, this is a high level plan of or approach that the organization will follow in order to guide the change, right. So, this might be embedded in your business case you might have, if you've got multiple approaches that you're evaluating, you might have multiple change strategies, and then the solution scope. So this is the scope of the activities are the changes that need to happen in order to Execute to change strategy.

Alright, so that concludes our strategy analysis knowledge area. I'll talk to you all soon.