Risk management is embedded in most all projects that we encounter. In our sector, project managers routinely identify risks, assess and document them so that they can be kept visible during a project's life. So what's the problem? Well, in many organisations it is not operated at a highly professional level. But this does not mean we need to be employing statistical rocket-science, such as risk pooling or Monte Carlo simulations (even though these have their place); there are far more basic things that will make a difference across our business. Here are four that we commonly find:
Definitions are not clear
To do something about mitigating risk usually requires the commitment of extra resources. Therefore, risk analysis is designed to communicate to decision-makers outside of the project team. Yet risks are often defined poorly. The project team members discuss and analyse various project risks in detail, so a statement such as 'delay in beginning Phase 2' is fairly clear to them all. But when communicated outside of the team, it may easily be misunderstood, underestimated, and ignored in the middle of a busy portfolio.
There is a templated way that this can be done, resulting in written definitions of risks that can be understood by anyone, across the company.
Impact confusion
Risks typically arise from various specialist (functional) activities. So when the project team is considering the Likelihood that they will occur, it's useful to press on the relevant functional expert, who is arguably the best estimator. But if and when risks kick over into issues, the Impact will affect many connected parts of the project, so the full Team has to consider and evaluate its potential to do so. This is where we often run into problems. Firstly, how far do you go in defining the knock-on impacts? For example: 'Delay in completing development of drug formulation, results in delay of start of Phase 3, results in delay in Submission, results in putting back the launch date, results in lost sales, results in lowering company profits', etc. Secondly, of course we want to prioritise and escalate the most serious risks, but we sometimes don't have a set of agreed conventions for impact classification. Can senior management easily compare a risk that 'very serious' or 'very high' in one project, with that from another?
We can apply some common thinking to all of this, so that we all understand the classifications and agree to them.
Project Managers doing everything
It is not uncommon for the PM to be taking sole responsibility for identifying risks, preparing draft analyses, presenting them to the team, documenting them, and so on. Busy functional team members, often busy serving several other projects, may be helpful if asked, but will take the easy option and not get any more involved. This is not advisable and in some cases may be dangerous. Teams may just be 'rubber stamping' output that is not properly analysed. When contingency plans are needed, they may be less than effective and/or unrealistic.
The project team functional members should be intimately involved with risk management. There are ways in which the PM can influence the development of the team's work and establish a more professional regime.
A different system for each project
The way risks are managed can develop as a 'cottage industry' within a project. This is found where there is either no cross-portfolio system and templates, OR where there is a system of sorts, but it is not understood, not enforced or simply doesn't work very well. For the right system, there is a dilemma: invest in a commercial product - highly developed, but it may be expensive and not fit your projects' needs exactly. Or develop your own. This may be OK, but these (usually Excel based) have a way of seeming quite simple at the start, then becoming over-complicated, with seeming endless tinkering to get them right.
But any system will not be effectively used by projects, without serious attention to change management. People tend to do what they know and have been comfortable with. You can map out a managed approach to introduction of a new system, and ensure everyone is bought in, with some care and attention.
John Faulkes 2022
Comments