If you’ve worked on projects, I’m sure the term risk management will not be foreign to you.
There are several ways to deal with risks and oh so many factors that contribute to how you will approach and deal with them.
But as always, I’m here to help you consider a slightly different view on risks and shine a light on an area we often don’t consider.
What does risk management mean to your team?
While our first considerations are the actions we will take to address risks on our project, Step 1 should actually be, what does risk management mean to us as a team?
If you asked a sample set of people, you would find that we all naturally have a different definition for risk. We have a different level of tolerance of risk and our tolerances will vary depending on the risk topic.
These different perspectives on risk happen, because we all have unique past experiences and beliefs which are based on what we have seen, heard, and dealt with.
For example, if I have had a bad experience with user requirements, I am likely to be less tolerant and more aggressive when managing user requirement type risks. This will likely result in me wanting to take more urgent action to prevent the same past experience from re-occurring.
My team on the other hand, may not have had negative experiences with user requirements, making them more relaxed about taking any actions to mitigate these types of risks.
Another influencer is someone’s natural appetite to risk. You may naturally be a risk taker and prefer to ‘wing it’, unlike your colleague who only loves calculated risk.
Or you may simply have a natural tendency to be risk averse.
Each of these characteristics cause people to react differently to risks and will result in a variety of issues if not properly supported.
From these examples alone, you can start to see how issues can easily occur within your team around urgency and the type of action or inaction taken to address project risks.
Unfortunately, unless these differences are known and addressed at the start of the project, you will only discover them when you’re facing problems – and this could impact you meeting your commitments.
The most common causes of poor risk management
In my experience, the most common causes of poor project risk management are:
As with everything I talk about on projects, having tools is only ever fully beneficial if people understand why they need it, how it should help them improve, how to use them, and who should be involved. RAID (AKA Risk) registers or risk meetings are no exception!
Just because you have a meeting to discuss risks and a document to capture it, doesn’t mean that the risk will be identified, managed, or dealt with in the best way to maximise the team’s success.
It takes more than just a good system for identifying and recording risks.
Here are 4 Powerful Ways to Improve Risk Management on your project
To account for the team’s varying experiences and beliefs, it is important to set some uniformed and unified standards.
This helps to take the emotion out of the risk and instead, follow an agreed process to achieve the best outcome for the project.
Standards should include:
Working to risk standards will improve team and stakeholder accountability. This is because everyone on the team is aware and has been trusted to follow the agreed process. The team knows what to do, where to go, who to involve, and how to work towards mitigating a risk.
Having a set of standards also creates the opportunity for team members to talk about things they have been burnt by in the past and provides them an opportunity to help the team avoid them occurring on this project.
To ensure everyone has the same meaning when they are managing risks, it is important to set clear and agreed definitions for terms that could cause misunderstanding of the risk or the urgency of it’s treatment.
Common examples of this include:
Team members and stakeholders should understand what each criticality means so risks are always rated following the same metric. For example, what constitutes a severe risk and what impact does it have on the project vs a low severity risk?
Is this the person on the project responsible for providing updates or the person responsible for solving or mitigating the risk (who could be an external stakeholder)
How is the likelihood of the risk occurring defined?
When a risk is closed, does this mean it has been accepted, or is it no longer a threat, or has it been resolved?
At the very least, the project team should have a high-level awareness of all project risks.
This knowledge will help the team to understand the pressures on their colleagues and the overall project. And even if this has no immediate impact on them, it provides awareness of potential impacts.
Aside from the project team, there may be common key stakeholders you may need to involve in risk meetings. These people should be agreed up front, so necessary stakeholders (and team members) are provided sufficient notice to attend meetings and be properly informed.
The process of closing out a risk is something that’s often forgotten.
While a risk might be assumed closed because it’s noted in an email, project teams seem to rarely discuss and formalise risk closure.
And when you don’t officially close out a risk, how do you know it’s really closed?
The questions you want to answer are:
Processes created for your people are the key to improving risk management
The best way to manage and mitigate risks is to set clear processes that everyone is able to follow.
But having an appreciation from the outset as to how our individual risk appetite and experience can cause issues when managing risk in a team is just as important. It’s this understanding that helps us to develop standards and processes that leverage our wisdom while removing our biases.
And when you combine processes with people in the right way, you’ll have the most powerful way of improving risk management on your projects.
Subscribe for insights, tips and strategies to help you deliver powerful projects.
We support and inspire project teams with insights, tips and strategies that build their confidence in delivering powerful projects.