Project Risk Management Done Right
What is effective risk management? How much needs to be done so that one can say all risks on my project have been properly managed and I’m 100% sure all is under control? Does it sound absurd to you? ;) If yes, you probably have already done a bunch of project management and can sense the high risk of overconfidence and ignorance such bold statements can convey. Let’s try to figure it out and understand what effective risk management is and when you can say it has been done enough at a specific life cycle of the ongoing project.
At the Project Initiation stage, it is important to have a Project Charter created. How is it connected with risk management one would ask? The relation here is pretty simple because one of the paragraphs to be obligatorily mentioned in the charter is the list of initial high-level risks that are properly highlighted and accepted by all stakeholders before the implementation process has begun. The majority of identified risks at this stage are high-level and the initial list should be revised by the development team as soon as the development process starts.
During the Implementation stage, one of the best practices would be to have a separate meeting with all dedicated team members to brainstorm together and fill in the Project Risk Register that should be a living document updated and edited based on the identified needs. Make sure that the register contains ranged risks with probability and impact as well as the mitigation plan, owner, status, and applicable comments. There are a bunch of templates available on the Internet at the moment shared by respectable sources in the world of project management. Choose one up to your liking and use it in your everyday work. Personally, I prefer to modify the templates based on the project and the team’s needs. Sometimes the goals of the risk register might differ, which respectfully influences its structure. Note, that if you are using any kind of abbreviations, there should be side notes with detailed explanations. The risk register should be constantly up-to-date, available to the team and all stakeholders involved.
At some point during the implementation phase, there might be a need to create a copy of the Risk Register for internal usage only, specifically if talking about third-party vendors, who also have to manage HR risks, promotions, and rotations, internal programs that may influence the effectiveness of the project team, budget changes, etc. This requires some additional time to set up but is greatly beneficial when this kind of risk register exists on the project. It contains those points that shouldn’t be shared with all stakeholders right away, but they have to be logged beforehand to keep track of and resolve when proper timing.
When working with the risks one should keep in mind and make use of the negative and positive risk management strategies which are: accept, avoid, mitigate and transfer for negative ones, and exploit, share, enhance, and accept for positive. Making it clear which strategy should be used for this or that identified risk will give the team more confidence and agility if and when the risk actually happens and what kind of action should be taken afterward.
Typically, when the project comes to its closure, the risk register should be updated and include the latest statuses of the identified risks, the majority of which should be resolved and closed. There are cases when some of the risks are just accepted. In this case, the information with details should be preserved and shared with the development team and other stakeholders to make sure everyone is notified and aware of this. In case the development process is initiated or the next release or phase is approved and ready for implementation the risk register should be reviewed and reprioritized. The risk register is one of the items that should definitely be included in the ‘lessons learned’ folder.
One never can guarantee that all project-related risks have been identified and taken care of. This is simply impossible. However, being attentive to initial risks and resolving them fast can decrease the number of issues any team can face during the project implementation. Manage your risks wisely ;)
What kind of risk management practices have you been using recently? Did they turn out to be effective?
