So we're going to be talking about the solution evaluation knowledge area. Basically, what this knowledge area looks at is the tasks that we use as VA s to assess the performance and the value of whatever solution that we've delivered to the business so far. And also any type of recommendation to remove any barriers or constraints, that's preventing that solution from meeting its full potential. So one of the things that you might notice as we start going through all the activities in the task is that some of those activities are pretty similar to some of the tests that are in the strategy analysis and requirements analysis and design, definition knowledge area. But the thing that's really different about the solution evaluation knowledge area, is that there's an actual solution here that's in existence. So while the others aren't, you know, they're more theoretical at that point.

During this now you have something tangible that we can test and kind of evaluate. So, um, there's various stages. So there's three key points that you can perform solution evaluation, you can do that in the form of a prototype, or proof of concept. So that's something that might be working but is maybe a limited version of the solution. Or you could do a pilot or a beta release, which is something that's kind of like it's a limited implementation, it's sometimes it could be full implementation, but to a small group of people. So it really depends on how you want to execute that pilot or that beta release.

A lot of the times what you do is you release it, and then you work through any problems that come about through that small group of individuals. And then an operational release. That's usually your full release or some type of partial release. That's a little more functional. Yes, so you can do solution evaluation in the form of a prototype, a pilot or a beta release, and also your full on operational release. And sometimes you might do a combination of these right, you know, anything that allows you to make assessments and test things, and run experiments is really what you're looking at, in order to do your solution evaluation.

And so we've talked a lot about the business analysis values, value spectrum. And so now when we're at the solution, evaluation, knowledge area, that's where we're starting to see more of that actual value, right? So we're looking at the proof of concept, the beta testing or the full release to where we can actually start measuring things. And the knowledge I'm sorry, the tasks that involved in this knowledge area include measuring solution performance, analyze performance measures, assess solution limitations, assess enterprise limitations and recommend actions to increase solution value. So, the measure solution performance is really just, you know, determining the most appropriate way to assess the performance of the solution. So this is where we're determining the KPIs looking at the goals and objectives and things like that.

And then analyzing the performance measures is where we're actually trying to make something of the information. So we're actually examining the information in regards to the performance in order to understand you know, how successful it is or the actual value that's being delivered. And we're going to have some gaps usually. So when we have those gaps, we're going to be looking at assessing the solution limitations, where we're investigating issues within the scope of the solution itself. And then as Assessing enterprise solutions are limitations. Rather, we're in, we're investigating the limitations outside of the scope of the solution, which basically means we're looking at the limitations of the organization and the business itself, something that's preventing them from utilizing the solution to its full capacity.

And then we'll make a recommended action to increase solution value by identifying and defining actions that the enterprise or the business needs to take in order to increase that value. And so, the core concept model, we talked about that and context of every knowledge area. So during week one, when we get the introduction, I went over the core concept models in depth, but what I recommend for the remaining knowledge areas again, is To learn the knowledge area itself, and then go back and apply the core concepts of the concept model to each of those tasks within that knowledge area. So this diagram here shows us the inputs of the entire knowledge area as well as the outputs of this entire knowledge area. We also have the condensed bit more detailed versions for each tasks. But for this knowledge area, your inputs include some type of implemented solution.

They list external and that really just means external to the solution, or external to the project. And then your current state description, your business objectives, and then your potential value. And then we've got our five tasks that we discussed earlier. And our outputs are going to be solution performance measures, solution performance analysis. Solution limitations, enterprise limitation. And then any recommended action that we have.

All right, so our first task, and the solution evaluation knowledge area is measure solution performance. And so this task really the purpose of this task is really just to define the performance measures and use that data collected in order to evaluate the effectiveness of a solution in relation to value. Right. So this is where we're determining KPIs. We're actually measuring, you know, measuring these KPIs to determine, you know, any newly deployed or existing solutions. And a lot of the times if a solution doesn't have a built in KPIs or built in performance measures or We have to basically work with the business to determine and collect those measures.

A lot of times we have to do it manually if there's not something automatic for us to use as a baseline to compare against. And so our inputs include the business objectives and an implement solution. So, earlier we talked about the business objective, and we know that those are our, you know, basically measurable goals for us. So these are measurable results that we basically want to achieve. And then our implement solution is whatever solution that we have implemented so far, whether it's a partial, a prototype or a pilot. So again, our inputs are the implement solution, and the business objectives.

The in the activity here is measure so simple performance. And our output is going to be solution performance measures. And so the elements involved into in that is actually defining solution performance measures. So again, this is where we're determining what are we going to do? Or what are we going to measure in order to determine how effective this product or this solution is. And so we usually make sure that the measures are accurate and relevant, in order to be able to assess the benefits that it's bringing to the stakeholders.

And so we might look back at a business case in order to look at goals and objectives, or any business processes or things like that, to determine measures, right, like if something is in regards to applications, right, we're going to be measuring turn times or the number of defects or something of that nature. And so these solution performance measures can be qualitative or quantitative. So quantitative measures are things that are numerical. So those are things like KPIs turn times, things that are accountable, involving amounts, like the amount of money that it takes to do something or the amount of time it takes to do something right, or rate. Qualitative measures are things that are a little more subjective, like attitudes, right? So if we were to say something about, you know, simplification, or creating a more enjoyable process, right, those are things that are considered more qualitative in nature.

So these are the perception of how well the solution is meeting a need. In our second element is a validate the performance measures. So we want to make sure that the things that we're measuring are actually useful. for validating performance, right, so we want specific performance measurements that actually align with the high level measurements, right? So that align with our goals and objectives. And usually, we would seek the sponsors approval, right.

So the sponsor is often the person that we get this information from. But a lot of the times, it might also be a subject matter expert or some person with, you know, designated authority to provide that information to us. Okay, and then we're going to collect our performance measures. So this is where we would do some type of statistical sampling and collect this information, right. So we're going to start calculating and things like that. So things that we're going to consider are the volume and the sample size, because we don't want the sample size to be too small.

Because if it is too small, that might skew the results, right, and we might get a good, good enough range to make a good judgment. But, you know, a larger sample size would provide us more details and more information. But it might not be practical to get so we have to come up with a balance for these two. I did the frequency and time you know, usually things that are more Well, I'm sorry, frequency and time is basically how often we're going to do something and then when we're going to do it. So that might impact the actual effectiveness of the outcome, right. So if we're doing something when you know, there's more people or it's a busier time during the day, those are things that we're going to have to consider as well.

And then the currency is really just making sure that we're using the most up to date information because usually more recent data, or recent information provides, you know, is usually more representative than anything that's old or antiquated. Okay, so our guides and tools, so guidelines and tools. And so for any of you who are new to these sessions, I had mentioned that the guidelines and tools are, you know, nice to haves and they're more optional, whereas the inputs are things that you're going to want to be more familiar with, because those are the things that we really have to have in order to start a particular task. Now, this particular activity the guideline is the change strategy, which is you know, what our plan is to implement this potential value. The future state description is giving us the boundaries of the proposed new removed or modified components of the enterprise.

So how is the organization going to change as a result of this new solution? And then, requirements that are validated are Guide. And then also the solution scope, which is really just the boundaries of the solution. And there are several techniques here that we would use to, to measure solution performance. I'm just going to call out a few of them, which might be your acceptance criteria, which you might use to define acceptable solution performance, as well as benchmarking and market analysis where we might see you know, how other organizations define, you know, measures and what's acceptable to them. A business cases where we would get our, you know, business objectives from right and any performance measures that were documented at that point, a focus group might be helpful for providing some type of subjective assessment, right, some insights and impressions of their solution performance.

We might use observation where we're physically shadowing someone to get feet Back on perceptions of the social performance, or we could do a prototype to simulate a new solution at an earlier stage to see how the performance measures can actually be determined. And then we might do some type of survey or questionnaire to gather options. I'm sorry, opinions and attitudes about a particular performance solution. And some of our stakeholders that might be involved are the customers who would provide feedback. your domain subject matter expert would also provide potential measurements and feedback. An end user would also provide some type of reviews and feedback as well since they're going to be using the solution.

The project manager is another person that would be involved from a scheduling and a task performance. You know, a minute And scheduling perspective. And then the sponsor, like I had mentioned early, they're responsible for actually approving the measures that we use to determine performance. And then a regulator might have some type of prescribed constraints or guidelines that we need to incorporate into the solution performance measures. And so the output of measure solution performance is actual solution performance measures. So these are the measures or the measurements or the, you know, the KPIs that provide information on how well a solution is performing, or potentially could perform.

So this isn't actually the results. These are just the things that we're going to use to make those measurements. Our next task is analyze performance measure. So now this is where we're going to actually do something with those measures right. So this the purpose of This task is actually to provide insight into the performance of the solution and relationship to the value. So, you know, we've collected the measures in the measure solution performance.

Now it's time to do some type of interpretation or synthesis to that information in order to come up with an actionable plan to move forward. So in order to do this, we really need and we being business analysts need a thorough understanding of the potential value. And so we can come up with that by looking at goals and objectives, key performance indicators, any solutions, I'm sorry, any risks of the solution? And then taking a look at the risk tolerance of the enterprise and the stakeholders that are involved and then measuring that against you know, the state at targets that are being considered So your inputs include potential value and solution performance measures. So our potential value basically describes the value that may be realized. And then our solution performance measures, those are the measures or the measurements that provide information on how well the solution performing.

And now we have to make some type of judgment in regards to that. So again, our inputs are potential value and solution performance measures, those go into the Analyze performance measure task, and our output is actually going to be a solution performance analysis. Okay. So our elements include solution performance versus desired performance. So that's actually you know, the actual versus the plan, right. So we examined the measurements that were previously collected in order to see To assess the ability for the solutions value to be assessed, right, so we want to make sure that what we are actually measuring is sufficient to make that judgment call, right.

So, if the measures are not sufficient to help the stakeholders determine the value, then we need to determine some additional measurements to make or treat it as a risk, right. So we really want to make sure that the measures that we're taking are actually significant for the value that we are measuring. And then risks right so the performance measures may uncover new risks and if we do uncover new risks, we basically need to identify them and then manage them like any other risk. That's all you need to know about that. Trends is an important concept because generally, you want to look at trends of information, rather just looking at one anomaly. So you want to look at data over a period of time, right to guard against anomalies and skewed information.

So if you know one day the system goes haywire, and you all of your information is off, you don't want to just say, Oh, no, we you know, the system's broken, we've got to do something, you want to kind of look at it and kind of monitor it over a period of time, maybe a week or so, to see if it's a, you know, a pronounced and repeated trend, or if it was just something that happened and you just want to monitor it, but you might not have to act on it. And then accuracy, we want to make sure that the performance measures we are looking at are actually valid. In order for something to be considered accurate and reliable, you know, it should basically be something that you can reproduce and repeat. And so reproducible means that another person can reproduce what you saw or reproduce an event.

And repeatable means that the same person can repeat that scenario, or see those results at the same time, so, you definitely I underline those because you want to understand those definitions in the back of the web archive. And then you want to look for your performance variances, right. So that's really just the difference between what we expected and the actual performance or what we had planned for or our desired results versus the actual results once the solution was actually deploy, right. And so if there is a variance there, we want to try to do some type of root cause analysis to determine the underlying cause of this variance and get that figured out. So we've got a lot of the same guidelines and tools or change strategy, future state description. We also have risk analysis results.

And that's really just the overall level of risk that we've assessed from the previous tasks. And then again, our solution scope. So a lot of the same techniques would be used here, right, because the, you know, the activities that you used to measure those performance data points are the same thing you're going to use to analyze them right. So a lot of the same techniques will be used here. You know, I talked about acceptance criteria and benchmarking interviews might be used to, you know, determine the expected value of a solution. And its perceived performance.

The KPIs, that's what we're actually going to be analyzing the solution performance with. Also, again, observation, risk analysis and management, right. So if we identify any type of risks, we're going to have to analyze ended up a plan and develop a plan to actually modify those risks. And then, you know, if we do see that there is some type of variance between the expected results and the actual results, right, we want to do that root cause analysis to determine the underlying cause of that performance variance. And then again, we can do surveys and questionnaires to determine the expected value. Only a couple of stakeholders mentioned for analyzing performance measures and that is a domain subject matter expert who can identify risk and provide insights into the data.

And then a project manager, who again is responsible for the overall risk and may want to be involved in the risk analysis. And then your sponsor can also identify risks as well as provide some insight into the data and the potential value. And so, here our output is actual solution performance analysis, right. So before our output was a solution performance measures and now this is the actual analysis of the information. So this is the results of the analysis of measurements that were collected. And you know, the recommendations that we have to solve those gaps.

Alright, so let's move on. To assess solution limitations. So now that we've said, hey, we've got some performance gaps, now we got to figure out the cause behind these gaps, right? So now we're going to look at the solution itself. And so solution limitations is usually a result of some type of something we did wrong in the actual project itself, right? Maybe poor requirements or poor design.

Something did not jive well, and now we've got some type of solution limitation. And so the purpose of assess solution limitations is really to determine the factors that are internal to the solution. That's restricting it from reaching full value. So internal to the solution means the solution itself. And then the description here is, again, identifying the root causes of underperforming ineffective solutions and solution components. So generally, you know, if the system is underperforming, you're looking at the internal and the external factors.

And they can be looked at at the same time, you can look at the solution limitations as well as the enterprise limitations at the same time. In either of these can be done at any point during the solution lifecycle, right. So, again, you know, if something's in a prototype, or a beta phase, or even a full release a full deploy deployment, you can still look at solution limitations to see, you know, weaknesses in the actual potential solution. And so your inputs here that you need to have include an actual solution that exists, right. And so again, this might be a prototype or full solution. And then we also want to have our performance analysis.

Right. So that's the results of the analysis measures that were collected. And then, you know, any recommendations to solve that performance gap? So we got our inputs again, here. The task is assess limitations. And our output is an identified solution limitation.

All right. And so our elements include, identify internal solution components, I'm sorry, identify internal solution components dependencies, right. And so these are really dependencies that are limiting, you know, the performance right that are within the solution. So these are components within the solution that have to dependencies on other solution components, right? And we have to determine where or what about those dependencies within those components are limiting the performance of something. So it's kind of like you're only as good as your weakest link.

So, now, we have to figure out what that link is weakest link is and you know, how the other components are dependent on that. And then we want to actually investigate the solution problems. And so, whenever again, whenever we see something is a repeated problem, and is producing repeatedly in efficient and effective outputs, we need to perform some type of problem analysis, right. So we always follow trends, we monitor the trends first, and then we follow up with some type of root cause analysis or problem analysis in order to identify the source of that problem. And so, you know, a problem can be anything as simple as not being able to meet a specific goal or objective, or basically just failure to realize some type of benefit that you know, we have projected. And then we're going to make our impact assessment, which is where we review identify problems in order to determine basically the impact it's having on the organization and the severity of it.

And so there's typically three options that we're going to or three paths that we would take for those problems. And that would include Are we going to resolve it? Is it something that we must resolve? Or is it something that we can just mitigate through other activities, or is it something that's small enough for us to just go ahead and accept it because you know, the small change isn't enough? You know, the the work involved in that such a small change doesn't want us to put in the effort, right? So you want to determine if something must be resolved, needs to be mitigated or are we going to accept the risk and sometimes you might have to do additional quality control measures, right?

You might like doing some type of checklist or something to guard around some type of, you know, solution limitation in order to prevent further damage. All right, so we've got the same type of guidelines and tools here are changed strategy, risk analysis results in our solution scope. A lot of these techniques are similar to the last two tasks as well. Our acceptance criteria benchmarking and market analysis business rules analysis Data Mining what might be good to because that might be used to identify different factors that you know might be constraining the performance of the solution interviews could be used to help perform you know, the problem analysis. Lessons Learned is also a good one for for this particular activity because, you know, we might be able to look at lessons learned from, you know, earlier on in the project in order to help us construct some type of, you know, remedy for the solution.

Then risk analysis and management right, so, any risks that were identified, we want to make sure those are identified and managed. Root cause analysis we talked about and surveys and questionnaires can be used to help perform the problem analysis. And the stakeholders involved might be the customer, right? Because, you know, they've got a pretty important perspective on value. So they might be referred to or consulted with, as far as you know, their their opinion on the value. The subject matter experts usually provide some type of input on how the solution should perform, and identifies potential limitations as well.

The end user is the person that or the group that's using this product or this solution. So, they would definitely be able to make some type of contribution on the value that is being had or any type of limitation is having. The regulator would also need to be consulted about any potential changes that we want to make as far as increasing value. And then the sponsor again is responsible for proving the potential value of the solution. So We want to make sure that you know the recommendation that we make to resolve that limitation. The sponsor is okay with that.

And then the tester identifies solution problems during construction. And so your output here are the identified solution limitations, which is really just a description of the current limitations of the solution, including any constraints and defects. So this again, this could be in various states. This could be after we fully deployed it during some type of beta testing or proof of concepts or prototyping. Alright, so now let's look at assessing the actual enterprise and the enterprise limitations right. So now we're looking at the stakeholders or the business.

So the purpose here is really just to determine how the factors that are external to the solution are restricting potential value. So, basically how are the stakeholders or the business? What limitations Do they have that prevent them from reaching full potential of the solution. And so, these might include factors such as the culture operations, technical components, the stakeholder interest or you know, different reporting structures right. So, again, we would, you know, perform our, you know, root cause analysis to identify, you know, how the enterprise limits are creating some type of limitation to value and again, this is something that can be performed during any point of the solution lifecycle, right, we talked about the three different phases, the prototypes, the beta testing, or the full operational solution. And so our inputs here include the current state description, right?

So this is the, the current environment of the solution, including what's the environment like what's the culture like and any internal factors that might be influencing the solution. And then our next input is an implemented or constructed solution. So this is any solution that exists. And then our solution performance analysis is the actual results of the analysis of the measurements that were collected right. So same as before, again, our inputs are implemented or constructive solution, current state description, solution performance analysis. And so these all go into the assess enterprise limitation task and our output here is going to Be our enterprise limitation.

And so, you know, enterprise cultural assessment, stakeholder impact analysis, these are the things that we talked about in our current state analysis. You know, when we talked about the strategy analysis knowledge area, but in context to the solution evaluation, we're looking at the enterprise cultural assessment to look at those, you know, deeply rooted beliefs, values and norms that drive actions of the stakeholders, right? And so we perform the cultural assessment in order to identify whether or not the stakeholder stakeholders understand why the solution exists. So why are we doing this project or why are we making this change? And whether or not they view the solution as something beneficial, right. So do they see the value in making these change?

Do they think there was ever a problem to begin with, right and also To determine if and what cultural changes are needed in order to better realize the value. So, sometimes you have to do some structural changes or some org changes, in order to make a process or a solution more effective. We also want to look at internal and external stakeholders, right, so people in the organization and people outside of the organization. So we want to do this in order to gauge their understanding and acceptance of the solution and assess the perception of value. And also to determine what communication activities need to take place in order to get us where we need to be. And our stakeholder analysis is basically how the solution affects a particular group.

And typically we're going to look at it from one of three View. So we'll say, functions is really, you know, the different processes that the stakeholders use while using the solution. And then locations is, you know, the geographic locations of the state cutters that are actually interacting with the solution. And then we're also going to want to look at any concerns, you know, the issues risk and overall concerns of the stakeholder in regards to the solution itself, right, how are any of these preventing those stakeholders from utilizing or optimizing their use of a particular solution and then organizational structure changes. So similar to a very similar concept to the cultural change, but organizational structure change is the more formal relationships right? So if we have to change job roles, or who reports to who right Because sometimes the ability to adapt to the change can be either enabled or blocked based on the formal and informal relationships.

So we want to always consider both, you know, that org chart, which is the the formal relationship, but also those informal relationships as well. Because the informal relationships might be things like people that have influenced, but might not necessarily have authority, right? Those are things that can be helpful for adopting a solution. And then an operational assessment is a little more dealing with, you know, the processes and tools within the organization. Right. So, do we have processes and tools in place?

Are we adequately equipped to benefit from this solution, right, we're going to be looking at policies and procedures, capabilities, and processes, skills and training needs human resources, and then also our risk tolerances as well. And then the management approaches to that. And then the tools and technology. We've got the same guidelines and tools here our business objective change strategy to future state description, and the risk analysis results, as well as our solution scope. Also, here, we've got a lot of the same techniques, right? So brainstorming might be one that we might use to identify the organizational gaps, or maybe stake our concerns.

We could use interviews for that as well. Observations might be a good way to actually witness how the enterprise or the business is using the solution right to see any impacts. Organizational modeling my identify, if any required changes need to be done to the actual organizational structure. A survey might identify some gaps as well, or we might use a workshop to identify gaps in a more collaborative nature as well. All right, so our stakeholders include the customer who may interact with the organization and how it uses the solution. The domain subject matter expert is definitely going to provide some input on how the organization interacts with the solution.

And then the end user is will be using the solution. And they'll also, you know, be impacted by various components of the solution. So, you know, you would want to have them involved in any type of enterprise limitation evaluation. And we know our regulator may need to be involved to make sure that we actually due to certain laws and regulations, and then our sponsor is, again going to authorize and ensure that we have funding to deliver the solution and provide additional funds that will allow us to resolve any problems that have been identified during that assessment. And our output would just be our enterprise limitation. And that's simply a description of the current limitations of the enterprise or of the business or of the organization, including how the solution performance is impacting the solution.

Okay. All right. So we've got one more task to go. And that's recommending actions to increase social value. And so the purpose here To understand the factors that create differences between the potential value and the actual value, right, so the plan versus actual or the desire versus actual right, and then recommending a course of action to align them. In a nutshell, this task is really us determining whether or not we need to replace the system or the solution, retire the solution or maybe enhance that.

So the solution somehow, and so our inputs include both the enterprise and the solution limitations. Again, our inputs, our solution limitations and enterprise limitations, the task is recommend actions to increase solution value, and our output is actually actual recommended actions to make these enhancements. Alright, so our elements include adjusting solution performance measures. So this is basically making sure that the performance measures that we selected earlier are actually fulfilling the business goals and objectives. Um, because sometimes if the measurements that we chose don't adequately represent that goal, oh, that objective might have to alter that and choose some more befitting goals, some overfitting performance measures. And then our recommendations right, so again, you know, how can we usually the recommendations include ways to increase the solution performance, but sometimes it may be reasonable not to take any action at all.

So some common recommendations we might include might be to do nothing and we usually record In this when the value of making that change is low in comparison to, you know, the effort of executing that change. So if the effort and the risk outweigh the actual benefits, then we'll just recommend to do nothing might have to make some type of organizational change, right. So things like processes and tools might need to be updated or added, we might have to make changes to the organizational structure or different job functions, right. So a lot of the times this includes automatic and simplifying work that people perform, or it might include, you know, improving access to information right so that the people who need the information most can have quick access to it, rather than having to go through some type of middleman in order to get that information.

Other things we could do was reduce complexity of interfaces, right? A lot of the times reducing complexity can increase understanding. Eliminating redundancy, right. So different groups might have common needs, right? So if we try to determine what those common needs aren't kind of streamline that process into one that might be beneficial avoiding wastes, right, we always want to avoid waste whenever we can, by removing activities that don't add value. I'm identifying additional capabilities.

And these are things that are above and beyond those that are identified and the requirements and they might not all waise have immediate value because they might necessarily fit in with the goals and the objectives, but they might have some type of potential to provide future value. And then another recommendation we might make is to simply retire the solution and This might be because the technologies reached the end of its lifecycle. Or maybe some of the services are being outsourced. Or maybe it's just not meeting the goal all together. Other things to keep in mind include ongoing costs. So we always want to look at costs over time.

We also want to look at opportunity cost. And this is basically the potential value that could have been realized by pursuing something else. A lot of the times you'll hear it said, the cost the, you know, the cost of doing the next best activity, and then necessity, again, if something has a limited lifespan, and it just ends then we have to retire it. Because it's a necessity at this point. It's not practical. And then our sunk cost is the money and effort that we've already committed to something that might not have been effective.

So it's really just lost money. So one thing to take in mind is that you don't want to include sunk costs in your decisions, because your decisions should be based on future investments required. And the future benefits, not the previous investments. guidelines and tools are our business objectives, right. So, you know, evaluating and measuring the solution performance. And then the current state description is basically the context within which the work needs to be completed.

And then our solution scope again, is our social boundaries. And so when we're making decisions, we might need a or making recommendations for improvement. We might want to do a decision analysis to determine the impact of having any one potential value or performance issue. Usually when you're making a recommendation on improvement, you want to look at the financial aspect of it. So if financial analysis will be good to look at the cost of benefits, you'll probably have some type of focus group to determine if those performance measures need to be adjusted. Again, organizational modeling to demonstrate, you know, whatever structural changes, we need to have prioritization process analysis, risk analysis and management.

Or we could do surveys and questionnaires in order to gather feedback from a wide variety of stakeholders in regards to the value. And then our stakeholders involved would be the customer, domain subject matter expert who's going to provide some inputs on how to change should be implemented or what needs to change the end user and the regulators might be involved. Again, your sponsor is going to ensure that the funding for implementation of the recommended actions are available. And then our output is simply going to be the recommended actions. To take that need to be done in order to improve the value of the solution within the enterprise. Okay, so that concludes a number of things.

So that's the last task of this knowledge area. And that's also the last knowledge area. So we've completed all six knowledge areas so far.