Episode 148.2: Risk Management - Critical Success Factor for your Project - Part 2
Part 2. This episode of The PM Podcast is a 4-part webinar presented by Andreas Heilwagen on the topic of Risk Management. He stipulates that it is a critical success factor for your project success. We look at a definition of Risk Management, present the value that it offers to your projects, go through the processes offered by The PMBOK Guide, take a look at the free risk management templates offered by Andreas and the look into the success factors that will make your internal risk management approach a winning activity.
Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.
Andreas Heilwagen: Okay, “Templates,” “Definition.” Everybody needs the same language and of course, we need some “Tools.” And I will show you some simple, excellent tools which help you to do risk management.
Cornelius Fichtner: Now, that we’ve seen these eight or nine items here, let’s just make it absolutely clear to the viewers here; until now, we haven’t really done any risk management per se. We haven’t actively done anything. We really just sat down and we thought about all of these. What are our strategies? What are our templates? What is our communications plan? What are the success criteria and thresholds that we have? That’s all that we’ve defined. We have done nothing but planning. We have just written these stuffs down.
Andreas Heilwagen: It’s just the answer to the question how do we want to do it and the results of these aspects of the so called risk management plan.
Cornelius Fichtner: Exactly. And now, once we know all of these, now we can get into the other processes of risk management and that one begins with Risk Identification. This is where we go in and we sit down and we do some brainstorming. And we think: “Okay, what risks do we have?” right?
Andreas Heilwagen: Exactly. This process is done really often in contrast with the plan risk management process we discussed before. Meetup process is only done once.
And here, we want to identify risks as early as possible so before you start a project, you already have to ask your project sponsor what risks you might see and you have to do a lot of talking to people and to go find out what their opinion is and you can come up with your first list of risks. And of course, you have to identify risks anytime.
I think it is a good practice and I do it all the time if I have ever a project team meeting, after the official, again I ask all the participants what new risks do you see: Has risk change or is anything else coming up? Do we have opportunities which we should use? And if you make it a habit to ask this question every time, it’s a good starting point for risk management.
Cornelius Fichtner: Okay. Once we have them identified, there are two processes that everybody always messes up and doesn’t really know which one is which, I’m one of these people, is the Qualitative Risk Analysis and the Quantitative Risk Analysis. Let’s look at the Qualitative Risk Analysis first, what’s happening here?
Andreas Heilwagen: Yeah! You don’t mess them up if you remember what quality. With quality, it’s always hope that it is so you don’t confuse it afterwards.
Cornelius Fichtner: Right.
Andreas Heilwagen: So the main aspect of the qualitative analysis is impact. So how do I measure the impact and its financial impact. Robert Compton Jr. from IBM came up with a formula in 1970 and he said: “Multiply the financial impact and the probability that the risk occurs and you have your priority.”
It’s perfect. It has ever been used since. Of course, if you have a company or an organization which needs another metric instead of a financial impact, change it but you always need to come up with a formula which is valid for all risks in your organization.
Cornelius Fichtner: Yeah, an impact and probability is usually the one that is most often used.
Andreas Heilwagen: Right.
Cornelius Fichtner: Right.
Andreas Heilwagen: That’s what we need. What people usually forget, you need the risk owner because the project manager is not a technical guy.
For example, I did a lot of software development but today, I don’t dare to be a risk owner because there are the software developers which know exactly about their risks and I choose risk owner from the team who is accountable for the rest. Of course, you cannot ask everybody. A risk owner needs a lot of experience and some risks will go to the project sponsor. We have to find the right person who likes managing the risks, a really personal task because if you fail and you have a risk which occurs, you have a great problem.
Cornelius Fichtner: You also have the risk action owner here.
Andreas Heilwagen: Yeah, I was very curious when I found that term in the new practice there, not because you usually only get the risk owner. The risk action owner is responsible for implementing risk response in time. So it’s kind of response owner and the risk owner is the guy who is really accountable for the overall risk.
If you have a risk owner for every little risks, that’s not good. So you should choose which risks you have owner and an action owner, and that also implies that you should drop very simple risks and focus on the big risks.
Cornelius Fichtner: You said, the easiest way to remember the qualitative risk analysis is to ask yourself how bad is it? So what’s the simple question you ask yourself to remember what the quantitative risk analysis does?
Andreas Heilwagen: Quantity is a question of how much. I always think of mathematics and formulas and sets what it is about.
In qualitative risk analysis, the process we discussed before, you look at one risk at a time. In quantitative, the second process, risk analysis, you look at all risks at the same time and that’s very complex. And why do you do it? You want to find out what is the probability of achieving the project goals when you look at all the risks at the same time because risks are not nice and they do not occur one after another. You always have a situation that many risks can occur at the same time. They interact and they are dependent on each other; and you have to find out what the root causes are and there are mathematical approaches like the Monte Carlo Analysis which allows you to do that.
Of course, that’s a very big gun so you just don’t do it for small projects and it’s another of the success factors of risk management. You have to scale it for your project. So this process is the first one which you drop if your project is smaller.
So what other questions does this process answer? It asks the question: Does the reserve needs a risk tolerance? So each organization has its own risk tolerance and you need to provide enough reserves to manage the risks that people feel safe enough. It’s a simple way to describe it.
Another thing which is important is to find out which parts of the projects make the biggest problems. Maybe you want to approach them in another way. Maybe you want to change the scope. If you know it in advance where all the problems come from and all the risks come from, they’d help to verify that your approach is the right one.
And of course you want to know which are the biggest risks. So it’s a very complex process and it’s not for people which do small projects and which do not have the right software and models at hand.
Cornelius Fichtner: Okay. So the first four processes we looked at so far, the first one was plan risk management that we just planned, right? Then we identified the risks and then we went through the qualitative risks and then we went through the qualitative risk analysis and the quantitative risk analysis. That means now we know what are our risks. What’s next?
Above are the first few pages of the transcript. The complete transcript is available to Premium subscribers only. Please subscribe to our Premium Podcast to receive a PDF transcript.
Think you for this deep presentation.
I just wanted to mention that the responses for oppurtunities are missing in the 'Responses' section. You mentionned : voidance, transfer, mitigation and acceptance but not Exploit, Share and Enhance.