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 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
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
The red-light/green-light rating is a subjective assessment of whether the risk will likely have a major impact on the project. The risks are divided into three groups, one is "red" risks, one is "yellow" risks, and the last is "green" risks. The thresholds for these categories can be based upon the cost impact, the time impact, the quality impact, the probability of occurrence, or a combination of these. I normally view the "red" risks as those that are likely to occur and will significantly impact one of the project objectives. These risks must be addressed; usually with an immediate change to the project plan. The "yellow" risks are those that may have a major impact on the project, but that I believe we can manage through with the current plan. However, they are serious enough that they are watched closely. The "green" risks are those that either are insignificant or they are risks that were once "red" or "yellow" and have now been mitigated.
The next approach for qualitative risk analysis that I use is the risk matrix. This matrix can be setup as a 2x2, a 3x3, a 4x4, or a 5x5. What size you use is based upon personal preference. The vertical side of the matrix is labeled probability and the horizontal side is project impact. The scale on the matrix goes from low to high on each side. How low or high are defined should be based upon the major objectives of the project. Once the matrix is created, I place each identified risk on a post-it note and then locate the risk in the appropriate spot on the matrix based upon the likelihood of that risk happening on this project and the impact to the project objectives if it did occur. The risks in the upper right corner are major risks that must be addressed in project planning. The risks in the lower left cornere are minor risks and can be ignored.
The third approach for qualitative analysis I use is an urgency assessment. In this analysis I consider when in the project the risk must be managed. Some risks do not have the potential to occur until late in the project, others would occur early, and still others could occur at any time. The urgency assessment identifies anything that is an immediate issue for the project management team and which risk issues are not yet in play.
Quantitative Risk Analysis
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.
Sensitivity Analysis - in this technique the project plan is developed without the risk factor occurring and then the risk factor is introduced and the plan is redone with the risk impact in place. This provides a demonstration to the stakeholders of why the risk is important and needs to be addressed.
Failure Mode Effects Analysis (FMEA) - this technique is excellent for addressing technical or quality risks. It is not very effective for addressing cost or schedule risks. However, since the risk is quantified based upon safety and security issues, it can be very useful for explaining why a change in project requirements is needed.
Decision Tree with Expected Monetary Value - this technique can require a significant amount of time to set up, but once established it can easily be reused as project assumptions start changing and the project is forced to react to the changing circumstances. The decision tree shows the impact of decisions and risk events on project activities and the expected monetary value quantifies those impacts.
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.
Risk Response Techniques
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 six responses:
Avoid - the project plan is changed so that it is impossible for the risk to occur because the project is never susceptible to that type of risk. Some risks cannot be avoided.
Mitigate - the project plan is changed so that when or if the risk occurs it will only have minor effect because the threat has been anticipated and provisions for addressing it are in place.
Transfer - the project plan is changed so that an outside agency assumes responsibility for addressing a portion of the risk impact.
Escalate - the project plan needs to be changed beyond the boundaries set in the Project Charter. This requires stakeholder approval.
Accept - the project plan is not changed because the risk is so insignificant or the risk is so improbable that no change is needed.
Contingency Plan - the project plan is not significantly changed, although a risk trigger is established that can be used to indicate whether the risk will occur and if so in what fashion will it impact the project. If possible a "Plan B" is developed, or at least has been considered. If the trigger occurs, the "Plan B" is put into effect and the project is changed at that time.
There are also six 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 six responses to opportunities are:
Exploit - the project plan is changed from the normal approach for this type of project to take advantage of the unusual condition that is occurring.
Enhance - the project plan is changed so as to create an opportunity for improvement in the ability of the project to achieve one of its objectives.
Share - the project plan is changed so as to bring an outside partner onto the project that creates opportunities to improve one of the project objectives.
Accept - the project plan is not changed because the opportunity is so small or so unlikely that the risk of change creates a negative risk outweighing the opportunity.
Escalate - the project plan needs to be changed beyond the boundaries set in the Project Charter. This requires stakeholder approval.
Contingency Plan - the project plan is not significantly changed, although a trigger is established that will provide notice that an opportunity is now available to improve on one or more of the project objectives.
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 and Control
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.
