I just watched Dave Prior’s interview of Ken Rubin at the Agile 2014 conference. It’s a good interview, and Ken makes some excellent points. But at one point, he makes the observation, “In more traditional risk management, the assumption is early on that you’re going to generate this risk assessment. You’re doing this now on the first day, when you have the worst possible knowledge you’re ever going to have about the project.” Dave then interjects, “And then nobody updates it.” While I agree that this is not uncommon, it is poor practice.
Risk management should not be something you do once, at the beginning of a project. It should be part of the regular operating rhythm of any project. Whether you take a very structured approach to assessment, with quantitative analysis and a separately managed risk budget, or a qualitative approach with risk management costs baked into the project budget, risk management is only beneficial if it is part of execution, as well as planning. Our risk assessment, like our requirements gathering, should be an ongoing process that improves the resilience (anti-fragility, if you prefer) of the endeavor over the course of the project.
Risk: “An unknown that matters”
I would argue that a large part of any risk management project, like the requirements gathering process, is reducing or eliminating the unknowns. This can’t be accomplished just by making plans – you have to take action and increase your understanding. Let’s consider the most common risk responses:
- Transfer: If you transfer the responsibility to deliver some portion of the project, especially to an external organization, you still have to ensure that they’ll be delivered on time and to the required quality in order to make your risk response successful. This requires continuous monitoring and corrections, as well as coordination with the other performers on your team. If things start to go sideways, you’ll have to deal with the residual unknowns and the possible impacts.
- Mitigate: Any mitigation action should have a trigger, which requires monitoring. Once triggered, you need to determine if the mitigation is having the desired effect. If your mitigation is intended to reduce the impact of the risk event, you need to update your estimate of the impact in order to know whether to make incremental changes. If the intent was to reduce the probability of the risk event, you need to be able to monitor the residual probability.
- Avoid: If you avoid a risk by removing something from scope or changing the design, you’ll need to communicate that decision to the stakeholders. This shouldn’t be something done only at the time of the decision; it needs to be part of your communication plan.
- Accept: If you decide to accept a risk, you still need to monitor for it. It is not uncommon for a project to decide that a risk, previously determined to be acceptable, grows to require some mitigation or even avoidance.
The Team Should Know the Risks
The risks to the project may impact the project team, so they need to understand them. They also need to understand the planned responses for each significant risk, at least as it impacts their work. The team is part of the “sensor network” that will detect the transition from risk to issue, requiring action. They need to understand their role, and how to escalate an observed risk response trigger.
Ultimately, risk management is an integral part of the execution of the project. Whatever methods you use to manage and respond to project risks, be sure to keep discussion of the risks under management on the agenda for your team’s regular meetings. Few risks are entirely static; we have to manage them dynamically!