Risks: Are you applying these FIVE good practices?
There are many articles on risk management in project management. You will find some very good ones at the end of this article.
Rather, let’s talk about good practices that are too little used. Indeed, this part of project management is most of the time what seems to be the best understood and … the least applied. Without further ado, here are my FIVE tips to improve your risk management.
1. Anticipate and plan your risk review
A common mistake is to list all possible risks at the beginning of the project. Very often, with a superb color matrix that the management loves and that the project manager is very proud of… Of course, with the hours he has devoted to it! Then, this list is stored in a corner and is never reused afterwards. What is the utility of a list of risks that is not followed? Absolutely none.
To avoid this, it is crucial to plan from the start of the project when, how and with whom the risks will be reassessed. Always present, modified, or no longer current, a mitigation plan to be reviewed… The status of each risk impacting the project can evolve rapidly. It is therefore necessary to keep this information as up to date as possible.
Therefore, it is imperative to have a “last review date” field in your definition of each risk. We recommend a weekly update of the risks related to a current problem. At a minimum, your risk list should be reviewed by the team once a month; or at the end of each iteration for the “agilists”.
2. Are your answers ready? Are you ready?
Any good definition of a risk must include a response in the event that this event occurs (“mitigation plan”). And most of the time, one is mentioned. But is that response realistic? Is it tested, communicated and accepted by all?
Having its answers regularly reviewed and updated is as important as keeping the risk itself up to date. In some cases, on projects where the risks are particularly critical, it can be very useful to set up either a control body (auditor) or a recurring session to validate the responses.
As in the previous section, this approach must be part of the points decided and implemented from the start of the project. The “last review date” of a response is also necessary here.
3. How many risks should I have in my register?
“The question is quickly answered”: as many as can be clearly identified, qualified, defined and anticipated.
It is better to have two or three risks that are well understood by everyone, with a clear impact and a realistic probability of occurrence, a workaround plan… than dozens of risks for which we do not have all the information. Depending on the size of the projects, we recommend focusing on monitoring the “top 10” or the “top 3” in terms of score. Remember that the score = Impact x Probability of occurrence
Another method for sorting out if our register is too large is to limit ourselves to risks that have a high probability of occurring. If necessary, it is even possible to make two registers :
- an “active” with the few risks to keep in mind (your “top x”), with a high probability, to be kept up to date ;
- and a second part of the “backlog” type register that acts more as an archive and keeps track of what had already been identified and/or processed.
4. Your risk must have an expiration date!
This is a good practice that I see rather little applied: indicate in your registry the expiration date of your risk.
This enables the risk and its mitigation plan to be integrated into the project schedule, identify dependencies, and archive registry risks. By default, a risk that will remain active until the end of the project will have its expiration date coinciding with the project end date. If it is a risk that continues beyond the project, then it is a risk to the product, not the project .
5. Make sure everyone is on the same page
This point will be discussed in more detail in our next article on Stakeholder Management. However, I think it is particularly important to discuss it here.
Have your logbook full, your risk matrix shining brightly, take the time to identify all the answers. All of this can prove to be a futile effort if the impacted parties are not aligned, or are not aware of it. Often, in trying to get your environment interested in this subject, you encounter resistance and you may be seen as a killjoy. Hang in there, it’s important!
Talk about your risks. If there is one thing that is interesting to discuss with other teams, it is this point. As much as your results, the risks of your project can be an opportunity for another initiative. Or, a response you have put in place may have an impact on other projects within the organization, or even outside it. And, the only way to find out is to communicate about it.
Hence, once again, the importance of being concise, focusing on what is well defined, anticipated… And up-to-date!
More information…
Resources about risk management in english:
- Wrike: What is Risk Management in Project Management?
- LinkedIN: Why is Project Risk Management Important?
Resources about risk management in french:
Tags: Risks