6 Steps to Risk Management EDIT

Hello everyone, I'm Linda Westphal from the Software Excellence Academy, powered by the Westfall team. And today is the 1st of August and we're shifting from metrics into risk management this month. And the first one is going to be a general overview of the risk management process. So we're going to talk about the six steps to to risk management. So let's get started. Risk management is all about being aware of the future, what could happen. And effective managers, effective software practitioners, are very proactive about thinking about the possibilities of the future. What could happen, what should happen, and how can we make it more probable that it's going to happen. When we look at the future, there's two ways of looking at things. We can look at it positively and see the opportunities. If we deliver this product on time and on schedule, we may win the major lion's share of the marketplace and be very successful and make lots of money. Or we can look at it negatively, we don't get it out on time or we don't get it out on schedule and we lose that opportunity. We have negative consequences of somebody else winning the market or getting their product out first or we don't make the profit we expected to. So risk management is the Siamese twin to opportunity, folks. You can't have one without the other. In fact, DeMarco says moving aggressively towards your opportunities means running towards rather than away from risk. So we've got to get in software very good at doing risk management. Because folks, software is a risky business. All the easy stuff was done back in the 70s and 80s and 90s. In the New millennium it's all about very complex software, bigger, faster, and now. So software is getting to be a very risky business. In fact, more so every day. So we've got to be good at risk management. Let's do a quick definition. What is a risk? A risk is simply looking at the future or looking at the possibility that a problem or something negative happens in the future. If it's already a problem, it's not a risk. Put it on the problem list and go deal with it. A risk has some probability of occurring, some probability of not occurring. A risk starts when you make a commitment. You don't have the risk of Acme delivering a poor quality product to you if they're your subcontractor, until you pick them as your subcontractor. You don't have the risk of getting hit by a bus in the middle of the street until you make the commitment and step off the curb. Now you have the risk of getting hit by the bus on the sidewalk. But it's a whole different probability, a whole different risk. A risk ends when one of two things happens. Whack. You get hit by the bus. Acme delivers the poor quality product. Now it's a problem, it's no longer a risk. And it moves from the risk list onto the problem list to go deal with. Or you successfully walk across the street, you step up on the sidewalk, on the opposite side, you've attained your goal. The probability of getting hit by the bus is no longer a problem. Acme delivers a high quality product to you on time, you've met the goal, you don't have a risk anymore. And when you think about risk, you've always got to be thinking about that risk. Opportunity, balance. When we're getting into doing good risk management now, on the risk side, we have the probability the risk turns into a problem and the loss associated with it if it does. On the opportunity side, we have the probability of receiving the reward, the opportunity we're looking for, the benefit and how much that benefit is worth to us. The way I like to describe this when I teach my classes is let's assume you have a 2x4 board. It's 2 inches tall, 4 inches wide, 10ft long, and I put it down in the middle of the floor in a big empty room. And I challenge you all to walk toe to heel across that board without falling off of it. And I'll give you 10 bucks. Now, how many of you are probably going to try it? Think about it. Would you try it for 10 bucks? So let's look at this. What's the probability? Well, what's the problem? First, the problem is you fall off the board. What's the probability you do that? Well, for most of you, you can probably walk toe to heel across a 4 inch wide board, no problem. Me, I've got two replaced knees and haven't had any good side to side balance since I was 30 years old. So my probability might be 90% that I'm going to fall off the board. Your probability may only be 5% that you will fall off the board. I had one gentleman once in one of my classes, his hobby was tightrope walking. He said that's not a risk, that if he can walk a rope without falling off, he can definitely walk a 4 inch board. So again, the circumstances and the probability and the potential loss are going to change depending on the circumstances. Then you got to figure the loss if you do. So what's the loss if you do fall off the board. And don't say 10 bucks because I'm not asking you to pay me 10 bucks. You haven't lost 10 bucks. You just didn't have that opportunity to win 10 bucks. So what's the loss? Well, maybe everybody points and laughs at you if you don't do it. Maybe you twist your ankle, you know, no big thing. It's 2 inches off the ground right now. What's the probability of you getting in the reward? Well, how many of you trust me? Do you believe I'm actually going to give you the 10 bucks? Maybe we'll get Kathy to hold all the money just in case and she'll pay you whatever. And of course, the benefit of accomplishing your goal is the $10, the reward. Now, if we take that same board and put it between two five story buildings so it's five stories off the ground, how many of you are going to do it for 10 bucks? Well, that's absurd, right? What did we change in this balance? Did we change the opportunity? No, we left that at 10 bucks. And you still trust me or you don't. But we obviously changed the risk side. Now, we may have tweaked the probability you fall because you may be nervous, you may be shaky, but what we really lost, what we really tweaked was the loss if you do. Because if you fall five stories, you're going to go splat. So to keep this imbalance, we have to tweak the opportunity side. So if I say, okay, for $50,000, will you do it? And many of you might say, you know, like fear factor. But usually what I get now is can I have a Hornets? Can I have a safety net? Can I have. We didn't worry about risk mitigation when we were 2 inches off the floor, but when the risk or the loss is very, very large. Now we want to attack the perceived risk side. We want to either reduce the probability that the person falls off the board or reduce the loss if they do. Reducing the probability, maybe we train them down on the ground and they practice until they get really good and reduce the probability they fall. Maybe we make the board wider or put some kind of railing on it. Reducing the probability they fall by reducing the loss that that harness or that helmet or the big airbag or net. All of those would reduce the loss if you do. So we want to balance these out because even $50,000, even though we really like to have that, it's not worth the risk of losing your life potentially. So it's all a balancing act that we're going to be doing. Now, risk management is just part of good project management, good product management. Now I say product as well, because your project isn't successful if you don't produce a high quality product that anybody wants to buy. We'll talk a little bit more about that in a few minutes. So risk management is an integral part of project management. If you look at the pmbok, the project Management Body of Knowledge guide, it is one of the process areas of risk management. But it's kind of that opposite side of the coin. In good project management, we're dealing with the general generic risks. There's always going to be some level of staff turnover, there's always going to be some level of requirements churn, et cetera, et cetera. Those generic risks that happen on every project and those are just part of good project management. And a good project manager will account for those with risk management. We're looking at those big hunkin specific risks that are going to make your project considered a failure. You're going to be way over budget, you're going to be way behind schedule. You're going to have a product that's poor quality or doesn't have all the functionality that's needed, or you're not effectively and efficiently using people and other resources, your project's considered a failure. So generic risks, part of normal project management. You're always going to have requirements churn. We assume historically it's been 15%. It's going to be 15% on this project. We account for that. The risk is more than we expect. It's going to be more than that 15%. In project management, we're looking at the big picture, planning all the details. In risk management, we're focusing in on the big problems that might occur and planning on how we're going to deal with them through containment and contingency plans. In project management, we're looking at what should happen and how can we make it happen versus what could happen to us and ways of minimizing the damage if it does. Project management, we're planning for success. Risk management, we're planning to deal with the potential failures, hopefully keeping them from happening or at least minimizing the loss if it does. Now, there's many different types of software risk. There's the technical risks, brand new processes, brand new tools, overly complex software. Of course, all your product risks fall under technical as well. You have the risk of delivering a poor quality product or a poor reliability product or a poor usability product or whatever a Product that's hard to access. So all your technical risks, then you have all the managerial risks of overly compressed schedules or not enough people or other managerial issues, of loss of communication, whatever, and you have your financial risks. In this day and age, the world economy, and who thought of COVID right to plan into your projects, weird things can happen that can be disastrous financially to your projects. There are contractual and legal risks. I used to have a contract that said if we did not meet a certain reliability level, we owed them money back for every minute of outage over a certain number of minutes we had to pay them money. There may be legal risks. For example, if you're in a regulatory industry, there may be risks associated with not meeting the regulatory requirements. There's personnel risks. Again, you're going to have normal staff turnover. But if you have more than you expect or if one of those linchpin key people leave, you may have also people risks about, you know, George and Sam don't get along and it's causing a lot of disruption and morale problems on your team. And you can have other resource risks. There might be issues with the test bed not simulating the real world well enough. There may be risks associated with equipment being available on time or not having enough capacity or bandwidth on your network, whatever. So there's lots of different types of software risks. So the first step in the risk management process is to identify your risks. If you don't know about them, you can't do anything about them. You know, nobody probably predicted Covid, the virus that's going around. We didn't have plans in place to deal with that and we ended up scrambling. We want to minimize the amount of scrambling and firefighting we have to do by identifying these and dealing with them. So we're going to start by identifying them. Some basic goals here to prevent the unpleasant surprises, the disasters, the fire drills, because risks exist whether you acknowledge them or not. The easiest way to get hit by a bus in the middle of the street is to not acknowledge the risk or identify it and look both ways before you step into the street. So if you ignore the risks, it's going to lead to unpleasant surprises, folks. Like getting hit by the bus. I've seen people that just do a contract with Acme and six months later expect Acme to deliver a high quality product on time with all the functionality. Folks, that may not be realistic. You got to manage the supplier risks or you may end up with surprise at the last minute. It's poor quality surprise at the last minute. Oh, wait a minute. It was due today. No, we're not going to be done for three more weeks, whatever. Or as Gilb said. I love Gilb's principle. If you don't actively attack your risks, they're going to actively attack you. Another goal is to get everybody in the project involved at all levels, because testers will see risks that project managers can't see. Even customers will see risks that the quality people won't see or the software developers won't see. So we want to get everybody on the project and create mechanisms that they can identify risks. They can communicate risks to the project people. Of course, another goal is to identify it while there's still time to take action. If you're inches away from the bus when you notice it, it's too late. It's already a problem, folks. If it's got 100% probability of happening, even though it hasn't happened yet, it's still a problem. So we want to identify the risks while there's still time to, to make decisions about not stepping off the sidewalk or not picking Acme as our subcontractor. Again, not making the commitment avoids the risk. We want to be communicating about these risks with everybody that needs to be communicated with, that needs to be involved. We need to communicate to management, to the people that are going to be affected if the problem occurs, whoever is supposed to be analyzing the risk or mitigating the risk, whoever's going to be tracking the status of those risks for us, which means that part of risk identification is not only identifying it, but capturing it in some kind of format that we don't forget about it, that we can keep it through the project, etc. Now, of course, obviously the primary goal of risk identification is to turn your unknown risks into known risks. But when you do this, folks, don't get obsessive. There's all kinds of those little trivial risks that are just part of normal project management. Think about the risks again, that would make your project or your product considered a failure. And there's many techniques for doing this. You can go interview various people, all those people on that list I showed you about who you need to get communicating about risks. Or you can bring a team together and brainstorm. Now that'll get you your initial risk list. But throughout the project, things are going to change, surprises are going to happen, etc. You get more and more information. You can identify new risks. So you need mechanisms for either voluntarily or required reporting when other people identify risks on into the project. For example, our status reports every week that we Gave to our boss had a place for. Did you identify any new risks this week? In effect, the agilist do this in every single daily standup. They talk about three things. What did I do since yesterday, what am I going to do today? And what are my impediments? What are the potential problems that may be standing in my way? Not only problems that have actually occurred, but risks that you need to be thinking about potential problems so we can deal with them before they become disasters. We can use decomposition as we decompose our stakeholder requirements down into technical requirements, down into design, down into code. At each point ask yourself any risks there? Any risks there? Any risks there, there? At the stakeholder need level you may not realize that this requested need may be unfeasible, but by the time you get to technical requirements there may be a risk there. You can also decompose your project as you go, creating a work breakdown structure and break things into smaller and smaller tasks or stories into epics into smaller and smaller stories, whatever that decomposition, just keep asking any risk there? Any risk there? Of course there's assumption analysis. Anytime you make an assumption, ask if there's a risk. Assumptions are not facts. They're the best guess at what's going to happen. I think this piece of code will fit into one 8k chip on that board. Well, is that reality? No, that's my best guess. Is there a risk that it won't? How big is that risk, etc. At a minimum, look at your critical path through your project schedule. Because if there risks there, your project's going to be late if they turn into problems. Another way of identifying risks is have what's called a risk taxonomy. It's simply a risk list of problems that have happened in the past. I always say do that last because it becomes a checklist about whether or not you've thought of everything. If you do it first, then all you see is the risks on the list and you may miss project specific risks. So our inputs here into risk identification are our project plans, our requirements, our design, our code, all of our process assets, for example that risk taxonomy or things historic information about what's been risky in the past, your organizational and environmental factors, for example, do you have enough people? Are those people trained appropriately? Are there any cultural issues, et cetera, et cetera. And the outputs are that identified list of risks and information about those identified risks, their statements and any data you've collected. So the first step, start here is to identify your risks. Out of that comes the risk identification list and Then we go into the second step of the risk management process, analyzing your risks. The goal here is to look at the context of your risk and understand it. We are talking about putting me out on the board. One of the conditions might be that it's raining outside or that it is icy on the board. Contributing factors, my two knee surgeries and my replaced knees constraint. I have to go heel to toe across the board events. Yesterday was my 65th birthday and I partied Hardy until 2am and I'm a little tipsy still. No, that's just a joke. It wasn't my birthday yesterday. Project Inter Relationships There may be some issue on another project. For example, I'm expecting Cindy to move over to my project by the 1st of September. But Cindy's current project is running late. That's going to be a risk for my project potentially. So I'm going to explore all of this to understand what what may make the probability of the risk turning into a problem higher or lower the loss associated with it. If it does higher or lower. For example, the board being on the floor, we didn't even worry about the loss. But when the board is between the two five story buildings now the circumstances of are going to make the risk much larger because the loss is much larger. So what we want to do is take all that context information and determine, like I said, the probability and the loss and then on the goal side, the opportunity side, the benefit and the probability of getting the benefit. So this is all a probabilistic analysis, folks. How much of it do we do? How formal do we get? Folks, we can go from mild to wild here. If it's obvious this is a big risk and that's a tiny risk, folks. Rank them high, medium, low, stop, you're done. That's all you need to know. If that's good enough to do reliable risk planning and make good decisions, do it. Do the minimum you can get away with. Of course you can go all the way to very quantitative mathematical models like doing Monte Carlo techniques where you're looking at probability curves and you're looking at the shape of that curve and the total probability across that curve and build these, you know, do calculus and do probability statistics based on the shape of the curve and things. But most of us don't do that. Don't worry, you don't have to get that high. But whatever, do just enough Analysis is a way of saying that. So our goals are to estimate the probability. Now if we get really good and we're doing more sophisticated techniques like I said you may actually be able to assign a probability. There's a 90% chance Linda's falling off the board. There's a 10% chance that Simon's going to fall off the board. If you can get away with doing a more qualitative do it, you know, high, medium and low. I've just done a couple of examples here. Almost certain, very likely, likely, unlikely, highly unlikely, or in a lot of cases, we just sign an index to it on a scale of 1 to 5, 5 being almost certain it's going to turn into a problem. We're going to rank our risks. We also want to look not only at the probability, like we said, but also the loss if it happens. And there's many different things we have to consider when we consider the total cost of the loss. First of all, the cost, the money we're actually going to spend to deal with the problem, or the effort we're going to spend to deal with the problem. There may be losses associated with schedule slippage, there may be losses associated with technical difficulties. You're not going to sell as much if it's not a usable product or user friendly. You might not sell as much if it's not as reliable. And of course there's all kinds of other impacts. There might be loss of goodwill from your customer or loss of customer satisfaction, those kinds of things, loss of market share. And you can put quantitative values or qualitative values to a combination of all of these. And again, you can do this quantitatively, say it's two weeks of lost effort or, or it's $2,000, it's going to cost me versus $10,000 or a million dollars or whatever. Or again, you can sign some kind of qualitative loss statement or loss index to it on a scale of 1 to 5, scale of 1 to 10, then you're going to determine risk exposure. And folks, risk exposure is simply probability times loss, taking them both into consideration to establish how risky this risk is. And if you're doing things quantitatively, you can just multiply probability times loss. 10% of 700k is 70k. And you can add all of this up. If you're doing more qualitative, you may want to make a table. If it's catastrophic and probable, it's high, or maybe very high, whatever is appropriate to you. If it's marginal but probable, maybe it's a medium high and so on. And you put a table together so you can rank your risks on your list, or we can again multiply if we've done it on an index a 5 and 5, 5 times 5 is 25, etc. And we can use those numbers to rank our risk exposure. So the inputs into risk analysis were our identified risks and the information we collected when we identified those risks. And the outputs for each risk. We now have information about its context. Folks, write that down someplace so you don't lose it because you may decide this is a very high risk now. And six months from now when you come back to it, you say, why was I ever thinking that was a high risk? Things have changed. So if you don't capture that context information, you may not understand what, why you need to change or redo your analysis. It's probability, it's loss, and it's priority. Now again, we're going to set priority based on that ranking of risk exposure. You may also want to look at time frames when you're doing this. Something that's a medium high risk now may have a higher priority than something that is a high risk, but isn't going to happen for six months. So when you're prioritizing your risk actions, you may want to deal with the medium risks now as opposed to the high risks six months from now. You always want to defer action as late as possible because things may change. That's the whole lean concept of making decisions as late as possible so you can get as much information because things may change. And what comes out of this is a prioritized risk list. So we've identified our risk, gotten our risk list, now we've analyzed our risk, and out of that comes that prioritized risk list of what we're going to deal with first. Now the top part, the biggest risks of all, we may decide to avoid. If selecting ACME is very big, we are going to ignore them. We'll pick somebody else as our subcontractor. Then we've got risks that we want to actually go take action against. We have other risks that we can just accept. So that's the priority. And from that we're going to decide and plan how to deal with each of these risks. So the third step in the risk management process is developing our risk management plans. How are we going to deal with these risks? And our goal here is to look at risk handling techniques and determine what are all alternatives, what are our choices for handling this particular risk. For each of our risks that are high enough, we want to take action against them. Then from all the alternatives, we're going to select the best actions to take one or more, and we're going to plan our containment plans and our contingency plans. So here's my basic checklist as we go through this. Do I even know enough about the risk to be making an informed decision? If not, I might want to obtain additional information. One way of doing that is to defer it till later in the project before I take the action like we talked about. Another way is to come up with some alternative. Instead of, instead of doing Acme as a subcontractor, we can build it in house or we can select some other contractor that may be more expensive but has a better reputation, less risky to deal with. If we do have enough information to make a decision, we can decide, is that risk so big we're not going to take it? Folks, I'm not going to walk the board between two five story buildings for $50,000 no matter how much harnesses and things you've got. Because my probability of falling off 90%, it's just not going to happen in most cases. If Acme is so poor a vendor, you're not going to want to deal with them, you avoid that risk by doing something else. Can I make it somebody else's problem? We do this all the time in software. I remember many times where the hardware had problems. So we did all kinds of fault checking in the software. For example, in telecom, we were constantly, when nothing else was going on, we were pinging and echoing all of our boards. We would send it a code, it would take that code and do some manipulation on it. The hardware would and send it back to us. And if we didn't get the right thing back, we assumed the board had gone bad and we put it out of service. Because hardware parts do go bad and we don't want to put telephone calls through bad boards. We transferred the risk from the hardware to the software. You may also transfer certain risks from software to hardware by having fail safes or by having overrides in the hardware. Whatever. Buying insurance is the classic way of transferring some of the risk to somebody else. That contract I mentioned, that said if you don't have a certain level of reliability, you owe us money back was our customer's way of transferring some of the risk to us of them not being able to collect long distance money back in the day when you collected long distance money. So those are ways of not dealing with the risk or eliminating the risk or at least getting more information about the risk. The problem is you can rarely eliminate all the risks and even if you do, you're still responsible. For example, if Acme, if I'VE transferred a lot of the risk to Acme. It still doesn't mean that if something goes wrong, it's not my product that's failing in the field. Think about Target and the bad reputation they got when all those credit cards numbers got exposed several Christmases ago. Folks, it wasn't their problem. It wasn't their fault. Target. It was a subcontractor that was processing the target credit cards. But it doesn't matter. It was Target's name that was splashed all over the news. Even if you transfer the risk, it is still your responsibility. So then you have do we need to take action before the risk turns into a problem? Folks, that's your containment plans. Containment plans are actions that you're always going to take, no matter what. For example, if you get me practicing before I get up on the five story building, get me practicing on the ground, that's containment action. It's money I'm going to spend if I'm going to go do an audit to get more information about Acme before I select them as a contractor. That's a containment action. Again, anything that you're actually going to do, you're going to spend money time. Now folks, testing is a classic containment action. What's the risk? Shipping poor quality to the field, Shipping a bunch of defects to the field and having problems in the field. How do we contain that? By doing lots of V and V activities. Of course. Another way of containing it is by training our knowledge workers to not make mistakes or as many mistakes. The more knowledge knowledge workers have, the less likely they are to have problems and make mistakes. So do we need action now? If so, we're going to go plan our containment actions. If we don't, or even if we do have containment actions, they may not completely eliminate the risk. Do we also need contingency actions or contingency plans? Contingency plans are plans that are only going to be activated if the risk turns into a problem. A classic example here are disaster recovery plans. You hope to never have to implement your disaster recovery plan. But you got to put it in place, otherwise you're going to have a total disaster. So what you're doing there is minimizing the loss. If you do, if it does turn into a problem with your contingency actions. Of course, many contingency actions have to have associated containment actions. The containment action associated with disaster recovery. One of them is to take nightly backups of your software. Because without the backup, folks, if the hard disk crashes or the building burns down, you're out of luck. You can't recover from that if you don't have a backup, necessarily. And finally there's going to be some level of risk left over. We're always looking at have we managed the risk down to an acceptable level of risk? Folks, you get out of bed in the morning, it's a risk. You drive to work in the morning, it's a risk. Have you reduced it to an acceptable level? Do you wear your seatbelt? Did you bother to check the traffic report to see whether or not there's a pile up on i20? And you can take an alternate route, but whatever's left you're going to just accept. So I've already talked about the two kinds of risks again. Containment actions are obtaining the additional information, avoiding the risk, transferring the risk, deciding on things you're going to do as part of your plan, making the contingency plans even possible, like doing the nightly backups. The contingency actions are only taken if the problem occurs. But you got to have money, time, schedule, budget allocated just in case. Now, I don't have to have the whole cost of the problem because the problem has a probability of not happening, but I want at least the expected value. For example, 10% of 700k is 70k. So my expected value of that risk is 70k. I want that in my buffer. So, because if you have lots and lots of risks and add them all together, some are going to happen, some of them aren't, and hopefully your expected value will turn into a good probability. And you don't want to spend too much, folks, you can do this. I have seen people spend a million dollars to avoid half a million dollar risk. Now if they're very risk adverse people do that. Risk takers, folks, they're people that jump out of perfectly good airplanes. The thrill of taking the risk is part of the reward and opportunity. So this is all a balance. And you're going to have to do some kind of probabilistic analysis and look at your plans, look at your alternatives and decide the best choices. Because as you mitigate the risk, the costs are going of risk exposure is going to go down, but your mitigation costs are going to go up. You add them together to get the total cost of the risk. And don't forget to balance this against the opportunity. You pick the best possibility, but then you've got to make sure that the opportunity is still good. So I'm not going to again spend $75,000 to mitigate a risk where the opportunity is only $50,000 so when we look at the inputs and outputs for risk management planning, we've got that prioritized risk list, we've got our project plans, we've got our risk statements, and what we're going to come up with is containment plans, which are going to feed right into updating our project plans and the contingency plans and updates to the project plans to create the buffers in schedule, in budget, in staffing, to make the contingency plans possible. If you don't have some kind of buffer, and you know what I mean by a buffer, think about the last time you drove to work. Well, let me rephrase that. Let me think about the fastest time you've ever made it from your house to your work. Maybe it's 20 minutes. Did you give yourself 20 minutes to get to work today? Well, maybe you didn't drive to work today because of the virus, but the last time you drove to work, did you give yourself 20 minutes? No. That's the best you've ever done. You're going to add a buffer to that. Maybe it's five minutes, maybe it's 10 minutes. But you know on average that there's going to be some problems. You're not going to make every light just as it turns green. There's going to be some construction, or you're going to hit a school zone, or there's going to be extra traffic, whatever, and you give yourself a buffer. You're going to do the same thing with your projects. You look at what you may have to do in contingency plans and add a buffer to your budgets, your schedules, your staffing to take care of that. And all that's going to end up being part of your new project plans. So we've identified our risks. We got our risk list, we analyzed our risk, and that gave us a prioritized list. Then we plan them and we come up with our risk management plans, which are going to feed right into our project plans. The next step, the fourth step in the risk management process then, is to actually go implement all our containment plans. Now, you're not going to implement them all up front, folks. Part of your plan is when does this need to be implemented? For example, I keep using Acme as an example, but we're not going to. We may do containment plans up front, like an audit. We may do containment plans throughout the process, like ongoing surveillance, but we may not put major plans in place until the last minute, you know, just before system testing or something. We realize there's an issue with. We go Put our final containment plans in place. So we may be implementing these over time. The fact that the test bed is late, we're not going to deal with that during project planning. We're going to wait till maybe the middle of integration testing, see what's happened, and make a decision about whether or not we think it's going to be late, and then go build the simulator if necessary, because we don't want to spend the money if it's not going to turn into a problem. Wait till the last reasonable moment. So we're going to implement our plans. We're going to track all of the results of that. Did it actually decrease the risk to the level that is acceptable or the level that we expected and systematically control those risks as we go? The inputs here are containment plans and our project plans and the outputs are going to be implemented risk action. And what happened as a result of that implemented risk action. This is kind of an easy step, folks. You got the plan, just go do it. So we've got. We've identified, analyzed and planned for our risks and we've implemented the containment plans. And out of that is going to come our status, which is going to feed into tracking our risks. Now with tracking, we have got. What we're basically doing is making sure we've got information about those risks and also information about other parts of our project, what's going on with our project, with our product. And that's going to lead to additional information like I've been talking about. So when we get to integration test, we have new information. Maybe early in the project we thought there was a 30% chance of the test bed being light. But now that we're almost to system testing, we realize we got plenty of time. It's going to be here, maybe we know that it's going to be shipped next week and it will arrive within three days, whatever. So now we can go reanalyze. Maybe it's only a 3% probability instead of a 30% probability. And we can change our plans and decide not to do some of the containment actions. For example, we decide not to rent some equipment. It also so that information feeds into potentially replanning, potentially reanalyzing as we go. We also can close out the risks that have either turned into problems or where we've met the goal and we no longer have problems or the probability it turns into a problem. Of course, the other side of that is as we go through the project and learn more, we're going to identify new risks that are going to feed through the risk management process, basically the tracking step closes the circle and gives us feedback into the other activities of risk management. Two basic tracking mechanism, reviews and metrics. And these fit right in with normal project tracking and control. You may want to put a few extra things in place, but normally it's just normal tracking and controlling of your projects. For example, your project team meetings that happen periodically put reviewing the currently active risks that you're currently mitigating or that relate to the current activities that are going on. Review them in every team status meeting. When you're dealing with senior management, put risk management on the agenda when you're having those senior management reviews. Anything that's high priority, risks that might be disastrous, anything that's interdepartmental or interproject risks. For example, Cindy isn't coming over to our project because the other project is late. Senior management may have to make decisions on how to handle those kinds of risks. Your major gates are great places to say, okay, I finished this phase or I finished this iteration. What risks can I remove and delete? Because they either turned into problems during that phase or iteration or I accomplish my goals. What can I take off the risk list now that I've learned all this new information from implementing that iteration or implementing that phase, what new risks do I have? How has status of the risks changed? Do I need to replan or reanalyze? Entry and exit criteria to individual tasks is another place before I start the task, what are the entry criteria? Are there any risks associated with starting this task before all the entry criteria is met, what are the exit criteria? What are the risks of going ahead and completing the task without meeting all the exit criteria? And of course, metrics. We can look at variances and put in some kind of acceptable level of variance either on a ratio type variance or a delta variance. If the delta gets more than $5,000, we're going to take some kind of action. If it gets more than 50, we're going to take some kind of action. Whatever. We can also have thresholds that we track ourselves to. For example, we plan for that 15% requirements churn. Have we crossed that threshold or are we reaching that threshold too quickly? Even if we haven't crossed yet, if the slope says we're going to cross real soon again, it's looking like there's 100% probability it's turning into a problem. We may go back and reanalyze and replan. And if there's specific thresholds that have been crossed, as I said, for example, you may have More than one threshold. When we were doing inspections of our code, if we had more than X number of defects per line of code, we would reinspect that after it was corrected. If it went into the red zone, we actually threw that code out and started over potentially. Now, folks, metrics, as we talked about last month, should never make the decision for you. Just because it's in the red zone doesn't mean we have to throw it out and start over. But it's an indication there's a risk there. So before you put your contingency plans in place, go analyze why the risk is there, what's going on, what's happening. But the metric gives you information to make an informed decision. So we've got, again, we've done our cycle, we've identified, analyzed, plan, implemented our containment actions, we've been tracking our risks. And that last trigger that we talked about, again, something has happened. The status that we've learned from one of our meetings, the information we gathered from one of our metrics says this risk is turning into a problem or, or has turned into a problem. We go implement our contingency plans, folks. This is another just go do it step. You've got the plans in place, the disaster has happened. Go mitigate the exam disaster. Linda's fallen off the board. Yeah, her harness saved her from going splat, but it swung her into the building and she broke an army. Whatever the contingency plan would be to take her to the hospital, the contingency plan is the insurance company pays for the hospital bill. Whatever the inputs here are your contingency plans and that status of the risk triggers. Whatever triggers you've put in place and out of it, you've got the implemented contingency plans. Again, just because you planned it doesn't mean the plan work. So you've got to track that status back into your tracking and make sure that it feeds back through the input loop. Folks, good risk management is a baseline activity. You should do it at the beginning of the project. In fact, you should be before you even initialize your project. Initiate your project, look at your major risks and decide whether it's even an appropriate project to start. And then as part of your project planning, do good risk management. Feed those plans into your budgets, your schedules, your staffing, etc. But it doesn't stop there. It needs to be a continuous monitoring throughout the entire life cycle. It is a closed feedback loop. Risks planning, risk mitigation is not something you do up front and forget about. Just like good project management, tracking and Control. Good risk management, tracking and control is a significant part of that. So we've got a few minutes left for questions. Kathy didn't interrupt me anymore. If you've got some questions, go ahead and write them in the question box. And as always, a little bit of fireworks. Just to remind you of my hobby. And here's my contact information, which I will leave up during any questions. So Kathy, any questions I have just one. Don asks, do you consider realized risks as issues? If the risk is realized, I assume by that you mean turned into a problem. It is now a problem or an issue and it needs to move from your risk list, which has some probability of happening, but some probability of not happening. It needs to move over to your problem and issue list and be dealt with. Once it's a problem, you got to deal with that problem. One of the ways of dealing with it, however, is to put those contingency plans in place so that if it does turn into a problem, you already have plans to deal with it and you're not scrambling and firefighting. Any other questions? Winfred asks, is this part of PMP training? There is nothing in this that is not useful in your PMP training. The only difference a little bit is language. For example, what I call an opportunity, they call a positive risk. Now, to me, risk has a negative connotation, but they talk about positive and negative risks versus what I call risks and opportunities. So there's a little bit of wording differences, but there's nothing in this risk class that doesn't match up with what the PMP is going to talk about. You're going to be doing the same basic steps. Elaine Ellen says that I believe that this could be used as a 1 hour toward the 35 required hours for PMP certification testing. Yeah, it should be. I teach that course a lot. Yeah, any training that's related to the areas of the body of knowledge can be used for those training hours. Any other questions? No. Thank you all very much. That concludes the webinar.