CompTIA Project+ PK0-004 – Managing the Project Risks part 2

5. Using quantitative risk analysis

We’ve discussed qualitative risk analysis, where we qualify risk for additional analysis. Well, that additional analysis is quantitative, where we are trying to quantify by the probability and the impact of risk events. So in order to do quantitative risk analysis, we have to first understand well what risk events will come into this, what risk events qualify, and then we may quantify them. And what we’re quantifying is probability and impact. This helps with decision making for risk response. It really allows us to see, okay, high probability, what does that mean? Or impact, what’s the dollar amount for that impact? This process has several inputs, tools and techniques and outputs. Inputs the Risk Management Plan, cost Management Plan, schedule Management Plan, risk register, and then of course, enterprise environmental factors and organizational process assets.

Let’s look at the tools and techniques here for doing quantitative risk analysis, data gathering and representation techniques. We need some hard data to really quantify a risk. We need to know, okay, what does a high probability mean? How do you know this risk has a point 93% chance of happening? Maybe you do some modeling techniques where a modeling technique would be we set up a little prototype or we do some test, or we go and look what happened. In other projects, we might also bring in expert judgment. The output of this only one project documents updates. So what are the goals of quantitative analysis? I want to see what the likelihood is of reaching project success. So an overall likelihood of the project being successful, or you might have the likelihood of reaching a particular project objective like time cost or scope project risk exposure.

 So what’s the overall risk exposure for the project? And that helps us to determine the Contingency Reserve. The Contingency reserve is an amount of money that’s set aside only for risk events. We want to identify the risks with the largest impact and then also to determine some realistic time, cost and scope targets. So we call into question our estimates to make certain that those are reliable, even if certain risk events happen. Some tools and techniques here for performing quantitative analysis, we interview stakeholders and experts. So we have to get in the field and talk to people. Risk distributions, we have some high probability risk, some low probability risk. We also have some risks that may have a very large impact, but we have risks that have a low probability.

So what we’re doing here is this risk distribution is we are offsetting risk events, and we’re going to look at that in more detail when we create the Contingency reserve. Now, sensitivity analysis is a way of looking at each risk event independent from all other events in the project. And we say, what overall effect will this risk have on our project? So it’s a way of kind of isolating rather than saying in combination, this helps us define the expected monetary value. What is this risk going to cost me based on probability and impact. I’ve already mentioned modeling and simulation. So the idea here is we create kind of a prototype or we do some testing to get a true understanding of probability and impact. And then again you may go to expert judgment. As I mentioned, sensitivity analysis.

We look at each risk event independently of others and that helps us to find the risks that have the most potential impact on the project. It allows us to measure and examine uncertainties. Sometimes a tornado diagram it looks like a tornado is often used with sensitivity analysis. Now the probability impact matrix is the same approach that we saw in qualitative analysis. However, with quantitative we’re going to use a cardinal scale. We’re not going to say high, medium, low. We are going to say zero, 93. 90, what have you. This helps us identify the risk exposure for the entire project. The sum of our risk exposure, actually the sum of the expected monetary value leads to the contingency reserve and then you’ll see in a moment this allows us to hedge our bets that some risk events won’t happen while some probably will.

So this is a probability impact matrix for quantitative analysis. Very similar. We have our risk identified in the first column and then based on our analysis we have probabilities of the events happening. So 60%, 20% and so on. And then we have the impact of each risk event. If risk A happens it’s going to cost our project $10,000. If risk B happens it’ll cost our project $75,000. Now look at risk C. Notice its impact is 25,000 as a positive. Remember that not all risk are negative. We could have positive risk events and then on we go. The risk D, if it happens it’s going to cost us 85. Now if we take the probability times the impact we will create the expected monetary value. And that’s what that symbol means there at the top, the e x dollar sign V, that’s the expected monetary value, the worth of that project based on probability and on impact.

So on risk A the expected monetary value is negative 6000 and then B is negative 15,000. C, because it’s a positive risk, has a very low probability. But a nice impact is $2,500 and then D is negative $34,000. Now if we sum up our expected monetary values it’ll be negative 52,500. That is this project’s risk exposure. Now if this project has a budget of a million dollars that probably isn’t a big deal. But if this project has a budget of $200,000, that could be a lot of risk, a lot of exposure. So that ties back to that idea of utility function and your risk appetite and your attitude towards risk. Now the contingency reserve you see highlighted in green there, that 52,500. That’s the amount of money we say that we want for this project to offset risk events.

That if these risk events happen this is about how much money we need. Now, notice if risk D happens, it’s negative $85,000. So if risk D happens at negative $85,000, that’s considerably more than what we have in the contingency reserve. That little unease that you feel, that’s your utility function. That’s your tolerance for risk. So the probability, though, is only 40%, but its impact is negative 85. Now, look at risk A, all right, there’s a 60% chance of it happening, and if it does, it’ll cost us 10,000. So that tells us, okay, well, that’s not too bad. 10,000 out of our 52. What we’re doing here is we’re kind of hedging our bets that some of these will happen and some of them won’t. And then it allows us to gauge our tolerance for risk. So let’s go back to risk D. If risk D is early in the project, $85,000. If it happens, only a 40% chance.

And we’re going to know if it happens within 30 days of this year long project. So if we can get past that risk event early in the project, we’ve cleared the hurdle. It’s not going to happen. Our probability was right, so we had a 60% chance of it not happening. We just saved $85,000 on that event. We also have in our contingency $34,000 for the remainder of the risk events, in addition to their expected monetary value. So the idea would be we would say, okay, when will these risk events happen? What’s the probability and what’s the impact? And that lets us work accordingly.

Now, risk B might come at the end of the project. So risk B, even though it has a low probability, a pretty serious impact, we might be thinking, all right, if we can spend maybe $20,000 to eliminate risk B, it would be so much better for our project because it comes at the end. It’s a crucial risk event. So this is the analysis here. It allows us to reason and to think about what risk response should we apply and how much is that risk response going to cost us in proportion to the impact of the risk event and the timing of the risk event? The results of quantitative risk analysis, where we have a probabilistic analysis of the project, what’s the probability of achieving time and cost? We have a list of quantified risk, and it also allows us to look for any trends in quantitative risk analysis.

6. Responding to risk events

Risk events need a response. Now we have positive and negative risk events. Recall that a risk is an uncertain event or condition that may have a positive or negative effect on the project. So positive risk events are known as opportunities. Negative risk events are known as threats. So let’s take a look at how we go about planning risk responses. And this is a project management process. So we have inputs, the risk management plan and the risk register, our tools and techniques. We have strategies for negative risk, strategies for positive risk, contingent response strategies. And we’ll look at that in one moment, expert judgment. And then the outputs. We have project management plan updates and project documents updates. So negative risk, these are the ones that are easiest to see.

So some negative risk here, avoidance that we want to avoid the risk from coming into the project. So for example, this swimming pool is very complex and we’re a construction company and we tell the homeowner that we’re just going to avoid that risk altogether. We are not going to install the swimming pool, we’ll leave the space for it, someone else can come install it later, but we are going to install it. So we avoid the risk. Now, transference is where the risk is so dangerous that we aren’t going to do it. We’re going to hire someone else to manage that risk. So in our project, electricity is very dangerous. We are not going to manage any risk dealing with electricity. So we will transfer that risk to the electricians.

Now, the risk doesn’t go away, it’s still there. The electrician just manages that risk for us, that he’s qualified to manage that risk. And then we have mitigation. Mitigation is anything that we do to reduce the probability and or impact of a risk event. So in this example, like you do tape backups of your data, so you’re hoping that your server doesn’t crash, but if it does, you can restore it from these backup tapes. So mitigation, you’re reducing the probability and or impact. Now, positive risk events we have exploiting. We’re exploiting as we know a risk event is going to happen. So we take advantage of that, we exploit it. So an example of exploiting could be that we’re going to get a bonus if we get done on time and we can tell we’re going to have plenty of time to finish, so we even work faster to receive a bigger bonus.

So we exploit it, we take advantage of that. Sharing is where we work with other people and we share an opportunity. So maybe we partner up with someone else, a competition, for example. We’ll work together to gain the reward of this project. And then enhancing, we could also use enhancing, just like I talked about before, and crashing the project to get done earlier. So enhancing is you don’t know if you’re going to get the reward or not, but you hope that you will. So you hire more people to help you get there on time. So you’re making the conditions ripe to finish faster. So that’s one example of enhancing. Enhancing is anytime that you try to make a positive risk event happen, exploiting is you know it’s going to happen like there’s a byproduct or the probability is very high that the positive risk will happen. So that’s the difference between exploit and enhance.

Now the last one that we have is acceptance and it’s good for positive and negative risk. So some things that are risk that you just have to accept, well, there’s laws, constraints, you might get a small discount. So it’s a positive risk. Weather is a great example of acceptance. You just have to deal with the weather. There’s not a whole lot you can do about it. And then force majeure. These are like acts of God, typically weather or fire, things like that, that you don’t have a lot of control over. Forced majure. Contingent responses are when we have a pre planned response. So when certain events occur, this is how we’re going to respond. So an example, could we have a piece of equipment and on this piece of equipment, if the gauge for the heat, on this piece of equipment, the temperature, if it goes above 90, this piece of equipment will shut down.

We just know from experience it just overheats and shuts down and it takes a day for it to be fixed and we can go forward. So we know that if it hits 90, we’re in trouble. So we set a trigger, the contingent response that if this piece of equipment ever gets to 80 on that gauge, we back off and slow it down. So a trigger is any type of a warning sign or a condition of how we’ll do that predefined response. And then our risk register identifies that risk and this contingent response. So we have trigger. Now 90, another term that we’ll throw in here, 90 that we talked about, that’s the threshold. If the threshold means if you cross over this point, the risk has happened. Trigger is the the condition that signals the predefined response. So we have in our risk register, we have all of our risk identified.

Now some risk may have owners identified, like the individual that’s running that piece of equipment we were just talking about. They’re the closest to the work. So that person is empowered to give the risk response of slowing down that piece of equipment. Response strategies. So like I talked about, is it immediate response, like the risk is imminent, so here’s how you respond. Or do we pause the work and meet and think about our best response? So what’s your strategy? So it’s probably based on the risk event will determine your strategy for responding. And then we had triggers which are warning signs or conditions, those contingency plans for how will you react and then you may have a fallback or a rollback plan. So sometimes in it we talk about rolling out a piece of software and if we’d run up against certain problems, we roll that back, that we have fallback plans.

There may also be a point of no return, that it’s a triangular risk that at some point you’re over the peak and there is no going back. It’s like you move from one operating system to another. Some other terms you need to know here about risk. A residual risk is when I give a risk response that may create new risks that are tiny and they’re just kind of hanging around. Great example of a residual risk. We were going to hire that electrician. The risk doesn’t go away, but the electrician manages the risk. By bringing in the electrician, though to our job site, there’s a chance that this individual could fall down the stairs or get in the way of other people or steal some of our equipment. Those probabilities may be pretty low, but they’re residual. They’re just kind of hanging out there and they’re low.

When we have a risk that is on a low probability or a low impact in our risk register, we typically have a section called the low level watch list, that we just don’t ignore these residual risk. We put them on this low level watch list. Now a secondary risk is when I do a risk response. It creates a whole new risk event. So for example, in it, sometimes you can take one action and it solves one problem, but it creates a new problem. So for example, in it, I remember I was on a project and it was a printer pool. There are like five or six printers that you could hit print to and it would come out to any one of the printers. So we were having problems with the driver. So we found a driver that was compatible and that would work with these.

So we kind of patched it in. Well, that driver created a problem and there was a fax board on the services back in the old days and that driver screwed up the fax board. So we had to undo and roll that back and it just created a new problem. So that’s what a secondary risk is. You make one response and it creates a whole new headache. Risk response contracts when we do transference, a lot of times we need a contract with that vendor. And then you may have to justify the risk reduction. And so what this means is an impact, maybe 50,000, but you could do a risk response for about 40,000 and get rid of the risk entirely. So justifying that risk reduction is that you have to spend money on some instance instances to just eliminate the risk altogether.

7. Controlling Project Risks

As your project moves forward, you’ll have to be involved in controlling the risk events. So that’s what this topic is all about, controlling threats, opportunities, and those risk responses you and your team have created. So to control risk events, we’re talking about implementing your risk response response plan, tracking those risk events, monitoring residual risk. Now, residual risk is when we do a risk response, there may be some new leftover risk events as a result of that response. They’re usually pretty tiny, but we still have to monitor those so they don’t blow up in the project. And then we’ll also look at the effectiveness of our risk management process. So we’re looking at the effectiveness of our qualitative and quantitative and also our effectiveness for responding to risk events. Controlling risk is a project management process.

Its inputs, the project management plan, risk register, work performance data, and those work performance reports, tools and techniques to control risk reassessment periodically, go back and reassess the project. Do a risk audit to see are your responses really working. Variance and trend analysis can help you identify risk and send those through qualitative and quantitative analysis, technical performance assessment, examining that reserve analysis. So if a risk event happens and we have money to offset it, how much money does that leave left in the reserve in proportion to the remainder of the risk in the project? What meetings might you need in order to control risk?

Usually in your weekly status meeting is a great opportunity to talk about risk that may be imminent in the project or to check in with risk owners on what risk events have you already passed outputs? You have work performance information, you may have change request updates to the project management plan, project documents, and organizational process assets now risk monitoring and control. I talked about risk reassessment periodically. You have to go back and look at your risk events and see if the probability or impact has changed. A risk audit is just testing your risk responses and the quantitative risk analysis for its effectiveness and accuracy. Variances and trend analysis. Usually when you have a variance, you’re going to be introducing a risk that the project will be late and or over budget.

Technical performance information. How well are the resources performing? Especially you think about the technology. Has the technology changed since the project was planned? Is it performing as you had hoped? Because that can introduce risk events. I talked about reserve analysis. Status meetings are a great opportunity to check in on risk events. Now the results of risk monitoring and controlling, you have work performance information. So how is the project moving forward? Think about status and data on accuracy, hitting target dates, hitting your project budget change requests. You may have corrective and preventive actions. Those generate change requests.

And then you may have to update your project management plan to incorporate risk responses or to deal with a risk that has happened in the project project document updates. You may have to update your work breakdown structure, WBS dictionary, the risk register, all of those types of documents. One important thing to mention here is the issue log. An issue is a risk event that has already occurred. So you may have to update your issue log if a risk event comes into the project and then we have the organizational process assets. So what happened to the risk events once you get past it? Or if a risk event happened, how did you manage it? Because remember, what you document in this project is future historical information and that’s part of organization organizational process assets.

8. Section wrap

Alright, good job. Reaching the end of this section on Project risk management. You now know that a risk is an uncertainty vent or condition that can have a negative or positive effect on project objectives. We plan for risk and then we go about identifying risk. So we look for risk throughout our project. It’s not a onetime activity. We’re constantly on the lookout for new risk events. Once we’ve identified our risk, we add those to our risk register and then that allows us to document those and to track those throughout the project. So that’s part of our risk control. Now, once we’ve identified risk, we do some analysis. Remember the difference between qualitative and quantitative analysis where qualitative is very fast and subjective, it’s not very reliable, but it’s a quick way to gauge the probability and impact of a risk event.

And then quantitative is those risks that have a high probability or high impact that we need to study those in a little bit more detail, that we’re looking for true probability and what’s the actual financial cost, the impact if that risk happens in our project.

Probability times impact gives us our expected monetary value in quantitative analysis and then that allows us to create our contingency reserve. Now, when we’ve identified risk, we often, if not always, create a risk response. And there are seven risk responses. So remember, we had three for positive, three for negative and one for either, and that was acceptance. The three for positive, we had enhancing, we had exploiting and sharing, and then the three for negative, which is something you really want to pay attention for for your project plus exam. For negative, we had mitigation, we had transference, and then we just have avoidance altogether. And then of course, as I mentioned, as we move through our project, we want to do risk control. All right, great job. Finished this section on project risk management.