3.2 Employ the four steps of risk management - Video Tutorials & Practice Problems

<v ->So what are we going to talk about in this lesson?</v> How are we going to make sense of the idea of risk management so we understand effective risk management? Now, I alluded to this point earlier, and I guess it really bears touching on more directly. Risk management can be an opportunity for us to totally lose our minds. And what I mean by that is if we end up factoring in every possible risk to our project, we can spend enormous amounts of time and energy chasing our tails, and if you've ever seen a puppy chase its tail, it's a hilarious thing. And that's really what ultimately happens because it doesn't go anywhere, it just keeps turning in circles, chasing after this strange thing. Chasing our tails with risk management ultimately leads the same thing. We never get forward momentum moving the project along because we're so focused and fixated on risk. So we have to be careful, we can make two mistakes. Number one we can allow the project's risks to overwhelm us where it becomes this sort of monster. And we're imagining all sorts of demons out there. On the other hand, we can make the alternative mistake where we simply damn the torpedoes and full steam ahead, where risks don't matter, where it sounds almost macho and belligerently, economic, if you will, to say risk be damned, we're gonna get this thing through to the finish line. That's a mistake, everybody as powerful as the first one, which is being overwhelmed by them. So how do we make sense of risk management? How do we attend to risks but make sure we're doing it in the best possible way without deliberately ruining the forward momentum of the project? Well, there's four stages of risk management. The first part is risk identification. That is allowing us to make sense of what are the relevant, accent that word, what are the relevant risks out there that we need to attend to? The second point, the second stage in risk management is the idea of the analysis of probability and consequences. It's not enough to identify risks, right? We also have to look at them within the scope or the idea of probability and consequences of those risks we've identified. Third, what are relevant, appropriate risk mitigation strategies? Mitigation essentially means how do we minimize or how do we resolve those risks to our satisfaction or more to the point to the satisfaction of the project? So risk mitigation strategies, we'll talk about some of those. And then control and documentation. So this lesson is going to consist of us now taking, pulling this apart and looking at each one of these components so that we understand each of these four stages better and so that we can start conducting better risk management of our projects. Let's start with the idea of some of these different forms of risk, how do we identify risks? Well, I think a simple way to do this might be to use what I call are risk clusters, risk clusters are asking a question, are there some general generalities or commonalities that certain types of risks have, and so for example, anything related to financial issues, that could be general economics in the broader economy. So for example, in 2009 when we had the banking meltdown and all of a sudden capital got very scarce. Banks were not keen to lend credit to companies and therefore a lot of projects were mothballed because they couldn't get funding for them. So it may be something broad like that. It may be more specific where in our organization now we've taken a hard look at your projects and we've decided we're only going to fund projects that have a return on investment of 20% or higher, and yours is kind of borderline, so we're not clear on that one. It could be all kinds of different financial risks that the project may undertake. And so that's one useful risk cluster to think about. Another definite risk cluster is the idea of the technical risks, so again, depending upon the type of project you're engaging in, what are the technical risks associated with that? How can we make sense of those? Now again, it's common in our minds to think, when I say the word technical, most of us often flash on high tech or electronics and computers and gizmos and gadgets that are flashy and have a lot of these kinds of electronic features to them but that's not correct. Technical risks can occur in any sort of project at any kind of level and in any kind of settings. For example, I may be dealing with technical risks if I'm pouring the concrete on a multi floor parking garage. And once we get to the eighth level of this parking garage, anytime I'm pouring concrete at this level, I'm placing enormous technical burdens, in other words, enormous downward forces on all of the support pillars in that parking garage. So maybe I'm doing something different or I'm putting new, using new loads or I'm doing things in a different way than they've been done before, that's a technical risk. It's not high tech, but it's certainly a technical risk. Some years ago, a overhanging walkway in a very large hotel, I believe it was in Kansas City, collapsed because there were so many people on it watching a dance competition going on down below. And I think it was a Friday night and several people were killed and dozens and dozens were hurt in that catastrophe because that bridge, that suspended walkway let go. Well, that was nothing high tech about that. That was a simple matter of not having the right kinds of fasteners to ensure that those support structures stayed in place. So you see technical just means what are the technical aspects of the project we're dealing with? How are the risks going to manifest themselves? Another famous example or certainly another well known concept here is the legal risks. What legal risks are we undertaking in taking on this project, are they significant? Are there all kinds of external stakeholders that could be affected by this? Is this something we should consider? In this country, It's been incredibly difficult since 1979 and Three Mile Island. It's been incredibly difficult to get licensing and community approval for nuclear power reactor development. So it's only in the last 10 years perhaps that in some states, mostly in the south, that we're seeing the development of nuclear reactors again for energy. And generation because so many people wanted no part of it. So if you were a power company and wanted to spend 1.2 billion or whatever it was gonna cost on a new nuclear reactor, you can understand the legal risks that you were run going to run because of all the different groups that were gonna try and shut you down immediately, were huge. So what are the contractual or legal risks we're entering into? Commercial risks, what if the project that you're developing is for a commercial product and it fails in the marketplace? Have we considered the implications of that? Apple's stock rises and falls very dramatically on the heels of how the public perceives its latest product introductions. So if the Apple iPhone 6 was not considered sufficiently cutting edge or technologically advanced, their stock took a huge hit because the commercial markets felt like sort of a major shrug, eh, it wasn't really all that great was it? Commercial risks ask those questions. What are the risks we're going to engage in once we attempt to introduce this product or this service into the marketplace itself? Risks associated with execution, these are risks that come about from the actual development of the project itself. I alluded before to a construction example. What are the risks that we potentially engender when we engage in this new development? Dubai has spent billions and billions of dollars developing new projects, developing enormous skyscrapers, some of the world's highest, developing huge man-made island complexes, developing an indoor ski park in the middle of the Middle East, developing a Tiger Woods branded golf course. The economy went bad in Dubai some years ago and many of these projects were scrapped in the middle of the process. For example, trying to build a golf course in the middle of what is essentially an arid desert is certainly an exercise in optimism, if nothing else. The execution risks associated with doing these is something that has to be considered as part of this process. The what are some other common types? So those are some general risk clusters, but they're by no means the only ones we have to think about because in a sense they're legitimate, they're also very broad. So what are some other ones that you and I have to think about maybe on a more routine basis, absenteeism. Supposing you're working in an organization where you have some notorious problems with absenteeism or you have a all star programmer or an all star test developer or whatever that basically you can't do anything about. And if he feels like taking the day off, he takes the day off and so we just have to work around his schedule. Strange it may be, we really need him and so we can't afford to get rid of him, but at the same time, we have to acknowledge the fact that this may be the case. An abrupt resignation. Suppose somebody just got a better offer from another company and decided to leave us. That's in legitimate risk as well, staff being pulled away. Our project originally was staffed for eight people to help out to make this all work. Other projects got brought on board and now all of a sudden, instead of those eight people, I had 'em down to four. How am I going to resolve having to get this project done with half of the resources I originally started out with? Time overruns. How are we gonna deal with overruns in terms of time? How about the skills are unavailable, I need a c++ programmer, we don't have one. Where are we going to find one in short order? What if we never even thought of that Initially, we just assumed that when it came time for the programming to be done, we would have a resource here who could get that done? Low and behold, we discover that person's no longer here, hasn't worked here in six months, now what? What about training? Suppose that we brought people on to speed here only to discover that our training for them had been ineffective. And so we they, we sit them down and give them an assignment and we assumed it would be done in 20 hours, 40 hours later, they're still puttering around with it because they just weren't trained effectively to get the work done. What if the specifications were incomplete? We thought we had clear understanding of what the project was supposed to do. And then as we started looking through all the sheets of specifications, we discover some of the critical information is not available here. Change orders. Change orders are one of those features that drives project managers and their teams absolutely crazy. Change orders are when the project customer or top management or some other person says, I know we said we wanted to do it this way, but now we need it done this way. So I need some change to take place here. Sometimes change orders are good, for example, if you're a builder and you build residential real estate and you contract with somebody to build them a $300,000 house and they walk in and they say, I don't like the door there, I want it moved over there, or I want bookcases there, or I think the staircase doesn't make sense the way you've set it up, what's the residential person gonna do? He's not going to argue with you, he's gonna say, I can do it any way you want me to do it, of course, every time I change your request, every time I implement these new changes, it's gonna cost money. So the money is always changing because of change orders. Those are the kinds of things to think about as part of these different risks. So how do we do this, how do we, how do we identify some of these different risks? Well, I said early on that we have to be careful. We don't want to listen to the worst angels of our nature who are putting fear into our hearts about all the possible things that could go wrong. So any one person by him or herself trying to anticipate all these risks runs a great risk if you'll pardon the pun number one, because I don't see them all, I have finite information, I simply can't recognize him. If I'm a technical person, I may not understand the commercial risks associated with this project. It's not something I concern myself with. On the other hand, if I'm a managerial kind of person, I deal with a management, I deal with a stakeholder management, I may not be qualified to handle the technical risk or even recognize what are some significant technical risks for the work you're trying to do. So you see any one of us is limited by the amount of information they can possibly recognize and pass on that are legitimate risks. So the first challenge is how do I identify real risks to this project? One way we do this is get the team together. Don't try and do it by yourself. Bring the team together in a brainstorming meeting and let's work off each other, let's put everything on the table. Let's try and understand what are some of the things that you may have thought of that never even occurred to me? Have somebody record this. So get somebody on at a blackboard or a chalkboard and have them writing this stuff down so that we've got all this information up there. And at this point in time with a brainstorming meeting, don't be too evaluative, don't start saying things like, Oh, that's a stupid one, forget that, or nah, that's not likely to happen. We're not at that point yet folks, all we are doing now is identifying relevant risks. The only bit of advice I would give you is set your parameters, say we're interested in relevant risks, meaning risks that have a legitimate potential to occur so that we in a brainstorming session can at least eliminate a few of the hit-by-the-bus risks, but beyond that, dis sky's the limit. Try in a brainstorming session to engage and involve everybody in your project, especially people from different backgrounds. If you've got marketing people in the room and you've got software people in the room and you've got engineers and you've got production people in the room, you've got a good cross section of folks who can help you identify the relevant risks, things that they think about that nobody else thinks about and you probably never even considered. So brainstorming meetings is a huge way to get those ideas out on the table. Second, never neglect expert opinion. If you are running a project, it never hurts to ask some of the senior folks in your department or in your organization who maybe haven't run exactly the same project you have or something, not exactly similar to it, but close. They've had some experiences. So if you're trying to introduce version 7.0 of your flagship software that your company depends on, why not go back and see if the project manager for version 5.0 or 6.0 is still around or is someone you can talk to and get some information on? Try and find out from those people what they know, what they can tell you because they are experts, because they bring something to this that you probably never even considered before. Past history. We can also look at projects from the point of view of where do the risk fall out based on past history. In some organizations it's required. Now notice what I just said, it's required that project managers prior to full sign off, basically the top management will not allow you to get started. Sign off will not occur until you can bring them a report on past historical examples that were similar to the project you're working on. So they expect you to go and dig this up. They expect you to find the history to be familiar with the history so that you're in a position now where you can be guided by and influenced by the history of these past projects and the risks they undertook. Multiple assessments are very similar to the idea of brainstorming meetings in the sense that their team base. So what I'm gonna do here is I'm going to put together a team or maybe multiple teams out of members of my project, so subdivide them, put them into teams and give them specific assignments. Maybe say to the software folks, if that's the kind of project I'm working on, identify the relevant software risks based on your experience, based on what you guys can come up with. Give it set for your production people. Give them a set of manufacturing or operations or supply chain risks. What have you run into before or what are potential problems here, so the idea is get multiple people working on it, get them working in teams where they can kind of conjoinly come up with this information. Very similar to the brainstorming idea, it's simply breaking it down one level below. And that's the idea. What do we do with this information? Well, we said the first thing we have to do is we have to identify the risks, that was phase one. Step two now is assessing those risks. So we've got all our lists of risk. We've got everything from run out of coffee Monday morning when everybody really needs it to the really significant ones at the that really loom that are really significant. All those risks are good, but it's just a list, right? All it is a bunch of things that we've come up with and we look at them and maybe we scratch our head and we say, Okay, but there's 43 things here. How can we possibly attend all 43? The short answer to that question is you can't nor should you be expected to, because it's not relevant, it's not useful to look at 43 things and somehow think you can concoct 43 strategies and that each one of them is equally viable. So one way we can develop an assessment is by developing a matrix along the lines of what you see on the screen right now. And this matrix is taking the original definition of risk. Remember, project risk is likelihood, probability, times consequences. And so for simplicity's sake here, what we're gonna do is divide it up into high and low. Now you can decide how you want to assess high versus low. You can decide what those language, what those terms actually mean, for me, it's not that relevant or it's not critically important to know that. What's really more important is recognizing that I'm forcing myself to develop a classification scheme here. I'm forcing myself to say low means low. So how are you and me, how are we as a team going to define what low is? Let's do that. High means high again, how are we gonna define that? Let's make sure that we're all on the same page. And then once we've done it, we're gonna take all those different risks that we've come up with all those list of 43 and we're gonna start classifying them onto this matrix. And you can look at that and you can see very clearly that the ones that we really have to attend to, the ones that immediately should grab our attention are down there in the bottom right quadrant of my matrix. The ones there that have both a high likelihood of happening, but also have very high negative consequences. So they're likely to happen, and if and when they do, they're gonna be serious, they're gonna, there's gonna be serious problems here when and if this happens, so down in that bright red quadrant on my matrix, you can see these are the significant issues. Now the good news is that out of those 43 risks that we came up with, we may not have all that many that actually genuinely honestly fit down in that category. And we ask ourselves a question as part of this when we're trying to set these risks within this framework, when we're trying to assess them and categorize them, Let's be honest and let's work on this jointly so that when Joe says, Oh, that's a serious one, that's a high, high. Then three other people may say, Well, no, it really isn't. I mean, that's the likelihood is high, but the consequences are not really that significant. So in other words, let's be collective here and let's come up with this assessment and identify where those risks fall out. And you can see then back to my original point, the serious ones, the ones that we absolutely must attend to immediately are in that bottom right quadrant. The next batch are the ones that are kind of long that diagonal, so in other words, they may have a low likelihood the probability is low, but the consequences are pretty severe. Or the probability is quite high, it's gonna happen, but the consequences may not be all that serious. Those two boxes, those two quadrants are really for the second level. So that's sort of secondary concerns. If our immediate concerns are in the bottom right, then if we have time left over, if you will, if we have the opportunity, if we have means, we're gonna then address those next two quadrants because those are things that we should consider. They have some impact potentially, but lastly, don't forget that final quadrant up there where not only is the probability low, but the consequences are low. These are things that we probably don't need to waste a whole lot of our time with, and so again, honest assessment, honest classification of all these different risk factors into these different quadrants will go a long way toward number one, allowing us to get a better sense of these different factors. Number two it lets us sleep better at night because we're not laying awake, they're constantly running through our minds, all 43 of those different risks because all 43 of those different risks were not created equally and don't have to be considered equally, so risk assessment is doing that. It's saying let's classify the risks for how we should best attend to them. Now, once we've done that, once we have our list, if you will, once we've broken it down and we've identified those activities, those risk factors that are most critical, the ones we really have to pay attention to, we are next left with the question, what do we do about them? So think about it this way. So far we've come up with some identification strategies. What could potentially happen? What are some things out there that could affect our project? We've started classifying them, which are the ones we really have to pay attention to? Which are the ones that we can get to after we've dealt with these, and which are the ones that just really don't bear worry? Well now the third step in this process is what are some of the things we can actually do about them? Because some of you are wondering, all right, what are some of the tools that I have in my toolbox that will now allow me to address these risks in the best possible way, as efficiently as possible, but also in as time intensive a period as possible? So let's look at those. What are some risk mitigation strategies? The first and simplest one, of course is accept it. Let's go back to our original quadrant, if you remember there, that when we have a project risk that we can categorize as both low and low, it's low probability and low consequence. The simplest dealing with it is just to accept it. It's probably not all that relevant, so let's not worry about it, likewise, some of those risks and those other categories, for example, losing my chief programmer to being hit by a bus, well, the probability is low, but the consequences is severe. But again I'm probably just going to accept the fact that my chief programmer can look both ways before he crosses the street. So some risks don't really bear me spending a lot of time attempting to mitigate them. They're just not that relevant in the greater scheme of things. So a very perfectly appropriate strategy is to accept the risk. The point to remember is that when you choose to accept a risk, make sure that you've documented this, that you have an idea. These are the risks that we've identified and these, this is why we're going to accept this percentage of them, and here's our justification. Don't just use accept as a strategy to just say, well, let's not worry about it. Accepting a risk means taking a hard look at it and coming to a logical reason why we're willing to accept that risk and make sure in your own mind you're clear on what that logical reason is. Another method that we can use for risk mitigation is minimizing the risk. Can we find ways to minimize that risk as much as possible? So for example, I may minimize the risk by looking at alternative ways that I can deal with this with other people. For example, suppose I'm a car company and we're interested in coming out with a brand new auto design. We haven't had a lot of success with a particular small block aluminum for cylinder engine. Ours just doesn't seem to generate enough horsepower. So what I might do as the car company is contract with another car company that is particularly noted for their small block aluminum for cylinder engines to use those in my car. What I'm doing there is that I'm trying to minimize the risk by finding alternative ways to get this accomplished. So minimizing a risk there means that we're going to do what we can to minimize the process or the concerns that we have for that risk. Facetiously, you could even argue that minimizing a risk might consist of something like giving better training to our personnel. We don't do a very good job with some sort of activity in the project where we're gonna minimize that risk of time overruns by sending everyone away for additional training, so they're gonna become better at their job and thereby minimize the risk. Another perfectly acceptable type of risk mitigation strategies is to share the risk, I might share a risk, Think about Airbus, this is a very large example, but it's still illustrates point quite well. Airbus is a consortium of many European organizations. The cost of entry, the barriers to entry into the commercial airline industry was absolutely massive. And so Boeing initially was the leader because they had been around for a long time, they had the deepest pockets and they had all the technology, they had all of the skill sets, they had the learning curve, all of this working to their advantage. And so when the European Union, and particularly the Airbus Consortium was first formed, they realized that no one organization in Europe and indeed no one country could subsidize their aviation industry to the same degree. And so they decided to jointly share out this risk by bringing in German companies and French companies and Spanish companies and British companies and Dutch companies and all these other, Italian companies, all these different groups from the different parts of the European Union to share out that risk, that way, no one person is on the hook for too much. Ask yourself a question with your particular projects that you're working on right now, are there ways that I can find to share some of these risks? So for example, if I have serious financial risks associated with this project, can I find other projects and other parts of the organization that we can leverage some of the knowledge we're gaining in this project with what they're doing over there and thereby get them to share some of the development risks with us because they can see how it can work to their advantage as well? That's just one example. But I've seen companies do precisely that where a project coming out of one part of their organization can actually benefit other parts. And so they find a way to share that risk among these different groups. Sometimes and in some circumstances, we may have the luxury of being able to transfer the risk entirely, so for example, if I have the ability to push off a risk onto another stakeholder, I may take advantage of that. There's an old joke, some of you have probably heard, and it goes like this, where does a 600 pound gorilla sit? And the answer is anywhere it wants to. In a corporate setting, many companies deliberately become the 600 pound gorilla. So they may contract with external companies, suppliers, and they're very careful to only contract with small companies. So for example, I'm a massive conglomerate, multi-billion dollar a year, and yet some of my suppliers are relatively small, 10 $20 million revenue companies on a yearly basis. Why do I do that? Well, one reason I do that is because I know that my contract with them is hugely important to them, and therefore, any risks that I have internally, I can try and dump on some of these other people as well. So can I find ways to simply transfer risk to my partners in the project? Sometimes that possibility does exist. You have to ask yourself the question, is that a likely scenario with your different projects? Another mitigation strategy we see oftentimes in building is contingency reserves. We had a brand new business building constructed for us about 10 years ago. We had $30 million to spend on this business building. The final design very carefully was costed out at 27 million. Now, you may be thinking, Well, where did the other 3 million go? You had a $30 million contract, but ultimately you contracted it for 27. So where's the distinction? Because in construction, it's very common to always retain 10% of the total cost in a contingency reserve. You never know what's gonna happen. You don't know till you actually start developing the building, you have a good sense of cost, you don't have a complete sense of cost. And so in construction, it's very common to sit 10% into an escrow account and just keep it there just in case. And so contingency reserves are an alternative way to make sure that when push comes to shove, that we've covered all of the possible risks and done a good job with risk mitigation throughout these steps. Finally, just as a quick recap, we talked about how do we identify relevant risks. What do we make do with them? How do we assess or categorize or classify them? What are some steps we can take to mitigate those risks? The final step in this process is developing a control and documentation system so that we have some means by which we can verify and determine what happened, and indeed, if you look, you see that the control and documentation gives future managers an opportunity to classify and codify risks, responses, and outcomes. Now, here's a point about this. Remember initially I said, what are some means by which we can identify the relevant risks for our project? And I said, expert opinion and past history. Were two examples of those kinds of means to identify risks. This is what I'm talking about. If we as a company are interested in corporate learning, so the organization as a whole is learning and moving forward, one way that I can promote organizational learning is making sure that when my project is done, when my risk assessments are done, that we spend the time documenting what happened, what were the impact of when that happened? How did we deal with it, how successful was our solution? Was it a good solution or that didn't work so we had to try this one, that didn't work either, ultimately, we had to try this thing. So by the way, folks, for those of you running projects in the future, don't do this or this, you have to immediately go to this step in order to fix that problem because these other two won't work and they'll just waste your time. Well, what a marvelous bit of advice that is. And think for your situation. Imagine if you had an opportunity to read up on these particular bits of advice, how that would help you with your project. So you don't have to constantly relearn the lessons of the past, you don't have to constantly be reinventing wheels. You have this information in play because as part of your risk management, you also required documentation. You made sure that this was gonna happen. And at the same time, what were the action plans? I say here, don't keep discovering risk management. And what I mean by that is don't treat risk management folks as a constantly new thing. Once you get comfortable with it, once it becomes part of your or project processes so that we just naturally do it without thinking about it, you're gonna discover that it's, you're not reinventing wheels, you're not rediscovering risk management every time you run a project that in fact you've done a good job of it every step of the way. And so it just becomes part of the normal flow of what you're doing with a project. So if you do this, you're putting yourself in position to proceed successfully. Change management reports. This is the kinds of things we're talking about. What happened? Who was responsible for it, or who did it happen to or who was most affected by it or who dealt with it successfully? When did it happen in the project? At what point in the development of the project? So that if we have to make changes, what happened? Who did it happen to, you get the idea, when did it occur? So what should we be looking for? Why did it happen? Change manage report systems have to ask these fundamental questions, not simply for your own sake. Please understand me. This purpose here is not just so you can dot all your eyes and cross your Ts. It may be necessary from a contractual point of view when you're dealing with an external customer, you have to document this because they're gonna wanna see this in all of the information when you pass along the project. But more importantly, this is gonna help your own organization. As you guys are moving forward in new projects, you're gonna have this as a background and as a backstop for you to make sure you're getting everything done and you're getting it done in a way that future, I don't wanna say future generations of project managers, but certainly the next people in line are going to have a leg up because of the work you did. Risk management is still part of the early stages of the project. So if we think about our life cycle, we're still really at the early part of setting the stage for success. And for some of you may be thinking, well, when are we going to really start getting into the actual development of the project? Well, that's coming. But if we don't do these first steps correctly, if we don't spend time getting all of our dominoes lined up, we're gonna find that they're gonna start falling. And when they start falling, it's gonna be real problem. So what we want to be thinking here is develop our scope, develop the risk management, and then we're gonna be putting ourselves into position to start building the project plan. And that's what we're gonna be seeing in the next lesson. Thank you.