Any time there’s anything that might occur on your project and change the outcome of a project activity, we call that a risk. A risk can be an event (like a fire), or it can be a condition (like an important part being unavailable). Either way, it’s something that may or may not happen…but if it does, you will be forced to change the way you and your team work on the project.
There are 7 Process in this Plan Risk Management Knowledge Area.
- Plan risk management. Planning process group
- Identify Risk. Planning Process Group
- Qualitative Risk Analysis. Planning Process Group
- Quantitative Risk Analysis. Planning Process Group
- Plan Risk Response. Planning Process Group
- Implementing Risk Response. Executing process Group
- Control Risk: Monitoring and Controlling.
The Risk Management plan is the only output of the plan risk management process
It tells you how you’re going to handle risk on your project—which you probably guessed, since that’s what management plans do. It says how you’ll assess risk on the project, who’s responsible for doing it, and how often you’ll do risk planning (since you’ll have to meet about risk planning with your team throughout the project).
The plan has parts that are really useful for managing risk:
- It has a bunch of risk categories that you’ll use to classify your risks. Some risks are technical, like a component that might turn out to be difficult to use. Others are external, like changes in the market or even problems with the weather. Risk categories help you to build a risk breakdown structure (RBS).
- You’ll need to describe the methods and approach you’ll use for identifying and classifying risks on your project. This section of the document is called the methodology.
- It’s important to come up with a plan to help you figure out how big a risk’s impact is and how likely a risk is to happen. The impact tells you how much damage the risk will cause to your project. A lot of projects classify impact on a scale from minimal to severe, or from very low to very high. This section of the document is called the definitions of probability and impact.
The another four risk management process are:
Identify Risk, Perform Qualitative Risk Analysis, and Perform Quantitative Risk Analysis, Plan Risk Response.
Note: All the processes are in Planning Process Group.
Identifying Risk: TO identify a risk you use information gathering technique:
Four useful information gathering techniques
Brainstorming is the first thing you should do with your team. Get them all together in a room, and start pumping out ideas. Brainstorming sessions always have a facilitator to lead the team and help turn their ideas into a list of risks.
Interviews are a really important part of identifying risk. Try to find everyone who might have an opinion and ask them about what could cause trouble on the project. The sponsor or client will think about the project in a very different way than the project team.
The Delphi technique is a way to get opinions and ideas from experts. This is another technique that uses a facilitator, but instead of gathering team members in a room, the facilitator sends questionnaires to experts asking about important project risks. The facilitator will then take those answers and circulate them all to the experts—but each expert is kept anonymous so that they can give honest feedback.
Root cause identification is analyzing each risk and figuring out what’s actually behind it. Even though falling off of the cliff and having your tent blow away are two separate risks, when you take a closer look you might find that they’re both caused by the same thing: high winds, which is the root cause for both of them. So you know that if you get high winds, you need to be on the lookout for both risks!
The risk register is built into the Risk Management plan. Updates to the risk register are the only output of the Identify Risks process.
Besides, some risks will cause a whole lot of damage to your project if they happen, while others will barely make a scratch…and you care much more about the risks that will have a big impact. That’s why you need the next Risk Management process, Perform Qualitative Risk Analysis—so you can look at each risk and figure out how likely it is and how big its impact will be.
Perform Qualitative Risk Analysis helps you prioritize each risk and figure out its probability and impact.
Points to Remember
- The main output of all of the Risk Management planning processes is updated project documents, and the main document that gets updated is the risk register.
- The first step in Risk Management is Identify Risks, where you work with the whole team to figure out what risks could affect your project.
- Qualitative and quantitative analysis are all about ranking risks based on their probability and impact.
- Qualitative analysis is where you take the categories in your risk plan and assign them to each of the risks that you’ve identified.
- Quantitative analysis focuses on gathering numbers to help evaluate risks and making the best Decisions about how to handle them.
- Decision tree analysis is one kind of expected monetary value It focuses on adding up all of the costs of decisions being made on a project so that you can see the overall value of risk responses.
- To calculate EMV, be sure to treat all negative risks as negative numbers and all opportunities as positive ones. Then add up all of the numbers on your decision tree.
- Don’t forget watch lists. They let you monitor lower-priority risks so that you can see if triggers for those risks occur and you need to treat them as higher priorities.
Plan Risk Responses process
The strategies for handling negative and positive risks are the tools and techniques for the Plan Risk Responses process.
Control Risks (Monitoring and Controlling) is another change control process
Risk responses are treated just like changes. You monitor the project in every status meeting to see how the risks in the risk register are affecting it. If you need to implement a risk response, you take it to your change control board, because it amounts to a change that will affect your project constraints.