Risk Management Practical Tips
Table of Contents
Despite the super-accessibility of information, there are still people who turn a blind eye to a number of obvious things. This results in wasted time, money and effort. In this article I will try to make risk management as simple as possible.
Working with risk is, in my opinion, one of the most important aspects of being a project manager. Have you ever been in a situation where you have solved a big task, spent a lot of time on it, and just before the finish line you started to feel insecure? And how often have you had thoughts of ‘do or die’, ‘wasn’t done’, etc. in your head when completing tasks? Were there times when, at the finish line, you said to yourself or out loud ‘it’s over’ and felt relieved? Or, on the contrary, did you pound your fist on the table in frustration?
These are all indicators that you have not spent enough time on risk control. In some cases you’ve wavered, in some cases you’ve turned a blind eye, and in some cases you’ve taken a chance. But problems arise no matter how much we believe in our luck.
For myself, I think of risk management in the following way. My head is a kind of loft (attic) on which a scientist’s cat walks in circles and from time to time makes notes in a notebook. He is particularly meticulous in noting mistakes, wrong decisions and omissions. And as the deadline for the project approaches, the notes in his notebook grow, and your anxiety begins to grow. But you don’t know it yet. In the following, I propose to analyse what you can do with all this and how you can turn this scientific cat and his notes into your helper and ally.
Forming a team
No one person can be an expert in everything. This is why teams work on projects. It is much harder to achieve good results alone. Everyone has their own life experience, their own way of looking at the world and their own prejudices. Everyone judges what is happening from their own point of view - and this allows you to get the full picture and make the right decision.
Let us recall the parable of the elephant and the blind wise men. Several blind wise men were brought an elephant and asked to answer what kind of animal it was. Each of them felt the part of the animal available to him and came to his own conclusion. The wise men disagreed and did not know what kind of animal they were looking at. One felt a snake, one felt a tree, etc. But each of them was right, based on the data they had. The problem was that none of them took in information from their colleagues. If they put their observations together, they would most likely be able to identify the elephant.
Now let’s imagine that a sighted person is added to your team. He can see things as they are and tell them what is really going on. In this case there would probably be no parable.
Risk management is no different. Everyone has a different perspective and it is important to gather as much detail as possible to make a better decision.
When recruiting people for the team, choose people with different backgrounds. You may not have a ‘sighted’ person, but a team of ‘blind’ people can work together to identify which animal is in front of them and how to feed it.
Handing out tools
- Who am I to defy the elements? Just a speck of dust in an infinite universe.
- Fucking hell, Petrovic! Get a shovel and clear the snow!
In classic project management, it all starts with the creation of a risk management plan. This document outlines how risks will be managed. The document may also include methodologies and tools to be used, roles of participants, risk categories and other details that can help formalise the risk management approach.
This document will answer many questions during the project, but it will be time consuming, especially if you have not done this before.
In practice, a risk register and a risk map are used instead of a risk management plan.
Risk Register
The register is a simple spreadsheet that can have from three to dozens of columns, depending on how detailed the risks are. You can keep it in any spreadsheet (Excel, Google Sheet) or wherever you like - the main thing is that you use it.
For ease of use, you can add columns for the date of identification, the person responsible for the risk, a comment for the risk response strategy (accept, avoid, etc.), risk type (threat/opportunity), category, risk cost and other attributes you want to control.
In project management - a risk register is created when you start working on a project. Business cases, which are used to present the project at a high level, identify the key risks known at this stage, along with the expected benefits.
Risk map
One risk register may not be enough. The number of risks identified may be so large that it takes three times as long to control them as the project itself.
To make the right decision about which risks to control, a risk map is used to show all the entries in the risk register in a diagram. By looking at it, we can easily identify the items that need attention.
The risk graph is usually constructed according to the following rules. On the axis of the abscissa is the impact of the risk on the project - the higher the value, the greater the impact of the risk. On the ordinate axis - probability of occurrence of the risk event. The diagram can be conditionally divided into 4 squares:
- High probability - High impact
- High probability - Low impact
- Low probability - High impact
- Low probability - Low impact
And then we put the risks from our registry on it.
Communication as a secret weapon
A key factor in reducing the likelihood of risk is communication. During meetings/calls with stakeholders, pay attention to all factors and events that may affect the project, both positively and negatively.
There is a perception that once someone has spoken out loud, they think everyone has understood them. But some people may not have paid attention to what was said. Don’t let valuable comments and remarks go to waste.
Let’s take an example. Developing an extension for the system. There is 1 day left to deliver the work as planned. Another phone call with the developer, in which I want to hear that everything is ready.
- Hi, how is the plugin going?
- Hi. Yeah, it’s good. It’s almost done. There’s still one thing I don’t know how to do.
At this point, a red light bulb goes off in your head - you need to start the task with an understanding of how it will be done. For the developer - if something is unclear, it means we need to study it, and that can take a long time. Let’s make it clear.
- What is the moment? Something complicated?
- It’s a series of technical details that an untrained person would drown in, that I don’t quite understand.
- I see. What are you going to do with it?
- I don’t know yet. I’ll see what Google has to say. The light bulb is starting to flash more often.
- I guess I’ll have to write to the developer of the system itself, check with them.
At this point we should stop and consider the following. A developer can spend several hours searching for a solution, there is a chance that he will not find it, and we will have to contact the system vendor, which can easily take several days.
I decide to agree with the developer that I will get back to him in 2-3 hours with an update. If he does not find a solution in that time, I fix the risk and analyse the work plan to determine the time margin.
These situations are common and can be traced in any dialogue. Take notes as the conversation progresses, clarify where necessary and, if appropriate, add the identified risks to the register for further work.
Even a small comment can uncover a whole layer of problems just waiting for you to set yourself up by starting to implement.
Separate meetings can be scheduled to discuss risks. You can set aside time in meetings for these issues. Of course, you can think it through on your own. But risks are best discussed with all the people involved in the project.
Conclusion
Don’t forget that even the PMI RMP level will not protect you 100% from risk.
There will still be situations that you cannot control. There are problems that
- Could have been prevented, but no one foresaw them;
- were foreseen and planned for, but things didn’t go as planned.
Risk management is first and foremost a skill that can and should be developed. The theoretical part can be learned:
- Project Management Standards;
- specialist literature and courses.
I recommend Tom DeMarco’s book ‘Waltzing with Bears’ as a starting point. Now, the practical part is something you should do every day on your own.
Learn from your own and others’ mistakes, draw conclusions from the situations that arise. Then the number of ‘fires’ will be minimal.