Risk Management and Issue Management are related processes that are critical to project and program management success. For the sake of simplicity, the focus of this article will be on project-based risk and issue management. Understanding these processes at the project level will provide the foundation to be able to extrapolate these concepts to the program level.
A project risk is anything that has the potential of negatively or positively impacted a project. Note that a risk does not need to always be a negative impact. Risks that have a potential to positively impact a project are called opportunities. For this post the focus will be on negatively impacting risks because identification of negatively impacting risks are generally the priority of projects and the things that keep project managers awake at night.
A risk is a condition that has not occurred yet. For example, if a company’s production website is hosted on one server with no on-site or off-site backup or recovery processes in place, then it is evident that there is a risk of a single point of failure. If the server fails for any reason, then the company’s production web site will be down until they can recover the server or replace it with a new one.
This seems like simple enough concept, right? Good. Now let’s put a bit of construct around the way a risk is identified, measured, mitigated and monitored:
- The Risk Management Process:
- Risk Identification
- Risk Measurement
- Risk Mitigation
- Risk Monitoring and Review
1. Risk identification
Generally, there are two acceptable sentence structures for documenting an identified risk — the If-Then statement, and the Condition-Consequence statement.
- If-Then Risk Statement Format: If [event], then [consequence]
- If the company’s production web site goes down, then the company will lose internet sales until the server can come back up.
- Condition-Consequence Risk Statement: Given [event], there is a risk that [consequence]
- Given the fact that their production web site is hosted on one server with no documented backup or recovery options readily available, there is a risk that we could lose internet sales if the server goes down.
Both formats of risk documentation are acceptable. The Project Management Body of Knowledge (PMBOK) prefers the second option. I happen to prefer the second option as well. I find that it easier to write a risk statement clearly with the second option.
The risk is logged and managed on a Risk Ledger, which is generally a spreadsheet of risks that are maintained and reviewed periodically. There are also tools that can support the development and maintenance of a Risk Ledger. A risk ledger, at a minimum, contains the following fields of information for each risk:
- Risk Number – a unique number for the risk – used for identification purposes or for associating the risk to other information as needed
- Risk Name – a brief name to quickly recognize the risk
- Risk Description – a description of the risk written in risk statement format
- Risk Date – the date that the risk was identified
- Risk Owner – the person assigned to be responsible for the risk (Risk owner specific responsibilities vary, but generally, the owner is responsible for the risk in some manner)
- Risk Trigger – the event that would trigger the risk (In the server example above, it would be “The server crashes”
- Risk Mitigation Strategy – a description of the activities that must be put into place to mitigate the risk — thus reducing the probability of the risk from occurring and/or the impact of the risk should it occur (In larger projects, the risk mitigation strategy might require a separate document in order to capture the complete details.)
- Risk Contingency Plan – contains information on what needs to take place if the risk is realized (Once the risk is realized, meaning that it comes to fruition, the risk becomes an issue. An issue is a condition that is currently impacting the project negatively. Specific activities must kick in to action to resolve the issue. So in the server example above, the contingency plan would be to install the application on a development server and make the development server temporarily the production server until a new production server is bought and configured.)
- Risk Status — open, closed
- Notes — Notes from periodic status updates from the risk owner
2. Risk Measurement
Once the risk has been identified and documented, a risk owner must be assigned. Generally, a project that has a mature risk management process has a risk group that is responsible for reviewing, analyzing and mitigating risks. The risk is assigned by the Risk Group Lead. The person assigned to the risk is the recognized as the Risk Owner.
It is up to the Risk Owner to assess the risk, validate that it truly is a risk and identify a mitigation strategy for the risk. A mitigation strategy is the plan of action that needs to be put in place to ensure that the risk is not realized.
This risk review team reviews the risk and measures the probability and impact by assigning a probability and impact score — where probability is the likelihood that the risk could be realized, and the impact is the severity of the consequence should the risk be realized. The risk score is a product of these two scores (Risk Score = Probability x Impact). For example, let’s assume that the probability score and the impact score values are 1, 2 and 3 for low, medium and high respectively. If the risk team indicates that the probability that the server might go down medium, but the impact is high, then the Risk Score is 6.
Risk Score = Probability x Impact
All identified risks must be assessed for probability and impact, a risk owner must be assigned to ensure that the risk is mitigated through the project life cycle, and a risk score must be assigned to each risk. The risk score serves as a measure of the risk’s priority. The higher the risk score, the higher the priority.
Depending on the project’s risk tolerance (Tolerance levels can be different from project to project, or from organization to organization), a decision must be made to take one of the following actions:
- Accept the risk — There may be cases where the risk does not pose enough of a risk (based on risk score, probability or impact). Therefore the cost of mitigating the risk might be much more than the cost of the risk itself, should it occur. Or the risk probability might be so low that a calculated risk is taken to accept the risk.
- Avoid the risk — For example, if a risk is associated with a specific module or component of code, and the component can be put off for a future release or just de-scoped from the project, then a decision can be made to avoid the risk altogether.
- Transfer the risk — Outsource the work so that the responsibility of mitigating the risk becomes the responsibility of another service provider or contractor.
- Mitigate the risk — Make a conscious decision to develop a strategy to mitigate the risk to that it is not realized
3. Risk Mitigation
Should the decision be made to mitigate the risk, the Risk Owner, working with the Risk Group, is responsible for devising a risk mitigation strategy for the assigned risk. The risk mitigation strategy, or risk mitigation plan is a plan that is put into place to reduce the probability of the risk from taking occurring and reducing the impact, should the risk occur.
Using the previously mentioned example of the single server production environment, a mitigation strategy might be to back up the application server. Another mitigation strategy could be to have another hot-backup available so that if the primary server fails, the second server could take over.
3. Risk Monitor and Review
Once a risk mitigation strategy is in place, the risk group must periodically monitor the risk to ensure that the risk is being mitigated. This can take place through periodic status updates by Risk Owners via meetings or reports.
If the risk is realized, meaning that the risk trigger actually takes place — in this case, the trigger being the fail of the production server — then the risk becomes an issue. An issue is a condition that is currently having a negative impact on your project. See the next post for more on Issue Management.
Risk Management is a very broad subject. For further research, refer to the links below. There are also many Risk Management certification programs, including one by the Project Management Institute called the PMI-RMP certification (http://www.pmi.org/certification/risk-management-professional-rmp.aspx).
Please comment below if you have additional comments or feedback. Also feel free to let me know of additional risk management references, trainings and certification programs.
- http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf The Risk Management Guide for Information Systems by the National Institute of Standards and Technology (NIST) is a very good and complete reference on Risk Management
- http://www3.imperial.ac.uk/riskanddisasterrecovery/riskmanagement/riskproceduredecember2008 — goes much more in-depth about other risk management topics such as identifying causes of risks, risk tolerance and risk strategies
- http://www.pmi.org/certification/risk-management-professional-rmp.aspx — The PMI-RMP certification
About the Picture: A beautiful fall day in October in the Plains, VA