CompTIA Project+ PK0-004 – Managing the Project Risks part 1

1. What’s a risk appetite?

A term that we use often in project management, especially from a portfolio management perspective, is risk appetite. In this lecture, we’ll take a quick look at exploring attitudes towards risk. Often when we think about risk, we think of when we’re taking a risk that’s dangerous, but really risk, it’s not bad. It’s the impact that can affect us. So for example, you have investments in the stock market. You could make money or you could lose money. So that is a risk. Now, financial advisors will tell us that we should distribute our investment. So some are very solid stocks, while others may be more risky that we could lose that money. But if those stocks do well, we could make a lot of money. Well, that talks about risk distribution and our risk exposure. We’re offsetting risk events. So risk appetite is really how we manage risk in expectation of rewards.

So risk, we know it’s not always bad, it can be the impact that we worry about. And we also have to look at, well, if we take this risk, what’s the reward? So a great example here about risk and reward. If you play golf and you’re a very confident golfer, you might tee up and take your golf swing and have that ball go all the way over a lake onto the green. Now, if you’re playing with me, I’m probably going to lay up. So I’m going to aim away from the water and probably have one more stroke because I know I don’t have the confidence, I know that if I hit my ball, I just seem to find water. So the risk here is if I cut that water, I can get up on the green, but the risk could be that I don’t make it and I end up in the water and I have an extra stroke. So risk and reward, if it’s a really narrow lake, well, maybe I’ll take that risk and get the reward.

If it’s a really big lake, well, then I’m going to play it safe. I’m going to avoid the risk. In business, we say, well, we could use a new vendor, they have a lower cost, so we could save some money. But the risk is we’ve never worked with this vendor before, so that’s just one example. Whatever risk we look at, we have to look for what’s the reward? Are we getting any gain out of it? So risk isn’t always bad. Now, there are two types of risk in project management. You have business risk and pure risk. Business risk are where there could be an upside and a downside, like the new vendor in that analogy, that we’ve never used this vendor before and if we use this vendor, we might be able to save some money. So that’s a business risk. Well, if the vendor doesn’t come in on time, we’re going to lose some money.So that’s the risk. But the reward could be we’re going to save money.

Now, a pure risk means there is no upside. So for example, there’s risk dealing in construction, there’s risk in health care, there’s risk dealing with electrical work or manufacturing or what have you. So pure risk means there is no upside and we take additional steps to avoid or mitigate those types of events. So when we go into plan for risk, we need to understand what’s the enterprise environmental factors, what’s the attitude towards risk events? What about risk tolerance? Risk tolerance means if we look at probability and impact, we would say, well, we really have to mitigate or eliminate any risk, any risk that’s greater than 90% probability, even if its impact is low. Or we might do the opposite. We might say any risk that’s greater than $10,000, we have to mitigate.

So risk tolerance describes kind of a tolerance level of where we will tolerate certain risk events based on probability and impact. Now, a risk threshold, a threshold describes kind of a point that if we hit the risk is going to happen. So, for example, if we don’t have the cabinets installed in this home construction project by July 31, well, then we are going to be late on putting the floor in and painting the walls and so on. So our threshold is if we come to July 31 and that work isn’t done, everything’s going to be pushed off for a couple of weeks. And maybe that’s because the vendor who’s doing the floor says we have to start on July 1 or else we can’t come back to the project until July 15 or whatever the case may be. So risk tolerance describes I’m sorry, risk threshold describes that point that it’s kind of a warning sign that if we go past that point, then we’re going to have a risk come into fruition.

So then we take steps to not get up to that date of the end of July or whatever the case may be. Stakeholder tolerance describes a stakeholder’s willingness to accept rents. So in this chart we see over here to the right, generally, the higher the project priority, that dash line that we see leading up, the higher that dash line is represents the higher the project priority, the more important the project is. And generally, the higher the project priority, the more willing an organization or a stakeholder will be to eliminate and spend money to mitigate or eliminate or avoid a risk event. So if it’s a very low priority project, then my risk tolerance is pretty high. If it’s a very serious high priority project, my risk tolerance is low. So I want to spend more money to avoid risk events. Now, risk risk tolerance and risk appetite, sometimes that’s called the utility function. So just know that term. It’s tied to risk acceptance and tolerance and just your appetite towards risk.

2. What’s in the risk management plan?

Planning for risk management. This is a project management process that every project manager should do for every project. And it creates the risk management plan. So in this session, this lecture, we’re going to look at how you plan for risk management. So what’s in the risk management plan? Well, the risk management plan, it defines how will these risk management activities occur. The risk activities in relation to project importance. Remember, the higher the priority of the project, the more willing we are to spend money to eliminate or avoid risk events. This plan also defines how key stakeholders, not just the project team, but key stakeholders, will identify and analyze risk events, how will create risk responses and then how will we control risks throughout the project.

Now, the inputs, tools and techniques for this process, we have several inputs. The project management plan, the project charter, stakeholder, register, and then of course, enterprise environmental factors and organizational process assets. The tools and techniques, the big tool here is analytical techniques. How will you analyze the risk events? And we’ll be looking at that in a moment. Expert judgment. We’re going to rely on our project team and key stakeholders, perhaps some vendors or consultants. And then of course, we have to have meetings in order to do that. The output, just one, is the risk management plan. Let’s talk about some analytical techniques here, planning, meetings and analysis. We have to get together with our project team and stakeholders to review the risks that we’ve identified to talk about the cost of the risk events.

Also, what impact do these risks have on the schedule? And then this will help us to write the risk management plan. Now recall that enterprise environmental factors and organizational process assets were part of our inputs for this. So our risk management plan, we may have some rules in our organization where we have to use a particular plan or approach or have it approved or organizational process assets. We could take a similar project and look at its risk events and its risk management plan and adapt it to this project. Or maybe there’s a template that we could use for our risk management plan. Enterprise environmental factors may include some policies about how we manage risk events. So think about the nature of the work.

The risks that you’ll have in a healthcare project, or a construction project, or a manufacturing project, or an It project, they’re all going to be different types of risks. There’s no uniform way to manage risk in each industry now. So the point I’m making is the nature of the work will dictate how you manage that risk. Now in your industry, you may have some particular standards. Like in It, we talk about backups and fail safes and secondary servers or rollover servers. In some industries you have regulations, so you think about in pharmaceuticals there are regulations about how those companies make the drugs or pharmacies for the safety of the people that are taking those drugs.

This all contributes to the creation of the Risk Management Plan. The Risk Management plan defines that methodology relevant to your industry, industry standards and any regulations. The risk management plan also defines the roles and responsibilities. So this is key because we’re talking about the ownership, sometimes just called the risk owner of risk that fall in a certain part of the project. So for example, in construction we have risk dealing with electricity. Well, the risk owner of course would be those licensed electricians. So they would be the role and responsibility. It’s just a way of assigning risk. The people closest to the risk are empowered with risk responses and management. We’ll talk about responses in a moment.

Now, budgeting and timing, there may be a cost to your mitigation or avoidance. It may take time to do your risk response. And then you may also have some risk categories. Like I mentioned the electrical work, you could also have risk in plumbing and construction with framing and on and on it could go. So it’s a way of slicing out the risk based on the different types of projects, the different areas within your project. Now, the risk management plan also defines probability and impact. And I’ve talked about that a couple of times. Now, probability is the chance of an event happening and the impact is what’s the financial impact. And this allows us to create a probability and impact matrix and we’ll be doing that in just a moment. Stakeholder tolerance for risk.

Recall that the higher the priority of the project, the lower my tolerance and then just the inverse, the lower the priority of the project. Perhaps my tolerance then is higher for risk reporting formats. Who do you have to communicate with about risk and then how will you track risk through your project? Now, I mentioned risk categories. Risk categories can follow the work breakdown structure. You can create what’s called a risk breakdown structure. So like in this example, we have a technical area of a project, any external risk events, the organization and project management. So let’s look at project management. Often we don’t think about risk being in project management, but if my estimates are bad, that’s a risk.

If I’m not effectively planned, if I’m not involved in the project, if I’m not communicating well, those can all be risk events. External, you think about vendors and regulations, what happens in the marketplace, what happens if the customer cancels the project, force majour, so weather. So that’s an idea here of a risk breakdown structure. It looks kind of like the WBS. Now, risk categories can also be just real high level technical quality or performance. And I just want to come back and stress that idea of project management, risk and organization, risk. And then of course, as I mentioned already, external risk. So it’s important to recognize these for your exam, but also to be an effective project manager.

3. Identifying project risks

An ongoing process in your project is to identify the project risk. Risk is an uncertain event or condition that can threaten the project, but it can also be an opportunity to help the project. So risk isn’t always a bad thing. Now, most of the time we think about risk, though, we’re thinking about threats to the project. When we look to identify risk, we identify, but we also document the risk events. This creates a risk register. You might also see this as a risk log. It’s basically a database, like an Excel spreadsheet, that you would list the risk events, their characteristics, and then you would track that throughout the project. So identifying the risk happens over and over and over. Usually each week in your status meeting is a great time to talk about risk.

What risk have passed or occurred? What risks are pending? Are there any new risks that have come onto the project scene? So you do this throughout the entire project. Now, to identify risk, we have several inputs, tools, and techniques and outputs. Inputs for risk identification, the risk management plan, the cost management plan, schedule management plan, quality management plan, HR management plan, the scope, baseline activity, cost estimates, activity duration estimates, stakeholder register, project docs, procurement docs, enterprise, environmental factors, and organizational process assets. A lot of inputs here, but if you look at these inputs, there’s something really interesting. When you look to identify risk, our first tool and technique is documentation reviews.

So look how many of these are documents and plans that you’ve created. So what we’re learning here is we should go look at our plans and all these documents and see are our estimates accurate? Are these realistic? Are there any risk lurking, like in our scope or our stakeholders or other project documents? So that’s the first tool and technique is documentation reviews. Then we have information gathering techniques, studying, talking, having meetings, and so on. And we’ll look at that in one moment. We have checklist analysis, assumptions analysis. We’ll have some diagramming techniques, SWAT analysis, SWOT. It’s not just SWAT SWOT because it means strengths, weaknesses, opportunities, and threats, and then expert judgment. Our one output here is the risk register.

 Some information gathering techniques. Well, brainstorming. You get together with your stakeholders and you do some brainstorming. Just anything goes. Any risks at all that you want to identify, they go into this brainstorming session. The Delphi technique uses rounds of anonymous surveys to build consensus on risk events. The reason why this is important is if we all go to a meeting and you’re my boss, I don’t want to throw a risk out there that might make you look bad. So if we could do an anonymous survey where I could identify the risk without you knowing that I’m the one who said that was a risk, then the risk truly is identified and dealt with. But you don’t know I was the one who submitted it.

And then the reason why it’s rounds of anonymous surveys is after this first round then the risk will be compiled and we’ll look for commonalities and so on.And then we’ll create a second survey about the risks that were identified. And then people can say, yes, this is a valid risk or no it’s not. And then we do it again and again and again until eventually we all agree on what risk or in the project. Now it’s called the Delphi technique because it’s based on the Oracle of the Delphi and so that is why it’s the Delphi technique. And so the Oracle, the Delphi was someone who could see into the future and to make wise decisions and to help resolve difficult questions. And so that is the Oracle at Delphi.

And not that you’ll see that on your exam, but just if you’re wondering why it’s called Delphi, there you go. All right, some checklist help you identify a risk and then assumptions or anything that you believe to be true but you haven’t proven them to be true. So an assumption can be a risk. And then some diagramming techniques where you break out the components of a project and you look at all the possible attributes of it, what the possible risk may be and that helps you to identify risk in their probability and impact, which we’ll talk about. Coming up, another diagramming technique, flow charting is a great way to see, okay, where could there be risk in this process flow? Where could there be risk in this work flow? So that’s another diagramming technique.

Now the one that I really want you to pay attention to is this one. And this is called an ishikawa ishikawa Kawa diagram or a fish bone or cause and effect. This is something that you’ll definitely most likely see on your exam. So the effect is the thing you’re trying to solve. And then you have the causes over here, these different factors of time machine method and so on. So this helps have the conversation to what causes may be contributing to the effect. Cause and effect. These causes are sometimes known as causal factors. And then you could break these out again. So you could keep like for example, you could take personnel and say, well in personnel we have contractors and internal employees or we have engineers, we have database administrators, we have It support.

You could just continue to break these down into more than one groups and those are all called causal factors. But that’s ishikawa fish bone or cause and effect. It’s all the same diagram I mentioned SWAT strengths, weaknesses, opportunities and threats and then expert judgment that you can rely on experts to help you identify risk and to gather information. The Risk Register is a central risk repository. You might sometimes see it called a risk log. But a Risk Register is the preferred name. It’s all of your identified risk, any potential responses, root cause analysis. You can create good and accurate responses.

You might use risk categories where you might say, okay, all the risks dealing with plumbing are here, and electrical is here, and so on. The reason why you do that is when you create risk responses, you might be able to create one risk response that would knock out two or three risk. And then as you move through the project, you have risk status like it’s still pending or it’s in motion or it’s passed. So it allows you to track risk and what their outcomes may be, and then that becomes part of organizational process assets. So it’s historical information. If you do another project like this, you have that information to go back to and see how you manage that risk in the past.

4. Using qualitative risk analysis

Performing qualitative risk analysis means that you’re going to take a fast, subjective kind of a gut feeling of a risk event and what its impact on the project may be. So it’s just a real quick way to analyze risk events events. So performing qualitative risk analysis, let’s hop in and look at this project management process to perform qualitative risk analysis. As I mentioned, it’s a fast subjective approach to analysis. All that we’re doing here is we’re saying this risk has some probability and it has some impact. If that first glance tells us that the risk probability is high and the impact is high or it’s a serious risk, then that risk needs to go on to quantitative analysis. So I like to say that qualitative analysis means that we are quantifying the risk events.

Qualitative analysis where we are now means that we are qualifying the risk for more analysis. We’ll talk about quantitative in the next lecture. For now we’re going to focus on this high level subjective analysis of qualitative risk analysis. This can be done just as each risk is identified, or you can collect all of the risk through risk identification and then do qualitative. Now typically this is done with an ordinal scale ordinal as an ordinary high, medium low, red, amber, green, very high to very low, or a cardinal scale where you could say on a scale of one to 100 or one to ten or whatever scale you wanted to use. So typically it’s an Ordinal scale. Now this process has several inputs, tools and techniques and only one output.

So the input here the risk management plan, scope, baseline risk register, and then enterprise environmental factors and organizational process assets, tools and techniques. To do qualitative risk analysis, you have your risk probability and impact assessment and we’ll be looking at that in one moment. Then we have our probability and impact matrix. So the probability and the impact give us a risk score, risk data quality assessment, risk categorization, risk urgency assessment, and expert judgment. The sole output of this process is project documents, updates, and what you’re going to be documenting here is your risk register or risk log. Let’s look at a probability impact matrix. So all that it is, is a table and you identify the risk in the first column and then you have probability and impact.

And this is a table that’s using an Ordinal scale of low to high.So it’s real quick. So we say, well, the probability of data loss is low, but if it happens we have a high impact. And then we say, okay, well, a low probability and a high impact, that’s a moderate score. So we could do that for each risk event. And so it’s subjective is the score. All that we’re doing here is filtering out those events like email service down, that has low probability and low impact. The enterprise environmental factors may dictate which one of these based on the risk score should go on to quantitative risk analysis. So this is very subjective. It’s kind of a gut feel. It’s real fast. Now, some other qualitative tools you need to be familiar with risk data quality assessment.

How reliable is the data to say the probability is low and the impact is high? How are we proving that? Risk categorization? Remember, we can create categories like our risk breakdown structure and we could say, okay, I need all the people that are dealing with it to examine these risk events and then I’m going to have a meeting with all the people that are dealing with the electrical work to look at these risk events and so on. So it’s a way of categorizing and finding roles that know about that particular risk that could say the probability is high or low or what have you. Now, risk urgency assessment. This means that when a risk is identified, we can look at that risk and say, oh, this is very imminent, it’s very serious as well. So rather than do qualitative, we can just look at it and say, this needs to go on to quantitative analysis.

Generally, risks that are in the near term, they have a higher urgency than risks that are in the long term. Of course, you might also have some risks that you can see long term, that they’re going to have a high probability and a high impact. So they should go on to quantitative. This is all based on expert judgment. If I don’t know anything about your industry, I certainly am not one to go in and say this is a low risk or a high risk because I don’t know. We need someone that is an expert in that industry or close to that type of work. So your project team members, consultants, maybe some key stakeholders or people in your organization, they can come in and help you filter the risks that are low from the risks that have a high probability and a high impact.