~ By Kareem Shaker
Risk management is the heart and soul of project management. Failing to practice it right can have fatal consequences on projects and programmes. Doing real effort in the planning stage can save the entire investment and will increase the likelihood of project success. However, planning alone is not enough if monitoring risks is not handled seriously. These are seven deadly sins of risk management and how to take preventive actions to avoid them.
Enterprise Risk Management (aka ERM) specifies the processes, frameworks, and methodologies an organisation uses to identify and manage enterprise risks of all types, such as operational, strategic, financial, compliance, etc. The project manager has to consider the enterprise-wide risks and study what threats the organisation is likely to encounter during the projects' lifetime. Consulting the Chief Risk Officer (CRO) before and while building the risk management plan can have a mammoth impact on the way the project management plan will be developed. The project risk management has to be congruent with ERM, since the ERM governance can impose certain documents to be delivered, probability/impact scales, risk appetite, and risk management software to be used. Project Management Institute refers to those as Enterprise Environmental Factors (EEF).
Risk Breakdown Structure (RBS) is the catalyst to identify large numbers of risks. Risk management teams use it to identify risks and stimulate the minds of the stakeholders who will be participating in the risk identification stage. RBS can be developed by listing all the root causes of potential risks. RBS highly depends on the project domain. Every industry has its own associated risks. Risks that are valid to a software project may not be applicable to a construction project. The project manager can start with a template from a known body and customise it based on previous project history and project-specific risk categories.
Subjectivity can make risk management lose its essence. You will find that risk averse stakeholders will identify large numbers of risks; in contrast, risk takers may be oblivious to real risks. It is important to mediate these conflicts during risk identification.
The risk identification process is substantial for successful risk management. I believe that identifying risks will always get 60% of the job done, and the rest is sort of "Just Do It!" There are different information gathering techniques to solicit stakeholders' input. The perpetual problem of risk management information is subjectivity. Different people will perceive risks in different ways. For instance, a financial risk may not grab a technical manager's attention, and a technical risk is very unlikely to be deemed as a risk by a financial manager. It is the responsibility of the risk management team to remove subjectivity and ensure quality of risk information. Subjectivity can be avoided by using the Delphi Technique, as it keeps the views of different subject matter experts anonymous, even after finishing the identification phase.
Successful risk management can never be a one-man army. The risk management team has to set clear expectations and inform subject matter experts, stakeholders, customers, team members of what is expected from them. The ownership of risks has to be communicated to the risk owners. The project manager has to follow up on the status of assigned risks, and the risk owner has to report risk status updates on a frequent basis. The project manager should not be the only individual who owns risks. Potential risk owners may be reluctant during risk identification stage, fearing that they may be responsible for the risks they will be identifying. Creating a risk management RACI Matrix (Responsible, Accountable, Consulted, Informed) will ensure roles and responsibilities are clearly identified and communicated.
Not all risks have to be managed; some risks just need to be accepted. Response strategies of negative risks (yes, there are positive risks, those are known as opportunities) are Avoid, Transfer, Mitigate, and Accept, but oftentimes the acceptance strategy is never considered. Risks have to be accepted for two main reasons; first is unfeasibility of the first three response strategies, and second is due to unfavourable benefit cost analysis. For instance, if the loss value is much smaller than the benefit gained, due to implementing a control, it would be rational to accept the risk; otherwise you would be paying $100 to save a $60 risk.
Contingency reserve can only be determined after the project manager has had multiple revisions of the project management plan. Contingency reserve should only be used when a planned risk (aka known unknown) materialises. The contingency reserve should not be used for any unplanned risk (unknown unknown). The unplanned risk can only be handled by the management reserve. It is also not right to use the contingency quota of one risk at the expense of another risk, unless the latter has already become void.
Risk management is an iterative process and should be practiced in all project stages, from inception to closure. It is not right to do it during the planning stage only, nor is it right to stop looking for new risks during the execution phase. Many project managers conduct risk identification at the beginning of the project, and shelve risks until they turn into issues. The project manager should elevate the culture of risk management and ask team members to report new risks. The new risks have to go through the process of analysis and response strategy planning. The project manager has to visit the reserve balance and make sure that no risk will have no contingency. It is also important to put risk management on the agenda of frequent progress and status update meetings.
These are the seven deadly sins of project risk management as I could identify them. It would be great if you can share your experience and articulate what could be a sin in risk management from your perspective and how to avoid it.
Kareem Shaker, PMP is a project manager at Dubai World, he has over 10 years of experience in IT projects, consulting, and pre-sales.