“In theory, there is no difference between theory and practice. In practice, there is.” This bon mot attributed to Yogi Berra sums up the state of risk management in projects. Risk management is supposed to be a defined process backed up with quantitative tools. In reality, it rarely is.
This difference between “what project managers should do ” and “what project managers do” is explored in this paper. The authors pose this question:
The essential question that we set out to answer was: Why do the traditional quantitative techniques of project risk management continue to be reproduced in the prescriptive literature if they are so rarely used in practice?
https://journals.sagepub.com/doi/full/10.1177/87569728221124496
In brief, the authors point out that risk is more complex than commonly understood, and that managing it is intrinsically related with the self-conceptualization of the project teams, and the different audiences that project managers have to interact with.
At PL Programs, we live in the real world, so we add to this perspective and present another answer.
What Risk Management Is Supposed To Be
The common approach to risk management looks something like this: Brainstorm, list, prioritize, develop and manage response.
There is of course more nuance in the process.
Some risks can have probability distributions assigned to them. The risks can be assigned to specific tasks. The impacts can be quantified, enabling prioritization and management of the most potentially damaging events. Then the resultant probabilistic impacts of mitigated risks can be assessed against the schedule, hopefully arriving at an acceptable answer.
At least, that’s what The Book (the PMBOK and other risk-management-specific books) says to do.
The overall concept of risk in this model is presented as a fact or as something that can be objectively evaluated.
But this often does not happen. Or, when it happens, it happens in very limited domains on a project.
Why is this?
A Holistic View of Risk
The authors point out that risk is a much larger, complex issue. Things that negatively affect projects can include major contextual issues on a project. The stakeholder environment, for example, may be a huge risk. Project team motivations and self-identities may present risk in the level of effort that the project team expends.
Other risks are specific to the workstreams. Here is a “complete” list of construction-related schedule risks . Software programming projects have entire bodies of scholarship and writing dedicated to mitigating software development risk. Automation and organizational risks are similarly richly endowed with a variety of things that can go wrong.
Different levels of risks are often neglected in risk assessments, which tend to focus on outcomes of specific tasks and not the confluence of uncertainties that create them.
Incomplete Concepts of Risk
Many types of risk can be quantified or at least estimated. The best practices in risk management include identifying the risks and quantifying their impacts impact. Qualitative risks are also identified.
However, many kinds of risk cannot be quantified. Or if they are, the quantifying effort is not credible.
This is a function of the local knowledge prohttps://fee.org/articles/the-use-of-knowledge-in-societyblem. There are too many dependencies and factors that may affect a project. It is impossible to identify them all, and much less to have any realistic idea of their impacts and likelihoods. It follows that is impossible to identify all the second-order risk effects and manage those.
(Sidebar: Some practitioners have identified a methodology – “Event Chain methodology” to classify and react to tasks that have been affected by a risk. This involves a somewhat complex method of assigning different states and associated risk probabilities and impacts to those task states. It is more accurate than conventional methods, but it has a key problem in common with other quantitative methods: it is hard to do).
Identifying and managing risk becomes even more difficult when the identities or livelihoods of the project team depend on their conceptualization of risk as something that can be completely managed.
Why Quantitative Methods Are Not Used
Quantitative methods are not widely used because they’re hard to do and they apply in narrow cases.
They’re hard: Quantitative methods require specialists to understand applications of statistical theory. They also require subject-matter experts to conceptualize where uncertainty and risk exist in the project.
This material is presented in PMBOK standards but its application and ideal use cases are not explained thoroughly. And often the statistics must be paired with understanding of combinatorics, because for every range of risk occurrence probability, there is a range of impact magnitudes to consider.
Further, the tools available are clunky and require lots and lots of effort to maintain. So they are most useful on large or mega projects, where resources dedicated to risk management can be assigned and coordinated.
They apply in narrow cases: There are some cases where quantifying a risk’s impact requires so many assumptions as to be meaningless.
For example, try to quantify the risk of a poorly integrated project team. This is a massive risk which may impact all of project cost, delivery, and quality. But trying to generate a point value or range of impact values to specific events from the systemic risk is difficult. Here, a qualitative risk assessment and mitigation plan is more effective.
In contrast, a schedule’s robustness may be greatly improved with quantitative analysis and simulation. Financial analysis of a project plan may be helped by analyzing the impact of individual risks on a project’s cost profile, though here we start to get into cases where cost impacts of risk events may not be well-understood.
It is much easier to assign subjective values to a probability/impact matrix and use those as a guide to what to pay attention to. This is a good first pass that might catch most of the apparent risks, but is not comprehensive.
What To Do About It
So what are we to do with all of this? Let’s try to make sense of it.
The first step is to know what you are doing.
Project planning should include an assessment of the type of project and risk management program required. If the project is large, and the risks appear varied and complex, you want to tailor the amount of effort put into risk mitigation resources and tools.
A large project (Ed Merrow says that projects over $1B seem to be the tipping point for complex resource allocation) with expensive outcomes needs the right supporting amount of effort int its risk mitigation. That may mean tools and experts beyond a regular spreadsheet-based risk register.
After diagnosing the project type and profile, then allocate resources and time to it. Where schedule or quality issues may have impacts in the tens, hundreds of millions, or even billions of dollars, it is worth investing in high-grade risk management, including quantitative methods where they apply.
The extra resourcing is a cost and communications burden. But like insurance, it is worth the cost when the possible outcomes are orders of magnitude bigger.
****
For insights on your project and correct levels of risk management, get in touch with PL Programs’s certified and knowledgeable program professionals.