All risks are not equal and do not deserve the same level of attention. So, once we have a reasonably complete and categories list, it’s time to prioritize them.
Prioritization makes it possible to identify which risks we want to invest time in, so the prioritization process itself should not require a great investment of time and effort. The most efficient method is to engage the expert judgment of your team and collaboratively score each risk. For best results, consider engaging subject matter experts and impacted teams from across your organization to gain better insights into the risks. For example, if you have risks which could impact your organization’s Support Desk and end users, bring in leaders from your Support Desk to help analyze and prioritize those risks. This is another benefit of risk categorization we did in step 2, above.
This is a subjective assessment performed by you and our team, which is why it is sometimes called a Qualitative Assessment. This is a judgment based analysis, so we aren’t bringing in a lot of science here. The end goal of this process is simply to prioritize the risks, so don’t get too hung up on the details.
The scoring of your risks is done in two dimensions:
- Probability: How likely is this risk to actually happen?
- Impact: If it does happen, how bad will the impacts be?
Probability is pretty straightforward in that it is a measure of likelihood ranging from so remote that it is nearly impossible to so likely that it is a near certainty.
Assessing impact is a bit more involved because there are many potential dimensions to impact. For example, risks can impact your project in terms of:
- Budget – your costs go up
- Schedule – work gets delayed
- Scope – deliverables can’t be done
- Quality – deliverables may not come out quite as well
- Resources – the team may not be available to support the project as required
But realized risks can also impact your organization’s core business operations, well beyond the scope of your project including:
- Production operation – impacting the way the business operates and supports its customers
- Reputation/ PR – impacting the way the market views your organization
- Customer Relationship – impacting customer satisfaction, threatening future business opportunities
So, when assessing the potential impact of a risk, be sure to assess the total impact, not just one dimension of it, or from the exclusive view of its impact to the project.
Scoring
There are different methods for scoring Probability and Impact. Some organizations like to use percentage (% chance and % impact to budget and schedule). This provides two scales of 0-100, which are intuitive and allow for a large range of choices. Another common approach is to use a scale of 1-5 for Probability and Impact, 1 being low, 5 being high.
Whatever method you use, be sure to clearly define the scale so your scoring is consistent and understood by your team. Below are some examples for a 5 point scale of probability and impact with definition for each level. Although a 5 point scale is common, you should use a scale that is familiar to your organization if they have one. I’ve worked with scales of all types, including a descending scale of 1-4 (1 being the highest value) for a Fortune 50 organization. It was weird, but that is what they were used to.
Example: Definitions for 5 Step Probability and Impact Scoring
Probability could be scored as:
1 – Very unlikely 0-10%
2 – Unlikely – 10 – 49%
3 – 50/50%
4 – Likely – 51-75%
5 – Very likely 75%+
Impact could be defined as:
1 – Low – <10% impact to project schedule, budget or scope. Miss no major project success factors, no impact to business operation
2 – Minor – 10-20% impact to project budget, schedule or scope. Miss no major project success factors, no impact to business operations
3 – Moderate – 20-30% impact to project budget, schedule or scope. Possible impact to major project success factors. Minor impact to business operations
4 – Significant – 30-50% impact to project budget, schedule or scope. Significant impact to major success factors. Clear impact to business operations
5 – Critical – 50%+ impact to project budget, schedule or scope. Inability to achieve project success factors. Significant impact or outage to some business operations
Prioritizing using P*I
Once you have the Probability and Impact scored, then you multiply the two numbers and get a “P*I” score. This numerical value represents the priority of the risk, which you can use to stack-rank and prioritize your risks for the next steps.
Some organizations have standards around how to handle risks of different P*I scores. For example, I worked with an organization that had a policy that any risk of P*I of 16 or higher (based on a 5×5 scale) had to be reported weekly to the project sponsor.
Remember, this is just a qualitative analysis to help you better understand which risks to focus your attention on. The P&I score is not proof of anything in itself. It’s just a way to help you be smarter about risk management.
Accounting for Different Impacts
Although not a part of typical scoring, it is important to account for the prioritized impact areas discovered earlier. For example, if you have a project that must be completed by a certain date, then risks with a potential schedule impact are going to be more important than risks that don’t even if they have the same P*I score. But how do you handle this in your log?
The simple method is to add a column to your Risk log which lists impact areas so you can sort and filter by them. But, this doesn’t change your P*I score, so it’s not a true reflection of priority.
Another method I’ve worked with is a bit sophisticated for a basic RAID spreadsheet, but provides more accurate scoring. That is to weigh the P*I score based on which impact area is affected. You would do this by adding different weights to each impact area (Scope, Schedule, Budget, etc.) and incorporating this into your P*I score. This is more complicated than is needed for most projects, but is an option when you have some very sensitive risk areas to consider.
Trigger Date
A risk’s trigger date is the date by which a risk will either become an issue, or it can no longer become an issue and therefore no longer presents a risk. For example, if you have a risk that materials may not arrive on the job site in time for certain work to be performed, the risk will either become an issue if the materials don’t arrive on that date, or the materials arrive on time and there is no longer a risk. In this case, the delivery date is the trigger date.
There are different schools of thought around capturing trigger date. Some PMs only track trigger date when it can be tied to an event in the project schedule. Some capture it on all risks and if there is not a specific trigger date, then the trigger date is the end of the project. And some project managers don’t bother with trigger date at all. Personally, I like to always capture a trigger date: the exercise forces a bit more consideration of each risk, and risks can then be filtered for those with impending trigger dates which may need attention.
