Goldilocks and the Three Risk Management Programs

Fit your process to your project needs

Photo by Mikael Kristenson on Unsplash

Risk management is one of the most valuable tools in your arsenal as a project manager. It should be part of all planning and inform every decision.

But your process shouldn’t be one size fits all.

While it’s not good for projects to have under-developed risk management processes, it’s also not good for an organization to adopt a rigid risk management process that is applied unilaterally to all projects. This is for three reasons: first, if it’s too lightweight it may not be good enough for very large or complex projects, and risks could be missed or poorly understood. Second, if it’s overly onerous it may take attention away from other parts of the project, which is itself a risk. Third, if it’s a bad fit in either direction it will be seen as useless busywork, it will actively harm the organization’s risk culture, and the best project managers will spend their time trying to find ways around it.

With a strong risk management process, every part of the process should be adding value. There are many options for performing good risk management on all sizes and types of projects, whether in identification, quantification, mitigation, or monitoring. A good process needs to take those ranges into account and allow for tailoring and flexibility.

So just how many options are there?

Here’s some of the range I’ve seen.

Identification

• We don’t really do risk
• The PM has a mental list of key risks
• The PM has written down their key risks
• The project team has collaboratively created a risk register which captures risks and other information and updates it on a regular basis
• Risk definition involves everyone on the team, all consultants, other internal stakeholders, and the entire C-suite. The register has 800 risks on it.

Quantification

• Seems like a waste of time
• The PM has a mental list of what’s important
• Quantification is a “gut feel” assessment of priority set by the PM — red, yellow, or green.
• As a group, the team is quantifying for cost based on an assessment of likelihood and potential impact
• Every risk has to be quantified on six impact types with the team and some additional internal SMEs and the team is using Monte Carlo simulation for the cost
• The quantification was derived with input from the full team, senior management, internal SMEs, and multiple external experts. The Monte Carlo quantification models have Bayesian sub-models which are being fed by live links to a data mining operation. The whole thing lives on a dedicated server.

Mitigation

• Look, things just happen on projects
• Mitigation actions live solely in the PM’s mind
• Each risk has some mitigation actions listed
• All risks have mitigations, and the team knows who’s responsible for each mitigation and when it needs to happen
• Potential mitigation scenarios have been analyzed and documented with reference to the organization’s data banks of past mitigations. Final mitigation actions need sign-off at two levels of authority.

Monitoring

• Someone will raise it if it gets bad enough
• The PM asks about some items at meetings, whatever’s currently on fire
• Progress on mitigations gets discussed when the risks are requantified, once every six months or so
• Key mitigations are being executed by team members who update regularly on status
• Every single mitigation gets discussed on a biweekly basis. Status and progress are documented and circulated to the company. Some mitigations are discussed weekly.

The point here is that, with the exception of the total avoidance of risk management, every option I’ve listed might actually be a reasonable approach depending on the type of project! On small and straightforward projects, like organizing a retreat or installing a park bench, the PM really might just consider various aspects of risk rather than have any kind of formal process. That works pretty well as long as it’s a very small team and the PM is experienced. Conversely, on multi-billion-dollar megaprojects, it’s completely reasonable to have multiple personnel whose entire job is risk management. The problem arises when you’re making the park bench PM create a fully quantified register with specific mitigations, or when the $200M capital project is being run by someone who doesn’t write risks down.

What Level of Risk Process is Just Right?

The decision being made here is really about two things: the organization’s risk tolerance and the overall risk profile of the project. Tolerance is effectively a reflection of an organization’s willingness to take on risk and ability to absorb impacts. Risk profile is a characterization of the project’s overall potential to result in serious impacts. They both need to be considered when designing a risk management process for a project.

If the risk tolerance is low and the profile is high, rigorous risk management is best so there is a fully documented trail for each risk, backed up by strong analysis. On the other hand, an organization with relatively high risk tolerance might be more accepting of less formal risk processes, especially on projects with lower risk profiles, as long as the team has their risks under control — some analysis, more discussion, less reporting. The right choice is a balance between workload, communication needs, risk profile, and organizational preference.

Some Things to Keep in Mind

• It’s not just about project size. Impacts may not be solely financial, and tolerance is usually different for different types of impact. A project which is very sensitive reputationally might be seen as more of a threat to an organization than a project which has a high potential of being late, for example.
• Consider complexity as well. Projects that have lots of touchpoints with other projects, or that have many different disciplines, multiple stakeholders, or brand-new technology may all benefit from enhanced risk management.
• Extremely large projects are a different animal. Megaprojects are notoriously prone to serious overruns, delays, and other risk events. Size has a complexity all its own. Risk processes for these projects need to go beyond the “typical” register to be useful, because the amount of information can become overwhelming. Custom designing a process for a megaproject is recommended.

Now Ask Yourself These Questions

If you have an idea of the general level of rigor that’s likely to be required, now it’s time to think about some more details. Consider the context of the project itself, including team culture, organizational culture, and project qualities. Depending on need, your risk management updates may happen more or less frequently, detailed cost or schedule analysis may be more or less important, and you may focus more on internal communication or on external reporting. The context can change over time as projects move into different phases, and it can also change if project characteristics change. Here are some questions to ask:

1. Are senior management very concerned about this project and need regular updates?
2. Is this project moving very quickly? Are the risks changing on a short time scale?
3. Is the team size very large? Is everyone going to be able to easily stay aware of key risks?
4. Is the plan to transfer some or all of this risk?
5. Is there a need to set a firm budget or end date ahead of time? Do I need a prediction of how much these risks could cost, or the effects on my schedule?
6. Is my team experienced with this kind of project and with risk management in general?

The answers to these will help guide the definition of a process that will provide what’s needed, with the right frequency of updates and reporting, the right information coming from your analysis, and the right level of communication among the team.

Find Your Fit

If you’re struggling with your risk management, or you feel that risk management doesn’t have much value, it’s very possible that there’s just a bad fit between your project and the process. Depending on your organization, this may not be easy to fix. But even if there is a defined organizational risk process it is still possible to adjust how you use it so that it aligns better with your risk profile, the organization’s risk tolerance, and your project’s needs.

Finally, don’t let your risk management process become set in stone. Like Goldilocks, you might have to try a few different options before settling on just the right one. Whether your project is well under way or you’re just getting started, it’s never too late to think about risk — or to think about how you think about risk.