- Welcome to module 10 part two where we continue looking at the risk theme. And here we're going to introduce the risk management procedure. There's quite a lot here so we don't get through it all but we will look at the first two steps which are to identify and assess risk. And so I should mention there are a couple of steps in our risk management procedure and we think about it in a wheel because we're constantly going through the cycle time and time again as we keep an eye on our risks throughout the project. The first step is to identify our risks, then we assess, then we plan responses, then we implement our responses, and communications in the middle is really important 'cause we're communicating all the time actually but it's worth looking at it by itself. So those are the steps in the risk management procedure, and we're going to look at the identify step first in more depth. There are two parts to the identify set, and first of all we need to identify context. We need to understand here the objectives that are at risk in the project. And this really will depend on every project, every project is gonna be different, have different objectives, but some of you I've met quite a few people who work in organisations where money is really tight. So the cost targets really can't shift. They cannot overspend. So you would be really concerned in that situation about uncertainties, risk that could challenge the cost targets and what could make us overspend. So that would be an important objective for you. Other people that I've trained, maybe compliance or legislative based projects or projects where you have a deadline, time then becomes an important objective that we need to bear in mind when we're thinking about risk. What could cause us to delay the closure of our projects? That's what we need to think about. So we need to first understand the objectives that are at risk, maybe it's cost, maybe it's time, maybe it's one of our other objectives, because there's cost, there's time, but there's quality, scope, and benefits to consider here as well. So this is why we pause to reflect before we continue. We need to think what are the objectives that we are most concerned about here in this project. And that will help us build the risk management approach. So there are a number of influences when we think about writing our approach. And you can see also this funnel of things we've got to think about that will help us write this risk management approach, and let's look at those in turn. There will be a number of customer quality expectations and some of those might be realistic or unrealistic. So there might be some uncertainty there if the customer doesn't really know what they want as well, so we need to think about that. They might also think about as a customer, they expect us to perform in a certain way, so I want you to think about how that affects us. The needs of the stakeholders might affect how we deal with risk in our project too. Do we have to inform certain people at a certain point when certain things are done. So that would influence who we report to, so write that in our approach. The complexity of the project would clearly have an impact, if it's quite a simple project with not much uncertainty, then we might need to take a lightweight stance on our approach. If it's very complex then we might need to be a bit more rigid and have a lot more transparency about who is doing what and when so it's got to be very clear and written down in our approach. What is the delivery approach? Are we going in house for this, or are we going out of house, we're outsourcing? There can be lots of different uncertainties, and it's different procedures that we're going to have to follow if we chose one over the other is this off the shelf or bespoke? That might well effect our risk approach. We might have made some assumptions, and so are there things that can threaten those and do we need to take those into account and have som extra checks? Exchange rates are something that we've been thinking about while I'm discussing with my delegates recently. Do we need to put extra checks in those for some of our risks being based on our assumptions? And finally your corporate policy standards, et cetera. We need to think about that. In some of the organisations that I train, they're heavily regulated and corporate policy is very clear, we need to deal with risk in a certain way, and that actually makes it quite easy to write a risk management approach on our project because we just use the corporate strategy and just keep it simple. But sometimes you might need to tweak your approach to risk, use the corporate policies and standards, and then you might just have to adapt then slightly with permission in a heavily regulated organisation to deal with the complexities of your project. So those are some influences to think about and you will then by the end of it have, and certainly in complex projects, a comprehensive risk management operation. Everybody will understand how we handle and deal with risk around here. So that was the first part of the identify step, identifying the context and writing our approach. Now we can have a risk workshop, a brainstorm session, and think about the different risks that might occur in our project and we will identify those risks then and put them in our risk register. And Prince2 recommends a particular way of recording risk, they want us to think about the risk cause, the event, and the effect on your project objectives, and I'll just show you this on another slide. And so you can see there we've got the risk cause, risk event, and risk effect, but it might help if we look at that in more depth. Risk cause, what we mean by that is the source of the risk. Are there any potential trigger points that might cause us to either meet our objectives or miss our objectives? And these causes could be internal or external, but they are the source of the risk. The risk event then describes the uncertainty for the risk, can we treat this risk as a threat, it's gonna threaten our objective? Or is it going to help us in some ways, can we treat it as an opportunity? So when we describe the risk event, we've got to say what might happen and whether we think it's a good thing or a bad thing. And then when it comes to risk effect, we need to describe the impact on our project objectives. So I think it might help if I give you an example. The risk cause is that a key team member may leave a team, this is quite common. We don't know what our team members are thinking. We hope they're gonna stay with us. But things happen, they might move on. So they may leave the team, and the risk event then, a threat usually, because we might not then have enough skilled staff to complete the products that we've got to within the time we've got. So the risk effect actually, we might have an effect on cost because we might have to pay to bring someone else in. But the one that I'm concerned about here is time. Maybe this project has got a specific end date so we cannot shift it, and so I'm concerned about the effect on the time objective. The project will miss its target by live date if a key member of staff goes away because we don't have enough skilled staff to work on the products. So there you go. A risk cause, which is the source of the risk, a team member leaving. Risk event, describing the uncertainty, the fact that if they go we won't be able to complete the products in time. And then the risk effect, the effect on our project objectives, we miss the deadline. So hopefully that will help explain what they mean by the risk cause, risk event, and risk effect. We may have various different ways of, I've talked about brainstorming, you can see it on the list there. We could use brainstorming to help identify risk but there are other ways that we could help ourselves fill in our risk register. And the first one is to look at a risk register from a previous similar project because we can look at the lessons learned from that and think about how we can inform our future risk making decisions. So we review lessons from previous projects, if we can get our hands on an old risk register, even better. We might also use checklist or prompt lists just asking us questions that we can go through and they help us think. How stable are our suppliers, what about resources? That kind of thing. And some people even use a risk breakdown structure which is a hierarchical approach. So you start at the top by thinking about the whole project and then you might break it down into different levels asking more detailed questions and it gives you a more detailed view about different component parts within the project. So those are a few different techniques, and those will help us hopefully fill up our risk register with properly expressed risk. Let's have a look at the assess step or second step in the risk management procedure recommended by Prince2. And this also is in two parts, we have an estimate part where we think about probability, impact, proximity of the risk and how that might change over time. So when we are in this assess step in estimating it, we need to know how likely it is to occur, so that's the probability. What the impact is if it did occur, so is it high, medium, or low maybe. Is it going to happen soon or in months time so that's our proximity? And so we'll at least look at those three. And record that in our rest register for every risk. Some of you might well be using red amber grids, red amber green grids even, for this. And you might have it just red amber green or you might have different shades of amber. Three is a little bit simple, five is usually the optimum that is recommended. We also then need to think about how to estimate all of these things, so let's have a look at that. And we are going to then turn to maybe probability and impact grids, and here's one actually that is from our manual where we have a number of risks that have been identified and we don't know what this project is or what these risks are, but I would be fairly concerned about the risks up there in the top right, because clearly they're very high or high in terms of probability and in impact depending on those risks. We've got three risks up there that I'm quite concerned about because they are above the risk tolerance line. I don't know if you can see it there, but it's that dashed line at the top right of that table. Now that risk tolerance line has been set by corporate, that's a project level risk tolerance. And they've put it there, and this would mean if we found a risk up there, above that dotted line, we cannot within our tolerances, bring it down to an acceptable level. So hopefully low or very low probability and or impact there. Somewhere, can you see risk number nine there? That would be where we want our risks to be. But if we can't get it down there from our actions down to an acceptable level, we're going to have to escalate the fact that we have these risks up above the tolerance to corporate or programming customer, and they are going to have to decide what we're going to do about it. So they might actually say no, this project's too risky, we better shut it down. Or they might give you maybe more budget to respond to those risks appropriately, or they may even say thanks for letting us know, good luck, keep an eye on it for us, and just hope it doesn't happen. So there's all sorts of different things that might happen if we did have really serious risks above the risk tolerance line, but it doesn't necessarily mean we're going to be closing down the project. And actually this diagram is a useful point to think about risk appetite. Some organisations that you're working for I'm sure are very risk averse, they don't want to take risk, particularly if human health or life is at risk, they're going to be very risk averse. Their risk tolerance line might be much lower and so they'll be much more interested in hearing about these risks, that's high or very high. For some organisations, they like a bit of risk, and so the risk tolerance level would be raised a bit higher, and so the project manager can just get on with dealing with those risks and they only really need to escalate the really really serious ones to know. So where that risk tolerance line is set will depend very much on the risk appetite of the organisation that's triggered this project. But the idea is clearly that we want to get those risks from the high area down to the low area by expensing some risk responses, but that's a bit later on in the cycle. We are just using this as a technique to assess probability and impact, and they have used words here very high, high, medium, low, very low, and you could, as I said earlier, be using colours for this as well. And there are all sorts of other grids that I've seen in my project related life, so you might have something similar but a little bit different to this. We also have other techniques as well, expected value is where for example, if we think a risk or dealing with a risk might cost 10,000 pounds, but then we thought there was a 50% chance of that risk occurring, we'd actually put a value of 5,000 pounds on it. So that's what they mean by expected value. We could use probability trees and probability trees show the likelihood of different outcomes given different situations. So they're quite fun to go through. And we also have Pareto analysis. And this analysis ranks risks in order in which they should be addressed. So some of you might be using those techniques as well. Whatever technique you use, you're going to have to fill in the risk register with the details of all this. And what's the probability impact and proximity et cetera, how do you think they're going to change over time? We need to put that in the risk register. And then we're going to look at all the risks in your risk register, and we're going to evaluate that. So our second step here in the assess step, we're going to evaluate our overall risk exposure, and it might be for some of you that you actually put numeric value on this, and when the risk exposure is above a certain value, then you have to escalate it to the next level up and then decide whether or not we're gonna allow you to continue the project, or whether or not they'll tolerate it and increase your tolerance. So yes, there are two steps here to estimate and devaluate in the assess step. That begins, and that brings us to the end of this part, or the end of this video because I think that was quite enough, you probably need to go away and have a break. There's an activity next as well, and so we continue the risk management procedure in the next video.