Managing risk is a core knowledge area in The Guide to Project Management Book of Knowledge (PMBOK ®). According to the PMI’s Pulse on the Profession®, one of the leading trends in 2015 is greater focus on risk management:
More rigorous risk management: This year, 83 percent of high performers report frequent use of risk management practices, compared to only 49 percent of low performers.
Carl Pritchard, a project risk management guru, refers to effective risk management as ‘planned clairvoyance.’ By intelligently creating a framework to look into the future and identifying potential situations, behaviors, and reactions, we can peer into the crystal ball. Consequently, we can plan today for these future events.
Successful risk management begins with the basics. The risk log is the foundation of the risk management practice. Here are seven tips for getting the most from your risk log:
- Register meaningful risks
- Depict risks as IF…THEN statements
- Measure the impact and likelihood using simple, relative terms
- Identify all the risk owners
- Document risk response triggers
- Plan viable mitigation options
- Review the log regularly
Meaningful Risks
Contents
Register risks that are meaningful and pertinent to the project. Pertinent risks will resonate with the team as tangible and viable concerns. Too often risk logs include generic statements that are not specific or material to the project, for example:
There may be changes in scope after requirements are complete.
Subject matter experts may not be available.
There may be delays in installing new hardware.
The hardware risk could be improved by identifying which hardware component (e.g., the production server) and specifics about the dates and dependencies to make it meaningful and tangible.
Building the initial risk list can be accelerated using brainstorming techniques such as the Crawford Slip Method. Once the project is underway, additional risks are often collected through regular project meetings. An attentive project manager may hear something and say, “I think you just expressed a risk, can you help me articulate your concern?”
IF…THEN Statements
Risks are best depicted as IF…THEN statements. IF this event occurs, THEN the outcome or impact is the following. For example:
IF the new production server is not delivered and fully configured by October 15, THEN there will be a delay in the application deployment planned for November 15.
Simple Terms for Impact and Likelihood
It is best to use simple, relative terms like: “high”, “medium”, and “low” to calibrate the impact and likelihood of risk events. Translating probabilistic statements into meaningful consequences challenges most people. The PMBOK recommends a 5-point rating scale. However, a simpler scale promotes greater consistency without compromising on the intended outcome—identifying the risks that are the largest concerns.
Continuing with the example:
- The impact of not having a production server would have a “high” impact on the project success. Most companies require segregated hardware for production and production servers are generally more powerful than the lower environments.
- The probability of the event occurring will change over time. The project manager should know the minimal recommended durations for each step in the procurement, installation, and configuration process. As these timelines compress, the likelihood of the server not being ready will increase from “low” to “high”.
Risk Owners
There are several roles in the risk management process. The roles should be documented in the risk management plan; and the risk log should identify who is responsible for each of these roles.
At a minimum, the following roles should be identified:
- Risk Monitor: Person responsible for monitoring the risk and reporting its status.
- Mitigation Owner: Person responsible for establishing and executing the risk mitigation plan. The owner of the mitigation plan is responsible for ensuring that a viable plan has been created.
- Decision Maker: The person responsible for making the decisions, such as: accepting the risk, invoking the mitigation plan, or canceling the project if the risks become too great.
In our previous example: the project manager may be responsible for monitoring the risk. The infrastructure manager may be responsible for identifying and executing the mitigation strategy; and the project sponsor may be the decision maker.
Risk Triggers
It is important to clearly identify the trigger events or conditions for invoking the mitigation plan. Establishing these preconditions helps ensure a timely response. Triggering events should be specific and quantitatively measurable. For example: the production server needs to be delivered, configured, with a completed shakeout test by November 1.
This trigger provides specific conditions that need to be met and a specific deadline. The deadline also leaves two weeks to execute the mitigation plan.
Setting clear, measurable triggers better also facilitates the difficult conversations about the risk or when to invoke the mitigation plan. Due to the “escalating commitment” phenomenon, risk owners may be less likely to invoke the mitigation plan if the trigger is not clear.
Viable Mitigation Plan
The primary objective of managing risk is having a thoughtful response should the risk be realized. The primary characteristics of a viable remediation plan includes:
- The plan has specific, clearly documented steps;
- The remediation plan is achievable and can be successfully implemented in the allocated time.
Depending on the risk, the potential impact and severity, it may be prudent to document multiple alternatives in the plan.
In our server example, there are several possible options, including:
- Lease a server or use a cloud service.
- Repurpose a lower environment or put the new application on a server with another existing production application. Both of these options include critical assumptions about capacity and performance.
- Delay the implementation of the project. If the implementation date is not constrained, this might be the best mitigation strategy.
These are all potential options. For them to be viable, additional analysis and planning would need to be conducted and documented.
Review the Log
The project manager and team should regularly review the risks to ensure:
- Continued relevance to the project. As the project progresses the impact and/or likelihood of the risk changes and needs to be updated. Close risks that are no longer relevant.
- All components are up to date. Review the owners, mitigation plans, triggers, etc. and make sure they are still accurate.
- Clarity of the risk. Too often our written communications do not bare the test of time; what once seemed clear, no longer makes sense. Review the risk statement, trigger, and mitigation plan to ensure that the information is still understood by the team.
Adopting good risk management practices is like purchasing insurance. The cost of following good practices is inexpensive. If the risk event materializes, then the investment pays for itself.
© 2015, Project Management, Essentials, LLC
Sources:
Project Risk Management. (2013). In A guide to the project management body of knowledge (PMBOK guide) 5th Edition. Newtown Square, PA: Project Management Institute.
Pritchard, P. (2014). Risk Management Concepts and Guidance, Fifth Edition (5th ed.). Hoboken, New Jersey: CRC Press.
Pulse of the Profession®: Capturing the Value of Project Management. (2015, February 1). Retrieved July 22, 2015, from http://www.pmi.org/~/media/PDF/learning/pulse-of-the-profession-2015.ashx
Brockner, J. (1992). The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress. Retrieved July 22, 2015, from http://www.jstor.org/stable/258647?seq=1#page_scan_tab_contents
Also See:
Projects and Probabilities: A Dangerous Combination
Closing a Project: Ask the Right Questions
One thought on “Peering into the Crystal Ball: 7 Tips for Successful Project Risk Management”
Comments are closed.