PMI PMP Project Management Professional – Introducing Project Risk Management

1. Section Overview: Project Risk Management

Welcome back. In this section we’ll talk about project Risk Management. Project. Risk management is chapter eleven in the Pmbok guide. We’re going to discuss just the big picture, the big concepts of risk management. What is a risk, how does it affect your project, how do we manage manage those risks? So all that type of business we’ll talk about here at the beginning of this section. Then we’re going to drill down a little bit deeper and talk about creating a risk management plan. The risk management plan will direct us and how we do the other risk management activities. So we’ll be looking at examining stakeholder tolerances and what is a stakeholder tolerance or a stakeholder threshold for risk?

Some risk management policies that you have to consider as you do your planning and management of risk. Then we’ll get into risk identification and ongoing activity that we do throughout the project. With risk identification it helps us to capture the risk events and then that allows us to go in and do qualitative and then quantitative risk analysis. So we’ll look at both of those qualitative versus quantitative and how do I keep those straight in my mind? So we’ll talk about qualitative and quantitative.

Then we’ll do an analysis of our risk and that helps us to find a contingency reserve. We’ll also examine a really important topic for your exam risk responses. So planning risk responses. And I have an assignment with you to really reinforce these different risk responses because you want to be able to recognize these responses and to know which response is most appropriate. So planning risk responses, we’ll talk about justifying risk reduction, about spending money to reduce probability and impact and then we’ll talk about monitoring risk. A lot of information really the important stuff here. But I have confidence you can do this. So let’s hop in and knock this out. Now in this section on project risk management.

2. Key Concepts for Project Risk Management

Risk is not always a bad thing. Risk is an uncertain event that could have a positive or a negative effect on your project. So risk in and of itself is just the uncertainty. It’s often the effect that we think of as being bad or negative in project projects. We have two big categories of risk. We have business risk and we have pure risk. Pure risk is the danger, the loss of life or limb. Business risk is the investment that you could lose or the potential to earn a return on that investment. A pure risk has no positive opportunity. A pure risk is always negative because someone could get injured or hurt or loss of life or limb. That is pure risk. Business risk is where most of us think of when it comes to risk. Think about your investments in the stock market or your savings or a new business that you start up. A pure risk. You think about the dangerous work in construction or health care or manufacturing or other disciplines where an individual could get hurt in your project.

That is a pure risk. When we think about planning for risk management, as we are going to do in just a moment to create the risk management plan, there are some terms that we need to know as we go into planning. First off is the risk appetite. It’s how hungry is an organization or a group of stakeholders for risk. So you think about they see an opportunity, so we want to really seize that opportunity. Don’t think of risk as negative. It’s the opportunity here they have a risk appetite, so they want to take on risk. Risk tolerance is what’s that unease, what’s their level of tolerance for the amount of risk in the project? The risk threshold describes at what point would I cross the significance of a risk? And now I’m uncomfortable with that. So what’s my risk threshold that once I get beyond this point, now I’m uncomfortable? Risk threshold could also mean that a risk event is known and at some point we’re going to cross the threshold and that risk event is going to happen.

So a threshold is also like you’re crossing the threshold of a doorway. So if the conditions continue to go, we’re going to hit this risk threshold threshold and now the event is likely to happen. Stakeholder tolerance for risk means how willing will a stakeholder be to accept risk or to allow risk or they want to avoid risk? So the stakeholder tolerance really describes their appetite, the generic term of risk tolerance and the risk threshold. Sometimes, probably not for your exam, but sometimes you’ll see this idea of the utility function which describes the tolerance and the amount of risk that an organization will take on and how they will allow risk or promote risk, positive risk in the organization. The other thing that we need to know is the relationship between the project priority and the cost of risk elimination. And so you have these two S curves here, an inverted S.

That’s the dashed line and the solid line that’s going up. So on the solid line that’s going up means the higher the project priority, inverse to the dash line coming down, the higher the project priority. The more an organization is willing to spend on risk management, the more they’ll spend to eliminate risk. So a very high profile project you would want to spend to eliminate risk. That could threaten the success of this high profile project.

But a low project priority way over there at the end, the dashed line coming down, those projects, like you’re going to replace all the keyboards or you’re going to decommission a piece of equipment, it’s a low priority, doesn’t have a lot of significance in the organization. So we’re not going to spend as much generally to eliminate risk in those scenarios. So it’s just pretty common sense. The more important a project is, the more willing an organization will be to spend money to eliminate risk. All right, so those are some themes we’ll see throughout this section.

3. Trends and Emerging Practices in Project Risk Management

As we continue our conversation about planning and managing risk events, there’s some other terms we need to introduce here. There are two levels of risk that we want to talk about. So we’ll get into these in just a moment. But we’re talking about individual project risk and overall project risk. So individual project, project risk are the little events. Not necessarily little, but the independent risk events in your project. Like the vendor could be late, the software could not be compatible with all of our laptops. The servers may have a faulty disk drive or whatever. So they’re individual risk events. The overall project risk is the risk exposure or how risky is the project in the organization. So it’s the overall risk exposure. So when we talk about risk exposure, we’re talking about both threats which are negative risk and opportunities which are positive risk.

 So we’re looking for risk exposure. We’ll see that term a few times in this section. None. Event based risk are variability risk. So we have unknowns here to some extent, uncertainties around a project activity or decision. So there could be fluctuations in productivity. So we anticipate we can make 1000 units per hour, but that number could vary based on the piece of equipment, who’s operating the equipment, any defects in the material, who knows these variables that could cause the fluctuations in productivity. Also the number of airs or defects, not always predictable. So how many airs or defects, how does that fluctuate? And weather is a non event based risk. It’s variable, it’s not every day does it rain, every day it’s sunny, you have a variety of weather. So it’s a variability risk, another non event based risk or ambiguous risk.

So again, uncertainty. It’s impossible to predict the future of technology changes all the time, there’s lots of competition, people are coming up with new inventions all the time. So it’s ambiguous. You can’t say specifically that a technological risk is going to happen. So there could also be you have new laws that’s ambiguous. You don’t know if the law is going to really pass or not until it does or does it. And then just the complexity of the project creates some ambiguous risk events. So you imagine building that skyscraper and you have all these different moving parts, lots of different team members, lots of different skill sets and vendors and so on.

So just the complexity of the project could create some ambiguous risk events. A term that we need to know in light of ambiguous or nonevent based or variability risk will be project resilience. Project resilience describes the awareness of unknowable unknowns. Like, we know the weather changes, we know that the project is complex, but we have lots of unknowns within that. So it’s unknowable unknowns. You don’t know exactly when the lightning is going to strike. Risk can only some risk, these that are, that are unknowable unknowns can only be identified after they happen. So after the lightning strikes, you say, yes, well, there’s a risk it happened. Or after the hard disk fails, okay, it happened. We couldn’t have seen that coming.

Or a project team member suddenly comes in, and I won the lottery and I quit. Bye. So that’s an unknowable unknown. Emergent risk require project resilience. So we need the right level of budget, and we need some contingency that schedule contingency your management reserve. We need to be flexible so when these unknowable unknowns actually happen that you can respond to it, you’re resilient, so you have some flexibility to respond. So that means that our processes aren’t so structured and so tight that we don’t have an opportunity to respond to the problem that we can’t. Okay, there’s a hard drive failure that we can’t say, all right, swap it out from that machine and get it over here, and we’ll replace this one. But right now, we need this hard disk and this server or whatever the case may be. So we don’t want to be so flexible that we’re not allowed to do quick solutions like that. So we need the project team empowered.

That may not be the project manager saying, swap out those different disk drives to keep the project moving. It might be the project team member making that decision and say, we’ll go through procurement and we’ll replace that hard disk, but we need over here’s our project. We need this one right now, or whatever the case may be. We want to have frequent reviews of early warning signs. A warning sign is also known as a trigger or a condition that the risk event is emerging, that it’s likely to happen. This could also affect our project scope or strategy. So we may have to make some adjustments there as a result of our risk response.

So we want to be flexible. We need project resilience. Of course we can tailor our risk management processes just like every process that we’ve seen based on the project that we’re managing. So the size, the complexity, how important or its priority, and then the different developmental approach will determine to what extent can we tailor these processes. When we talk about tailoring, we always have to consider what are our enterprise environmental factors or the governance that controls or restricts the project. So how much flexibility does the PM have when it comes to tailoring? But generally, you think about the size and the complexity that the bigger the project and the more complex the project project, the more likely we are to tailor or to go more in depth with our risk management approach. All right, great job. I’ll see you in the next lecture.

4. Considerations for Adaptive Environments

Let’s talk about risk management in an adaptive environment, in an adaptive environment we know that change is part of that life cycle. So in an adaptive environment is a high variability environment, lots of changes, lots of uncertainty, which can mean more risk. So in an adaptive environment we need some frequent reviews of our project work. So remember, we have incremental reviews, we do those retrospective and sprint reviews. We also want to think about having a cross functional project team that we are generalizing specialists, so we can call on a lot of different resources to help with these ambiguous risk and the high variability of risk that we have. When we do identify a risk in an adaptive environment, we want to make certain that we really do some analysis here, that we really understand the risk event and what effect can it have on our project, what effect can it have on our objectives for that iteration or for the project as a whole? Some other considerations for adaptive so risk is what we have to take into our planning as we start each iteration.

So we look at the requirements that we’re going to create in this iteration and what risk may be within these requirements. Is the sizing of the requirements or the user stories, are those really valid or accurate? Do we have experience doing this type of work before? So we want to look at each risk events and then we look at how that risk may play out in this iteration now in the product backlog. So even before we start the iteration over here in the product backlog, we want to look at the requirements and say as these are updated, what risk are being introduced, so the work can be reprioritized based on what risk may be introduced into these product requirements. So to put that in a practical scenario,

when you look at your product requirements, depending on what the priorities are, there may be one requirement that has a lot of risk, there’s a lot of uncertainty about that requirement. So you may, with the product owner lower that in priority that we’ll take that one on later. Let’s get some wins here, let’s get some success here and we’ll attack that guy later in the project as we can learn more about it or think more about it, or as we have more time and money later in the project, assuming that we don’t consume all the budget and all the time to create the more important requirements. So lower requirements, you could reshuffle those by risk, you don’t always get to do that.

Of course, sometimes that’s a high priority requirement and it does have a lot of risk, but maybe you assign more, what we call story points to it, so you take on less work and you can spend more time on the risk management for that requirement. In an agile environment we do have a risk management approach, the start of an iteration. And then as I mentioned, at the end of the iteration, so you look for risk in each iteration. You do it with your project team, the product owner, and then when you’re done, you look back on that iteration, you say, okay, what did or didn’t work? What risk came into fruition and how did we respond to it, or how do we still have to manage that? You can also do this while it’s in motion, but when you’re in motion, we’re generally adverse to change. So this is typically more about the project manager and the project team. And even really more specifically, team is the one that is going to address risk events. So remember that the team is a self led team in an agile environment. So it’s really about what’s in motion and how can they respond to those risks as that iteration is happening. All right, good job.

5. Planning for Risk Management

We need to create a risk management plan. The risk management plan will really tell us how do you do the rest of the processes here in this knowledge area of risk management? So that’s the goal of the risk management plan. It really isn’t planning for risk and responding for risk, it’s the plan on how you do the rest of the activities. Here it defines how you will identify risk, analyze risk, make risk responses, and then control risk once you’ve identified them.

Now, it’s not just you, the project manager, of course you’re going to work with your project team, with your subject matter experts, with stakeholders. So this is a group activity. It’s not done alone by the project manager. The attitude or the approach that we often have to have, especially if we’re part of a program, is an integrated risk management approach. What this means is that the risks are integrated throughout that entity, like a program, but each project is responsible for owning their own risk events.

So you’ve got this big umbrella of the program, or even a portfolio, and then each project manages the risk events. And then within that project, the ownership of the risk is delegated to the project team and even to individuals. You get down to having a risk owner. Now, some risk may be outside of the control or authority of the project team and the project manager. So it’s escalated to the program manager or to management to deal with. So it could be a negative risk event, it could be a positive risk event, like an opportunity that you see, but that opportunity is outside of the project. So you would take that risk and you could promote it onto management or the program manager. This introduces this idea of an enterprise wide risk management is what’s needed.

So in a very large project, a very large organization, an enterprise wide risk management approach means that we all have some structure, some framework, some governance, and some policies on how risks are managed, what are the thresholds, what’s a high level versus a very low level or a moderate risk? So how is the risk management approach for everyone in the organization? Risk efficiency is part of the organization and the approach. So how do we quickly identify, analyze, create responses and then monitor? So we don’t want to draw this out because risks often aren’t waiting, right? So the project team is executing.

You can’t pause indefinitely to ponder risk events. So you do need to take some time to study, but we want to be efficient in that study and our response. Let’s check out our edo’s here for planning risk management. To create the risk management plan, we will have the project charter, the project management plan, project documents, the stakeholder register and EEF like I was just talking about, and OPA tools and techniques. Your expert, your project team, stakeholders, consultants, your experts, data analysis, you do stakeholder analysis to understand the tolerance level of your stakeholders, and you have meetings. And then our only output, of course, is the risk management plan.