Previously, we outlined five useful tips in Project Risk Management, and we then went on to discuss five essential tasks in Project Risk Management. In this article, we will complete the theme of “Things to know in Project Risk Management” by looking at what NOT to do in Project Risk Management.
Most Project Risk Managers have learned through years of laborious workshop facilitation and risk review meetings that their job is not one of glory or grandeur. It’s a bit like being an intelligence analyst in a war office. The Generals take all the glory while the foot soldiers gain ground but, without the intelligence analyst constantly checking the best way forward and looking out for potential pitfalls, the war would never be won, and no glory would be gained, by anyone. The same applies to Project Risk Managers. On a well-managed project, they will occasionally be thrust into the limelight but, by and large, they will carry on with their jobs without making a great fuss and the project will be hailed as a remarkable success on completion. Conversely, on a poorly managed project, the Project Risk Manager is likely to receive a bit more attention than he or she would really want. This is because on poorly managed projects things go wrong and fingers get pointed. There are numerous very easily identifiable reasons why things may go wrong on a project, and most of them will come down to inadequate planning and preparation. But, rather than looking inwards, many project leaders will try to lay blame on the “unknown”. In other words, they will say the project failed because of certain unanticipated events, and this is where fingers will start to shift in the direction of the Project Risk Manager. It is therefore crucial for Project Risk Managers to prepare for this in two basic ways:
- Get the full support from your Project Manager to designate risk ownership, where necessary, throughout the entire project team.
- Examine the project execution plan for gaps and weaknesses, and register all risks associated with these shortcomings.
Notwithstanding these basic preparatory requirements, there are also certain essential tasks that need to be carried out in order to keep your project risk management process controlled and effective. These were discussed in our previous article, titled: 5 Essential Project Risk Management Tasks. What we now need to consider are the things that need to be avoided in Project Risk Management. These are numerous, but the most important things NOT to do, are as follows:
Do not attempt to manage risks that are beyond your scope or control
Every project needs to have a defined scope of work, budget and schedule. This even applies to projects that fall into the “Agile” category. Albeit in this case, defined work scopes, budgets and schedules tend to be more flexible and incremental than in traditionally structured projects. In any event, every project has boundaries and this includes boundaries on risk exposure. It is often the case that risks will be added to a project risk register just because they don’t have a “home” elsewhere. This can be highly detrimental to both the project and the entities exposed to these risks. It should be made clear to all concerned that the risks being managed by a project are only those that affect the project’s objectives, either in terms of project delivery, or the performance and safety of the project’s end-product. All other risks need to be transferred out, and managed by those responsible for safe-guarding the integrity of assets which are neither within the project scope nor remit of responsibility (see: 5 Tips in Project Risk Management – Tip #2).
Do not populate your risk register with irrelevant “perceived” risks
Risk registers are constantly at risk of being over populated with irrelevant risks. Project leaders and clients alike often hold the view that if a project risk register does not contain hundreds of risks, then the project is not being properly managed. This is not necessarily the case as, while all projects are always exposed to multiple risks, many of these risks are already captured within the prerequisite project plans, procedures and deliverables. Project Risk Registers should only contain risks that are not being formally managed elsewhere in the project. In most projects, there will be a mandatory requirement for numerous technical and safety assurance studies to be carried out. These include (to name but a few) HAZID, HAZOP, SIL, EIA, FEHA, EERA and SIMOPS studies which, to many, may just be a meaningless list of technical acronyms, but rest assured that these are all highly detailed deliverables of a technical risk assessment nature. A project risk register should be the exclusive domain of all risks that are not captured in the project plans, procedures and deliverables. In doing so, it is important to resist the urge to make up the numbers in your risk register by populating it with irrelevant, or “perceived”, risks. These may include risks which are outside of your scope and control, as discussed in the previous point above, or they may include risks which are real on other projects, but not on yours (see: 5 Tips in Project Risk Management – Tip #4).
Do not over-complicate your risks
Do not spend excessive hours trying to find complexity in your risks where there just isn’t any. Sure, some risks are quite complicated, while others just seem to be, but generally risks can be broken down into three relatively simple components: Threats (or Opportunities), Events and Impacts. When assessing any risk, start by asking yourself, “What is the main event I am looking at here?” Once you’ve established that, ask yourself, “What could cause this event to occur?” and, finally, ask yourself, “What impact will this event have on my objectives?” As a very basic example, consider the event of system hardware failure during testing. Now look at what could cause the failure of that hardware (in other words, look for the threats which could result in the risk event occurring). These could be numerous, ranging from incorrectly specified components, to poor assembly and installation, to inadequate preservation of the hardware materials. Finally, what are the impacts of the hardware failure? Again, these could be numerous and, depending on the type of hardware you are dealing with, could range from minor performance issues, to complete system damage, to multiple human fatalities. The key point here is to break each risk down into its three core components, so that the risk can be properly understood and effective mitigations established to help reduce both the likelihood of risk occurrence, and the severity of the risk impacts, should the risk still occur (see: Describing Risk: Accurate Description = Better Management).
Do not try to jointly manage opportunity risks and threat risks
Opportunity risks and threat risks need to be managed separately. Without this in place, Project Risk Managers run the risk of disrupting well thought out and established project execution plans. On every project, clients, contractors and members of your own team will come up with proposals on how to complete the project faster, cheaper and with improved performance. While these proposals should not be ignored, they do need to be assessed and managed as a separate process to the threat risks which occur on projects on a day-to-day basis. In an ideal world, this would be done by a team of project integrity specialists, working in parallel with the project delivery team, continuously reviewing all elements of the design basis, execution plan, schedule and budget to ensure the project is being executed in the best possible manner to produce the best possible result. Unfortunately, not many project teams have the luxury of engaging a dedicated team of integrity specialists, and the best most of us can hope for is a periodic peer review of our project progress. Even so, all opportunities still need to be treated as potential deviations from the plan and, as such, they need to be assessed and controlled in the same way any other change to project scope, budget or schedule is managed; through a formal Management of Change process. The key difference between managing threat risks and opportunity risks is that management of threat risks is the process required to keep a project on plan, whereas the management of opportunity risks is the process required to knowingly deviate a project from plan (see: Threat Risks vs. Opportunity Risks: Are they really the same thing?).
Do not confuse impact mitigations with probability mitigations
Risk managers and owners often fall into the trap of thinking of risk mitigations as being mitigations which can be applied to the risk as a whole, and don’t consider which element of the risk each mitigation affects. In most cases, being able to effectively mitigate the probability of risk occurrence should be a risk owner’s highest priority, while mitigating the impacts is what you have to do if the risk event still occurs. However, it is also possible to mitigate the probability of impact occurrence after a risk has already occurred. This is where things can get a bit confusing, and here it helps to keep a clear picture of the three basic risk components in your head. There are two ways to mitigate the impact of a risk, one is to control the likelihood of the impact occurring, and the other is to control the effect of the impact should it still occur. Both should be considered as impact mitigations, as they both deal with the potential impact of a risk that has already occurred. Probability mitigations deal with the likelihood of risk occurrence and aim to prevent a threat from triggering an unwanted event (or, in the case of opportunity risk, aim to take advantage of an opportunity to trigger a desired event).
For more information about our project risk management services and software, or if you just want to express your own views on the subject, please feel free to get in touch via our “Contact Us” page.