PMI CAPM – Administer Project Risk Management Part 2

3. Identify Project Risks

In this lecture we’re going to talk about identifying project risk that we always want to be on the lookout for new risk events. This is from the very start of the project, really all the way into the finish of the project. I mentioned in the last lecture this idea, idea of risk categories. So risk categories are a way of chunking out your project into different buckets of risk events. And this helps us to create what we see in this slide is a risk breakdown structure. So we have technical, external, organizational and project management. Well, these are just suggestions.

Yours might be phase one, phase two, phase three, whatever. Or in your industry you might have some different logical grouping of where you put risk. However you organize your risk is fine. But typically we’re looking after three big categories of risk technical quality and performance. Technical being in your discipline like an It, there is throughput and bandwidth and uptime and some of those characteristics of softwares and networks and databases and then the quality. So the accuracy and the precision of what you are creating. And does that introduce risk for your stakeholder? Because poor quality is not good, you can’t have that. It’s also risk obviously for project success and then we have performance risk.

So how well are our processes performing? How well is our team performing? And is that leading to variances on time and cost which could mushroom and cause an overall problem with our project? Now, a special category here is project management risk. So project management risk are things like estimating, not having enough time for planning, communication risks that we aren’t getting responses back from stakeholders. Also in project management risk are things like if you have a predetermined budget or a predetermined deadline, that’s not realistic. Those are risks that affect the ability of the PM to successfully manage the project. So I get that question a lot.

Well what if we have a predefined budget and it’s too little? Well, that’s a project management risk. And yes, you are correct that you want to document that and that it’s not a way of just saying, I told you so if the project fails. That’s not what we want. But it’s a way of acknowledging that you believe this is a risk rather than just accept it and say nothing. Because sometimes management doesn’t know. They assume that this is enough money and enough time just based on what they think is a similar project. And that’s not always the case. Organization risk could be risk in your company, like in a matrix environment, could be changes in the marketplace, could affect your organization, maybe your company is going to get bought out or busy and seasonal activities could be organization risk.

External risk will be anything that’s external to your project. You have to deal with a vendor, you’re hoping they deliver on time, you’re waiting on the outcomes of other projects. So that could be an external risk. It’s anything that’s external weather, customer, the marketplace, regulatory concerns, you can see it’s anything there that’s external to your project that you have very little control over as the PM. So our process, eleven two in the Pinbox is to identify risk that we want to identify and document risk. It’s something that we do throughout the project.

We’re going to identify and document risk and this helps us to create a risk register. This is an ongoing activity done throughout the project, not just at the beginning, but you keep and maintain this risk register and you keep identifying risk throughout the project. Wow. Right, look at all these inputs. In order to identify risk, I’m going to show you something here. First, go to the tools and techniques. Look at the very first tool and technique documentation reviews.

So the bulk of these inputs are documentations. You’re looking at these documents to see if there are risks lurking in your project. So let’s check it out. We have the risk management plan as an input, cost management plan, the schedule management plan, quality HR, those are all of our plans that we’re going to examine for risk. What about the scope, baseline scope statement, WBS, WBS dictionary, activity costs and activity duration estimates, the stakeholder register, any project documents, any of that supporting detail. We’re going to look at procurement documents.

So we’ll talk about procurement in the next section, but there could be risk in our contracts and proposals and quotes and so on. And then of course enterprise environmental factors and OPA. Now our tools and techniques, documentation reviews. You’re going to look at these documents to begin identifying risk. We’re going to do some information gathering techniques. We got to get out and collect possible risk events. Checklist analysis. So a checklist is like we’re going to install a piece of equipment and we have a checklist on how to install it the same way every time.

So we look at that to see, well, are we missing any steps? If we’re in motion, are people actually following the checklist? So checklist analysis, assumptions analysis. An assumption is anything that you believe to be true, but you’ve not yet proven it to be true. So assumptions analysis, diagramming techniques, doing some ishikawa diagrams or cause and effect diagrams, decision trees, anything that it takes to plot out, maybe your workflow, things like that. A context diagram, anything that shows an opportunity for risk. You could use a diagramming technique, SWOT analysis, strengths, weaknesses, opportunities and threats in your project. And then expert judgment. All of that business gives us one output, the risk register. And of course the risk register is where we go to identify risk events, information gathering techniques.

So I talked a little bit about this a moment ago, but information gathering techniques, we’re looking at things like brainstorming. You bring people together and just put as many ideas out there as possible. Recall the Delphi technique rounds of anonymous surveys to build consensus. So this is valuable with risk identification. If I’m in a meeting and my boss is in the meeting, I may not want to say a risk that might make her look bad, so I may not say anything and the project suffers because no one identified that risk, even though I knew it was a possibility. So the Delphi technique takes that out, takes any repercussion or fears of repercussion out.

So we do those rounds of anonymous surveys so people are open and honest, but anonymous with identifying risk, as I mentioned, checklist assumptions, analysis. You have to prove your assumptions or really test your assumptions. Diagramming techniques, SWAT, expert judgment, just what we saw there in our tools and techniques. The goal of all of these is to identify risk. So you don’t have to do all of them, obviously, but it’s a good idea to do more than one because it’s different ways of uncovering risk events. And risk identification is an ongoing Iterative activity in your project.

The goal is to create this risk register. The risk register is your central risk repository, sometimes called the risk database because it’s electronic. So you could use Microsoft Excel, you could use Access, make up your own database. But it’s a way where you take the risk events and you identify and document those events well. You will also identify some potential responses for these events. You’re looking for root cause, especially with our risk categories, because I may be able to do a risk response where I can spend some money that we’re going to talk about coming up, and maybe I can address three, four or five risk all at once, especially if they have a common root cause risk categories.

Remember that’s our risk breakdown structure or different chunks or segments of our project where risk are lurking as you move through the project, in particular, status meetings are a great opportunity to say what’s happening with these risk events and to update the risk register periodically. We have to do a risk audit where I want to see what is the probability and the impact and the effectiveness of any risk responses.

Are those still valid? And if not, we need to change the risk status so that could change our probability and could change our impact. All right, good job. Some great information here, important information here about identifying risk events and creating the risk register. Now that we have the risk register, we can begin to do some risk analysis. So that’s what we’ll talk about in the next lecture. I’ll see you very soon.