Create Risk Management Plan
The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually define the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes.
Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a risk management specialist. For a very large project, third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the project team.
Budgeting. Discuss your budget for risk management. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. The initial risk assessment should be performed early enough to affect the planning and estimating work. The detailed risk response plans should be revisited periodically during project execution to ensure they are working as expected.
Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
Thresholds. The threshold level is how you determine which risks are important enough to act upon. The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks. Typically, risks above the threshold will be responded to. Risks under the threshold will not be responded to (or will just be monitored).
Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status. If you have already covered this information in the Communication Management Plan, this section may be bypassed.
Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.
These are examples of the content that would be included in the risk management plan.
Assumptions and Risks
The quick definition for an assumption is that it is a “statement believed to be true”. In other words, you are not 100% sure if it is a fact, but you believe it to be true for the purposes of planning your project.
Projects need assumptions. You cannot delay a project while you try to be 100% certain of all aspects. In fact, it is not possible to be 100% sure of every aspect of a project. In some cases you need to “assume” that things will turn out as you expect, and continue planning based on those assumptions.
Another way to look at assumptions is their relationship with risks. Assumptions are very much related to risk, and in fact are simply low-level risks. They both start with the same premise. They are both future events or conditions that will impact your project. In both cases, there is a probability of occurrence and an impact to your project. The difference between an assumption and risk has to do with whether the combination of probability and impact is acceptable to you or not.
Let's take an example of a common statement that is included in many Project Charters – that “the resources needed for this project will be available when needed.” What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.
However, is it always an assumption? Can you imagine starting a project where there was a realistic possibility that they would not be ready when you need them - perhaps because another project needed to finish first? It is not too difficult to imagine that scenario. In that case, the same statement would definitely be a risk - not an assumption.
The key point is that the same statement might be an assumption or a risk depending on the circumstances of your particular project. The difference between an assumption and risk is whether the combination of probability and impact are acceptable to you or not. If the combination of probability and impact are not acceptable to you (that is, the combination is too high), it can be stated as a risk. If the combination of probability and risk are acceptable, it can be an assumption.
One way to identify important assumptions is to perform a risk assessment and look at all the low-risk items. Most of these low risks are not worth mentioning, but some will have significant implications if events do not turn out as you think. These are the ones that you can document as assumptions. |
