Project risk is an inevitable part of any project.
Risks that are not mitigated ahead of time will likely become project issues.
Good project management dictates that risk management should be a planned and ongoing activity during the project.
In this article I’m going to go over some helpful techniques for managing project risk on a typical project.
By following these techniques, you will lessen the likelihood of project scope, time and cost impacts to your project.
Project Risk Planning
Early on in the planning phase of your project you should take the time to develop your Project Risk Plan. This will be a sub-component of your overall Project Plan document.
In your Risk Plan document artifact you should define and document several items as part of your overall strategy for managing project risk. This document should be well communicated and circulated amongst the team and stakeholders for their review and buy-in.
The project Risk Plan should include, but not be limited to, the following:
- Risk Methodology – High level description of how you will identify, categorize, monitor and control risk.
- Assumptions – Any assumptions being made that could impact project risk.
- Roles and Responsibilities – Each person’s roles and to-do’s in controlling risk.
- Risk Rating and Thresholds – How risk is qualified and corrective action gets triggered.
- Communications – How risk related information is to be shared.
Project Risk Techniques and Approach
In order to mitigate risk you need to take proactive steps to identify potential risks.
By no means exhaustive, what follows are some practical techniques for identifying project risk.
In addition, you’ll see a common way to classify risks and monitor and control risks.
Also included is the importance of engaging executive oversight in the decision making process.
Let’s start with lessons learned from previous projects.
Project Knowledge Capital and Lessons Learned
A common problem that occurs in project management is that the same mistakes are repeated over and over.
It’s not uncommon for the same risk to pop up from one project to the next.
Often, the current Project Manager may not be aware of those risks since they weren’t involved in those previous projects.
There is a simple exercise to mitigate this problem, however.
Usually, at the end of a project, the Project Manager will conduct a Lessons Learned meeting to capture and document the project risks and issues that were faced along the way.
More importantly, the actual mitigation steps that were taken are also documented and stored in the organization’s project library. Or, at least in the electronic project folders.
An exercise that is helpful during the planning phase is to go back and review the Lessons Learned from the previous projects.
Get the project team and stakeholders involved and meet to determine whether previous risks and solutions are applicable to the current project.
Then, document those as part of the Assumptions section of the aforementioned Risk Plan.
By doing this, you’ll already be taking steps to proactively mitigate project risk. And, if those risks should occur, you may already have a mitigation plan to follow.
Also, if an unexpected risk arises during the execution phase of the project, it’s not a bad idea to see if something similar occurred in a previous project and what the resolution was.
Project Risk Matrix
PMI defines two approaches to Project Risk Analysis: Qualitative and Quantitative
One of the most common Qualitative approaches to project risk analysis is to create a risk matrix and use it as a tool to determine the probability and impact of a risk occurring.
The matrix is also used to determine what mitigation actions are triggered when the risk occurs.
Here’s an example of a Qualitative Risk Matrix, based on the Software Extension to the Project Management Body of Knowledge:
On a regularly occurring basis, the project team and stakeholders should meet to brainstorm and discuss potential upcoming risks.
Those risks should be captured and documented by the Project Manager.
As part of that process, it’s important to run each risk through the above matrix to qualitatively determine the probability of the risk occurring and the impact if it does.
Use the experience and expert judgment of the team and stakeholders to assign impact and probability.
Once that’s done, use the matrix as a key to determine actions. For example:
Critical – There’s a very high chance this risk will occur and it will have very high impact to the success of the project. You should absolutely develop a detailed mitigation plan, with assignments and action steps prior to this risk becoming an issue. Failure to mitigate could have severe impacts to project cost, schedule, scope and resources.
Very High – There’s a high to very high chance this risk will occur and impact the success of the project. Develop a detailed mitigation plan as soon as possible.
And so on… The Project Manager and team should have defined the action steps at each level prior to using the matrix. Those actions steps should have been documented in the Risk Management Plan mentioned above.
Risk Log
Also known as the Risk Register, this is usually a spreadsheet where all the open and closed risks are documented.
Each risk should be listed. Typical column headers in the spreadsheet would include:
- Risk Identifier (i.e. a number)
- Risk Title
- Risk Description
- Probability
- Impact
- Rank (i.e. Critical, Very High, High, etc. from Risk Matrix)
- Description of Impact (should risk occur)
- Mitigation Action Required
- Person Assigned to Lead Risk Mitigation
- Status (open, closed, in-progress, allowed to occur)
- Due Date for Resolution
- Result of Mitigation
The risk log is then used as the primary document for communication and planning during regularly occurring Risk Review meetings.
As a Project Manager you should make sure to schedule those.
Importance of Governance in Project Risk Management
Governance is usually an organization’s mechanism for escalation and decision making. It’s often setup to include three or more levels. For example:
Level 1 – Project Manager and Team
Level 2 – Program Management
Level 3 – Portfolio Management
Level 4 – Executive Management
This concept can be very important and useful in Risk Management.
The reality is that sometimes, in order to resolve a risk, money needs to be spent or people need to be called in or an executive decision needs to be made regarding how significant a risk’s impact really is.
If this structure is in place it’s a good idea for a Project Manager to become familiar with those involved at each level and develop a relationship with them.
There will no doubt come a time when a decision needs to be made and not everyone is on the same page regarding the solution.
This is when leveraging the Governance structure can break a stalemate or redirect resources from another area to help out and help you to mitigate the risk.
Conclusion
To summarize, be sure to regularly address and document your project risks.
Use lessons from previous projects as a starting point.
Create a robust Risk Management Plan and think ahead of time how you and the team will handle risks based on a qualitative risk matrix.
Document all risks and build relationships at all levels in order to get buy-in and decisions made when help from outside the team is needed.
Be sure to assign individuals as risk mitigation leaders on the risk log and follow up often.
The subject of Risk Management is very complex and goes beyond the information in this article.
However, I hope you found this information helpful and useful for the projects you’re managing.
Now let’s hear from you… Any Risk Management techniques you’d like to mention?
Leave a Reply