Project Risk Management is the process or activities associated with identifying risks, analyzing risks, developing appropriate responses to risks, and monitoring risk triggers. Risk management is a primary role of the project manager. While other project team members will be involved in all of the Project Risk Management processes. It is the responsibility of the project manager to ensure that risk management is done and that risk triggers are being monitored.
The PMBOK has defined Risk as, "an uncertain event or condition that, if it occurs, has an effect on at least one project objective." The objectives are identified during project initiation and include the major elements of scope or deliverables, key milestones, budget constraints, or any other aspect of the project identified as a key success criteria by the stakeholders.
Risks can be positive or negative. Typically we focus on negative risks, and these are the ones that are likely to result in project failure. However, there are positive risks which are opportunities for the project team to perform better than required on at least one of the major objectives. In my experience, positive risks, referred to as opportunities, must be identified early in the planning processes to take advantage of them in the project. Otherwise the cost and schedule impact of changing the plan will typically outweigh the benefit. Negative risks, referred to as threats, can be avoided if addressed early. However, these must be monitored and tracked throughout the life of the project.
The process of project risk management typically is viewed as a five step process. The first step is Risk Identification. Next is Qualitative Analysis and, when necessary, Quantitative Analysis. Once analyzed, Risk Responses must be developed for those risks that require them. Finally, Risk Monitoring must be done for those risks that require ongoing monitoring. I prefer to manage this process using a Risk Register.
Risk Register
The Risk Register is a spreadsheet that tracks the management of risks, both threats and opportunities, through the project lifecycle. The register not only aids the project manager in the process of risk management, it creates a document for archiving with the project files that can be used for Lessons Learned and a historical record.
The Risk Register is structured so that each row is a risk and the columns track information associated with the various risk management processes. The precise columns you use are a matter of personal preference. I like to have columns that identify the risk and where in the project the risk will have an impact. I then have columns indicating the results of qualitative analysis and quantitative analysis. I also have columns showing the selected risk responses and the status of any mitigating actions or the risk triggers that are being monitored.
Risk Identification
In order to do effective risk management, you must start with risk identification. That sounds really "Duh," but I have set in many project reviews and asked questions about the risk identification process only to find that it was never done. Instead someone copied the risk list from a previous project and started working with it, even though many of the items did not apply to their project.
There are many ways to identify risks and if your organization has a standard approach that works, use it. When there is no standard approach, my preferred method is to use a variation on the Fishbone or Ishikawa diagram. I start with a major project impact such as, "major schedule delay" or "test failure." I then try to identify all the possible reasons why that might happen on this project and document those in the bones of the Fishbone. I normally will do several of these diagrams, one for each major project impact. I will do these for both project threats and project opportunities. For instance, I might have one for, "Early completion" or "Major Under-run." All of the items that are listed then are transferred to the Risk Register for further analysis.
Qualitative Risk Analysis
Once the list of potential risks has been developed, the next step is to analyze them. This can look to be a daunting task if there are many risks. Therefore, the first step in the analysis is to filter the risks to determine which are the significant risks and which are insignificant. There are many techniques for this and they are known as qualitative risk analysis. I will discuss three of my favorite, the red-light/green-light rating, the risk matrix, and the urgency assessment.
Quantitative risk analysis are techniques that attempt to quantify the project impact of the risks. These techniques are generally much more complex than the qualitative techniques and therefore require much more time and effort to complete. I find that if I do the qualitative techniques first, I then can focus my quantitative techniques on just the few high risk items. These are the items that are most likely to require a significant amount of project management effort and possibly discussion with stakeholders to address threats to boundary conditions. Prior to the stakeholder meeting, I like to have a quantitative analysis done so that when I meet with stakeholders we can focus our discussion around the business impact of doing nothing as compared to doing something. The following is the list of quantitative techniques I recommend.
All of these techniques require hours and possibly days to complete. There are other quantitative riak techniques, however, I find that they are even more time-consuming and expensive. The results of the other techniques are typically no better than the ones listed above.
Based upon the analysis, some risks will require a response in the project plan, some will only require a response in the project monitoring, and some will not require any response at all. If a risk is deemed to be high, it needs a response. Responses to negative risks - threats, are one or a combination of these five responses:
There are also five possible responses for positive risks - opportunities. In almost every case, these opportunities must be identified early in the project if there is to be any hope of realizing the positive benefits they entail. The five responses to opportunities are:
It is important to note that in the absence of choosing to do something different, the "Accept" option will apply to any threat or opportunity. If "Acceptance" is not appropriate for the risk, action must be taken to either change the plan or to begin monitoring the risk trigger.
Risk monitoring is much of what a project manager does once a project moves beyond the planning stage. As project activities are being accomplished, the project manager should be tracking the risk triggers to see if any project changes are needed. The risk triggers should be listed on the team-level project dashboard. In addition, I revisit the risk register whenever a project goes through a replanning and at major Management Reviews to determine which risks have been eliminated and to add new risks to the register.
I also use the risk register to document the result of risk monitoring activities. The risk register tracks the status of project changes or mitigations that have bee initiated to address risk issues. The risk register also captures the impact of mitigating actions for those risks that are mitigated.