Article summary
Talking about risk is hard. Over the past couple years, I’ve adapted an approach from the book Waltzing With Bears by Tom DeMarco and Timothy Lister.
This approach focuses on two areas:
- How to name a risk
- How to identify the action being taken to manage the risk
Naming a Risk
Let’s start with a few basic definitions.
Problem: The event or situation that can go wrong on a project, usually the combination of impact and cause.
Risk: A problem which hasn’t yet occurred or materialized.
Materialize: The point at which a risk becomes a real problem requiring a team response.
So how does this help us name a risk? It allows us to tie the name to a concrete problem. For example, a risk on an e-commerce software project might be described as “Our payment gateway shuts down.” This name focuses on the cause but leaves out the impact. Here’s a name which includes a stab at the impact: “We can’t process online orders or refunds because the payment gateway shuts down.”
By including the impact in a risk’s name, we can build a more concrete understanding of its severity to share with key stakeholders. In other words, we can describe a potential future problem which has not yet materialized. This not only helps inform pre-emptive tactics (more below on that). It also helps to avoid a “sky is falling” scenario where folks ignore a risk in the worst possible way–without acknowledging that they’re ignoring it (more on this below as well).
In summary, a good way to describe a risk is by describing a future potential problem through its impact and cause.
Risk Actions
Once you’ve identified and accurately named your risks, your team and key stakeholder(s) can decide how to manage each one using the actions below. Let’s continue with the example of losing our payment gateway provider.
Avoid
To avoid a risk, you can alter your plan in a way which eliminates the chance of it materializing into a problem. More concretely, you can avoid a risk by finding a different way of doing something which doesn’t carry the same risk, or you can decide not to implement the risky feature at all.
In our payment gateway example, one way to avoid the risk would be to accept payments only through cash, check, or a separate point of sale system–not through the software. Another option would be to become a payment gateway and process our own transactions, though we may trade our single risk for other risks in that case.
Contain
Containing a risk means adding sufficient budget and schedule to a project so that you can deal with the risk if it materializes into a problem. In our payment gateway example, it could mean estimating the time it would take to find, integrate with, and switch over to another payment gateway, then adding that cost to the budget and time to the schedule.
Containing is the most conservative action, and it is a good option when you’re feeling like the chance and cost of materialization is high.
The nature of some risks makes them good candidates for containment. One example I’d usually choose to contain is the risk of not being able to address multi-team integration issues when one team finishes much later than another. In this case, I’d prefer to add budget and schedule to both teams, presuming both issues will need to be addressed when integration begins and that either or both teams will deliver later than projected.
Mitigate
Mitigating a risk entails adding a little extra budget and time to a project so that you’ll be better prepared if a risk materializes into a problem. Contrary to common misuse of the term, mitigating a risk does not excuse you from continuing to monitor and manage it.
A good mitigation investment will yield a solid plan of containment for a problem, and maybe some forward thinking to reduce the cost of containment.
With our payment gateway risk, I’d probably mitigate it by building a software abstraction layer between our e-commerce application and the payment gateway when integrating with the gateway. I’d also do some research on alternate gateways and document the ones we could technically migrate to in a draft risk containment plan.
Evade
Evading a risk means ignoring it, doing nothing to mitigate it, and simply hoping it doesn’t materialize. This might sound weird or irresponsible, but I assure you, it’s very responsible.
By admitting that a risk can be ignored, you might be more likely to include low-probability risks on the list you discuss with your stakeholders. That’s very responsible, even if you don’t think it’s worth investing time or money in doing anything about it, because you can get your key stakeholders to agree to evade it. That way, if you’re ever unlucky enough to have one of these issues materialize into a problem, it will be harder for anyone to pretend that they were unaware of the risk.
Summary
- Talk about risks with your team and stakeholders.
- Describe them in the context of being a future problem, including impact and cause.
- Agree on one of the four actions for every risk with your stakeholders: Avoid, Contain, Mitigate, or Evade.
- Sleep better at night.