Risk Response Strategies: Transfer and Avoid

As I’ve noted in other posts, a risk is an uncertainty that matters. Some event has a significant probability of occurring, and there will be a significant consequence if it does. A risk represents a threat, and a wise project team endeavors to identify project threats and analyze them so that the probability of occurrence can be reduced or the cost of the consequences reduced. Or both.

Consider the following proverb:

“The early bird gets the worm, but the second mouse gets the cheese.” — David Jakovac

Mr. Jakovac is correct only if the cheese is in a trap; otherwise, the Second Mouse goes hungry while the First Mouse eats his dinner. Thus, the Wise Mouse looks at the context, seeking potential threats and assessing her exposure to them. If the cheese is indeed in a trap, waiting to be triggered, then she has four potential risk management strategies to consider:

  • Mitigate – try to either trigger the trap from a safe distance or find a way to survive the snap
  • Accept – in effect, volunteer to be the First Mouse
  • Transfer – recruit a First Mouse (or possibly a whole tribe of mice)
  • Avoid – look for another food source

After considering the technical limits of the alternatives available for mitigation (little chance of reducing the probability of occurrence) and the fatal consequences of triggering the snap (little ability to reduce the cost of the event), the Wise Mouse will abandon the first two strategies as unworkable. At this point, Ms. Mouse needs to consider the economics of the Transfer and Avoid strategies.

Transfer

Crappy BumperGenerally, a risk is transferred using one of two mechanisms: pooling and delegating. In pooling, a number of parties at risk contribute funds to finance recovery from an event experienced by a member of the pool. If that sounds like an insurance policy, it is. Surety bonds are also a form of risk transfer, commonly used to absorb the impact of non-performance. Currency exchange rates can be a risk, and appropriate financial derivatives are used to partially absorb a loss. In most cases, pooling is about reducing the financial impact of an event, at some initial fixed cost.

The Wise Mouse is considering a delegation strategy. Delegation can take many forms—from sub-contracting to an experienced performing agency to engaging a contingent worker. Crowd-sourcing is a delegation strategy, as is the use of open-source software. Delegation to someone with more expertise is intended to reduce the likelihood of the event, again at some cost. Other times, as in the case of the recruited First Mouse, delegation is about transferring the consequences. Note that some residual risk will usually be present; in other words, some of the consequences will be borne by the Wise Mouse, possibly at the hands of the First Mouse’s mourners.

Avoid

We avoid a risk by accepting the opportunity cost of not doing something. In projects, this can range from taking something out of scope to making adjustments to the project delivery schedule. Depending on the goals of the project and the nature of the risk, we may determine that the remaining value of all-but-this-one-thing still exceeds the adjusted cost, and we may proceed without it.

Of course, if the value no longer exceeds the cost, it may be better to abandon the project. The Wise Mouse is considering exactly that approach.

Certainty is for People With No Imagination

Eats, Won’t Leave, So Shoot!

Leadership requires a willingness to make decisions under conditions of uncertainty. To be certain, you must believe that you have perfect knowledge of the circumstances and absolute control over the outcome. It also requires you to have absolutely no imagination; “Nothing will go wrong.”  These people often go on to win Darwin Awards. The rest of us acknowledge the limits of our understanding and control. We have horrible dreams, and yell at the heroine in the horror film to turn on the damned lights when you enter the room! We often live long enough to reproduce, or at least have roles in the sequel.

Risk management is about improving the quality of decisions made under conditions of uncertainty. It is unrealistic to demand certainty before taking action and foolish to assume that all will go well, simply because you need it to. Identifying and analyzing risks may help reduce uncertainty to acceptable levels, or it may lead to cancellation of a doomed project. In either case, the analysis of the risk and alternative strategies allows a rational basis for decision making.

Risk Management is Part of the Operating Rhythm

Risky Baby Business

Risky Baby Business

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!

Conditions and Risks

Snow PlowIn January of 1979, the city of Washington, D.C. suffered an unusually large snowfall. Due to a lack of functioning snow plows, traffic quickly ground to a halt. Reporters descended on the new mayor, Marion Barry, asking him for his plan for snow removal. Barry scowled, and then growled, “Spring.”

Operating Conditions and Risks

Every municipality where snowfall is common needs to have a plan to remove the snow, when it eventually falls. They are certain that snow will fall; therefore, it isn’t treated as a risk, but as an operating condition. It’s fairly easy to review records of past snowfall, business and neighborhood expansions and new roads, and changes in traffic patterns to maintain a standing plan and budget for the municipal government.

Let’s say that your project has a three day event scheduled in February, in a locale that can get significant snowfall at that time of year. If you plan to have people travel to that event, the potential for snowfall is a risk. If the snow falls a few days before or a few days after the event, it will have no impact. But snowfall just before or during the event may prevent people from reaching or leaving the location of the event. You will need to develop a risk response plan, particular to your exposure. And your first step should be to estimate your exposure.

Exposure and Response

The municipal government’s plan is to remove the snow from the roads, in some priority order. The date is largely inconsequential. But for your event, you need to consider each date separately. If heavy snow is forecast the day before the event is to start, do you cancel or reschedule? At what projected snowfall? How about on the first day—people might be able to come, but not return to their homes or hotels. What is the latest you can communicate a cancellation decision to the attendees? What is the reliability of the forecasts in that area? What about on the second day—reschedule or cancel? And on the third day, will you shut down early? There are a lot of scenarios and potential responses to consider.

But there are other risk strategies to consider. You might conduct the event at a locale with a lower probability of significant snowfall. Or schedule during a month where the probability of snowfall is lower. In choosing among the available strategies, you are considering conditions in order to assess risks. In similar fashion, you might consider the available and planned capacity at available data centers before choosing one to host your server. Or consider the impact of normal operations based on the business calendar, when staffing your project with people who won’t be fully dedicated.

While you need to take both certain conditions and probable risks into account in developing your plan, it is important to maintain perspective. Don’t develop a risk response for a condition, like an inadequate network capacity. Make your action to address that condition a part of your work breakdown structure, if it’s in scope. And if it isn’t in scope, escalate it.

This article was first published on the Leadership Thoughts blog.