3.1 Understand the critical nature of project risk management - Video Tutorials & Practice Problems

<v ->Following World War II,</v> there was a rush to exploit a brand new technology., the jet engine. The German Luftwaffe had developed the Messerschmitt 262 during the war and had a jet engine fighter that was highly effective, very fast, and incredibly dangerous. And the allies, particularly the US and the British needed to harness that jet engine. And they recognized that the next source of commercial use for it would be the commercial aviation field. So simultaneously, at the close World War II, two companies one in the us, Boeing, and one in Great Britain de Havilland, were simultaneously trying to develop the first commercial jet aircraft for their airline industries and De Havilland won they won the race, they came out first with their jet, it was called the Comet. The Comet was at the time considered absolute state of the art. It was powered by two jet engines. It had about 50 people, 55 people that it could carry in a very nice compartment inside. It had these wonderful square windows looking out because it was felt that gave it more of a panoramic view from the outside and to be able to see out as well. In many ways, it was an absolute state-of-the-art piece of equipment. And the British Overseas Air Corporation BOAC immediately adopted the Comet for their long haul flights. In 1952 the first problem started occurring with The Comet. There were a couple unexplained crashes and nobody quite understood what was happening. The assumption was it had to have been pilot error. Some more time goes by, in 1953, a Comet takes off from Rome's airport for the next leg on its flight. It gets up to about 10,000 feet above sea level and suddenly disappears off the radar screen. Air sea search, rescue vessels found debris floating. And then Mediterranean turns out it was The Comet that had in some ways crashed. Nobody knew understood why. So initially The Comet was taken out of service. It was tested extensively, nothing was found and so it was put back into use. Less than two months after The Comet was returned to use another flight again over the Mediterranean, disappeared off the radar screen killing everybody on board. It was at this point that De Havilland pulled the Comet and conducted significant, really significant testing and they discovered a whole litany of problems from metal fatigue to problems with the way the wings were had set up with the engines embedded in them. But these were relatively minor compared to the one significant problem, which was they discovered that rapid pressurization and depressurization of the cockpit, which you had to do with jets was causing spider web cracks to start appearing in the corners of those square windows. And that once, and that had happened enough times they were experiencing catastrophic blowouts, depressurization the cabin and ultimately the plane crashing. They only discovered that after the fact. They only discovered that after well over a hundred people were killed on The Comet. The Comet was, at the time considered a technological marvel that beat Boeing to the industry. So it was the first one out there that had all the modern conveniences that did everything a project should have done and was considered initially a marvelous success for the De Havilland corporation. Ultimately, as we know, once it had been in use for not even that long, it ended up causing horrendous fatalities. The Comet story is just one example of projects that have been initiated, that have been undertaken successfully, it appeared up until the point where some catastrophic failure occurred. Now, please understand not every project risk not every project failure occurs at the back end after the project is already out in use, and then suddenly everything falls apart. Many times in the midst of development, a project may run into significant problems problems that were unanticipated problems that derail the project, problems that cost the company millions of dollars. What we're gonna talk about in this lesson is the idea of project risk management, of what we need to do and what we need to be thinking of. Indeed, the mindset that we need to have when we're thinking about how do I manage my project. I need to manage it in terms not simply of the possibilities that this creative idea promises, but also the concomitant risks that we can engender in trying to make this project work. So how do we do this? What are the things that we're gonna be talking about in this lesson? Well, first of all, we have to understand what we mean. Risk management. Risk management in projects is, we call it the art and science which is an interesting term, isn't it? It suggests that we can only do so much with the science, with the deductive, with the logical. We also have to factor in the intuitive, the creative, the thinking outside of the boundaries. The art and science of identifying, analyzing, and responding to various risk factors throughout the life of the project and in the best interests of its objectives. So the risk that happen at the beginning, the risks that may occur at the end, the risks in the middle. These are all components of project risk that we have to constantly be paying attention to as the project moves forward. What do we mean by risk? Let's, maybe we should think about that first of all. What does risk actually imply in a project? Well simply put you can see project risk is any possible event that can negatively affect the viability of that project. So that's a pretty wide, broad category if we think about it. Any possible event that can negatively affect the viability of a project opens up an enormous can of worms, doesn't it? I mean, if I start getting a little bit creative about the possible events, I can go crazy. And you're right, you could go crazy. So what we're gonna try and do is put this in a little bit of a perspective and understand sort of what do we mean by relevant risk and relevant assessment versus allowing our fears to get ahold of us and essentially imagining all possible problems that occur. But project risks are those events those things that could happen that could derail the project. How does this work? Why do we care about risk? What ultimately does risk mean? There's kind of, take a look at this figure and you can see there's some elements here that are important for us to understand as part of this idea of risk. First of all, our old friend the project life cycle has come back. Now we have the conceptual, the I've changed it slightly to development as opposed to planning. It's okay, it's still the three stage idea. And you'll notice that this process as it moves in time, we start with the initial conceptual phase. We'll notice that because we're just starting out, we're into conceptual phase, the actual amount at stake the amount of money we have spent our investment here is relatively low. So we've done our business case perhaps or we've started trying to investigate the idea of the possibility of the project, but no more than that. Consequently, there's not a lot of money on the table at this point in time. On the other hand, you can see that this is when opportunities and risks are pretty much at their highest, because it's during this early phase that the sky's the limit. So yes, the opportunities are there, but so are the risks because we just don't know enough. We're still trying to understand the ramifications of this project idea we have. And so our best guesses are just that, they're best guesses. Now, during the development stage, during that second phase of the project, also known as planning, remember from our project life cycle the expenditures are starting to ramp up, aren't they? We're now starting to invest more time. We're putting together the plans and the schedules. We've conducted that scope development that we talked about in lesson two that was so important for the project success. So there was a lot that's starting to take place at least initially. So money is being spent. At the same time, we still have a lot of risks and opportunities that are taking place because we haven't actually done the hard work of the project. So many things we don't really know until we get into them. All we know is what could be, not exactly what is. And it's during the execution phase that things start happening. The things come together, don't they? Because now the money is being spent. Now resources have been acquired they're being deployed to work on the project. So we have a lot of things going on. So the good news is, on one hand because we're starting to develop the project some of those initial risks, the worry that we had are starting to tail off, right? We have resolved some of our technical problems. We have made sense out of some of our ambiguities. So those things are starting to tail off to a degree while the expenditures are starting to climb. And you'll see there that it's during the implementation and finally the termination phases, that the this is where the highest risk impact to the project can occur because the money has been committed now, because we are financially on the hook obligated for the project. And at the same time, although we're starting to resolve some of these uncertainties, some of these project risks, we haven't by any means resolved all of them. The Comet example that I started this lesson with was an example of a project risk that was only discovered after the fact, after de Havilland thought they had completed a successful project, and in fact discovered belatedly and tragically that they hadn't. And yet, for many projects, it's really during the project development itself that we start focusing on and discovering a lot of unanticipated risks or problems that start to emerge. And so it's during that period of time that the greatest risk impact is hitting us, because we are both spending a lot of money and we're just slowly starting to resolve a lot of those different risk issues. This is where the problems can potentially occur. So what do we do about this? What is the process that we can start putting in place to understand risk management, that we can start recognizing what's involved in risk and we gonna start attending to it in a rational manner? Well, the process of risk management covers several features First of all, we're asking the question what's likely to happen? What are some of the things that have a likelihood of occurring? What can be done about them? So we wanna know, A, what's likely to take place? B, what's likely to be done about it? Third, what are some of the warning signs? What are some of the giveaways that some of those concerns we had when we said what's likely to happen is actually taking place? Do we have any warnings in place that's allowing us to resolve that? What are the likely outcomes so that if this process this risk that we're looking at, if this continues what is it likely to do? Is it a significant risk? Is it a relatively insignificant risk? Is it not something we care about? For example, in a software project losing my chief coder, my principal coder early in the process is a significant risk and it's something that can have a huge impact on the viability of the project. On the other hand losing my chief coder to another company down at the end of the process when we've essentially finished all the coding, we finished all the testing and we're just in the documentation phase while that same risk is occurring, you can see that the outcome now is much less to my organization than if it had happened earlier. So outcomes can vary depending upon where in the project this is actually taking place. A project risk, what I want you to think about when we talk about project risks they can really be defined in terms of a simple formula but it's a very powerful one. The formula works like this. A risk is the probability of event. The probability of an event occurring times its consequence. Now, notice a couple things here. Number one, it's a multiplicative function. What that means is the probability times the consequence is a significant thing to think about. Not probability plus consequence. In other words, if I have something with a very low probability of occurring, my chief programmer getting hit by a bus while walking across the street in Seattle is relatively low probability. The consequence, of course would be catastrophic. But I can look at that in light of the idea that says is that truly a significant project risk because the probability so low even though the consequences are high? On the other hand, probabilities that are both high and consequences that are significant are true project risks probability and effect jointly makes for the project risk.