This article is part eight of my look into project risk management, and today the topic is qualitative risk analysis.
I did not expect this to turn into so many parts, but risk management is an in-depth topic and there’s a lot to cover!
In case you missed them, and to save you a job digging through the archives, here are the quick links back to the previous instalments:
Read part 1 here: An introduction to risk management
Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)
Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)
Read part 4 here: Tailoring Risk Management
Read part 5 here: Planning Risk Management
Read part 6 here: The Risk Management Plan
Read part 7 here: Identify Risks Process
What is qualitative risk analysis?
What is it, apart from being a word that lots of people (myself included) stumble over and get confused with quantitative risk analysis (more on that next time).
Qualitative risk analysis is simply the process of prioritising the risk based on probability of occurrence and impact, as well as some other characteristics if they are relevant. It’s what most of us would recognise as an important step in project risk management – the part where we decide which are the risks we are going to focus on because we don’t have time to spend effort on all of them.
Perform Qualitative Risk Analysis is the third process in the Knowledge Area of Project Risk Management.
The point of doing it is to prioritise individual risks by looking at how likely they are to happen (probability of occurrence) and how bad they would be for the project if they did happen (impact). When you look at those two data points, you can prioritise all the project risks.
As with risk identification, it has to happen throughout the project because risks come and go and also change in severity. Something that has a low probability of occurrence today could have a dramatically different likelihood of occurring tomorrow if something else happens to make it so.
The process doesn’t talk much about risk proximity although it is mentioned in a ‘other factors you can consider’ list in the PMBOK® Guide. I find proximity another useful measure for prioritising risks. That looks at how soon the risk is likely to happen if it happens at all. Risks that are likely to occur far in the future can be postponed for a bit while the team focuses on risks that have a likelihood of occurrence for next week.
In the process we review the risks we identified and prioritise them based on our subjective opinions and those of the team. Therefore it’s only useful if we also understand the risk assumptions and attitudes being brought to the table by the people doing the assessing.
It’s important to note that the assessment of risk is relative – you compare the risks on this project to each other, and come up with a relative priority. If you compared them to the risks on another project, you’d probably get a different result.
The inputs to this process are:
- The project management plan – mainly the risk management plan which tells you how you should be analysing and prioritising risk based on the matrix and data in it
- The project documents, especially the assumptions log, risk register and stakeholder register
- Enterprise environmental factors like industry studies or commercial risk databases
- Organisational process assets like info from past projects.
The stakeholder register is important because it gives you input as to who should be involved – and because assessing risk is generally subjective, even if you do try to use data-based categories for the assessment, it’s helpful to know what their risk tolerances and appetite are. If you use a neutral (professional) facilitator, they can help uncover some of the bias in the team and assess the risks more objectively. You’d hope, anyway.
Tools and Techniques
There are also quite a lot of tools and techniques, many of them centering on interpersonal skills and professional knowledge.
The tools and techniques you’re likely to use include all of these (there are quite a few to choose from, you won’t necessarily use them all on the same risk – pick and choose what makes sense to help the analysis of the particular risk you are looking at):
- Expert judgement (although bear in mind they could be biased given past experiences)
- Data gathering from interviews
- Data analysis (obviously, in a process to do with analysis)
- Interpersonal and team skills, notably facilitation as we also saw in the risk identification stage
- Risk categorisation (use the risk breakdown structure or your categories list for this)
- Data representation – this just means how you write down the output of your analysis. You can use a probability and impact matrix or a hierarchical chart like a bubble chart or just keep the info in your risk log and use that
There are quite a few ways you can do data analysis.
Risk data quality assessments: This is where you look at how reliable the data is that you are using for your assessment. If the data scores low, you will want to get some better data on which to base your next steps and action plan.
Risk probability and impact assessment: This is what most people think of when they think of risk analysis. It’s the table you will find in your risk management plan that tells you how a risk will score based on how likely it is to happen and the impact to the project or business if it does.
Other factors: You can consider pretty much anything you like when you make your judgements about risk. The PMBOK® Guide lists a few including proximity (as we saw above), controllability, urgency, connectivity and strategic impact.
Use as many criteria as you can do reliably and repeatably so you’ve got lots of data to go on when you make your risk assessments.
I tend to find that organisations stick to probability and impact, and some go as far as adding in proximity (how soon the risk is going to happen, if it happens). However, there are others, like how easy the risk would be to manage, how easy it is to detect and control, strategic impact and how connected it is to other risks – because that would influence a wider section of our risk pool
The challenge with doing the assessment is identifying unconscious bias in both the individuals involved in the process and the process itself. You’ll need to be aware of the risk appetite of the organisation and just challenge everything. Do your best!
The outputs of the process are updates to the project documents, specifically:
- the assumptions log
- the issue log
- the risk register
- the risk report, which is a document you’ll be creating as you go through the whole Knowledge Area, although I can’t say personally I have ever written one. The risk report info has always been contained either in the risk register or in monthly project and steering group reports.
The end result of this process is that you have a bunch of documents to update.
At the end of the process you get a list of risks (from the process to do risk identification) with a weighting or score of how risky they are. That feeds into a future process which is to look at what you are going to do about those risks.
You’ll want to make sure your assumptions log, risk log, issue log and risk report are all up to date.
These are all living documents so in case you hadn’t realised by now, this process is something that repeats during the life of the project. You’ll be doing risk prioritisation pretty much in every team meeting, or I’d recommend at least on a monthly basis.
Share the documents with whomever needs to see them so the whole team has access to the latest information.
In my experience, as you talk about the riskiness of risks, you also formulate ideas for what you might do to mitigate them. So the processes happen in parallel, often within the same risk workshop. It’s helpful to understand them as separate activities, but don’t worry if you end up planning risk responses at the same time as having a conversation about how troublesome the risk is likely to be.
Next time I’ll be looking at quantitative risk analysis.
Pin for later reading