Risk Response Strategies

The subject of risk response strategies came up on a project this week, so I‘ll review the four strategies listed in the 4th Edition of the PMBOK, chapter 11.  The first three strategies are useful in dealing with threats, or “uncertainties that matter” with a significantly negative impact.  The fourth strategy can be applied to either threats or opportunities.  They are:

  • Avoid.  At one level, this is the most obvious strategy.  If a particular event seems too likely, or has too great a downside, you simply remove it from the equation.  This might mean moving something out of scope, using a more proven technical approach, moving the go-live date out, or otherwise eliminating the element that is the source of the uncertainty.  It might even mean cancelling the project.  The costs associated with avoiding risks may be opportunity costs, or they might involve compliance or contractual penalties.
  • Transfer. When IT project managers think of transferring risk, they typically think of contracting a portion of the work to another performing entity.  Construction project managers typically think of taking out insurance.  In any case, the uncertainty is still there, but the impact of that uncertainty, if not all of the consequences, is shifted.  Consequently, the cost of transferring risk usually involves payment of some sort of a risk premium.
  • Mitigate.  Attempts to reduce either the probability of the occurrence of a threatening event or limit the potential down side are lumped together as mitigation.  However, the approaches to each are frequently quite different; more on that in a moment.  The costs associated with risk mitigation can vary, depending on the nature of the risk and the mitigation under consideration.
  • Accept.  When you don’t avoid, transfer, or mitigate a threat, you accept it.  In effect, this is the default strategy.  Refusing to acknowledge a threat leads you to accept it.  Refusing to absorb the costs associated with responding to threats in some other way leads you to bear the full consequences of the event, should it occur.

Let’s consider an example of mitigation.  Back in the 1980’s, when we were building the first servers based on PC technology, one of the technical threats was the failure of a disk drive.  At the time, the technology was still quite new.  Reliability, expressed as mean time between failures (MTBF) was low; consequently, the probability of the failure of any drive during operation was high.  In addition, the failure of a drive meant that the data on it would be lost.  Tape backups were available, but in the event of a failure, changes subsequent to the most recent backup would be lost.  System availability was also impacted, in that the server would be unavailable until the drive could be replaced and the last backup restored.  Thus, failure of a disk drive presented both a high probability of occurrence and a high impact.

The technical mitigations available for addressing this threat included two alternatives: higher-reliability drives, and redundant arrays of inexpensive disks (RAID).  Using higher-reliability drives reduced the probability of a failure.  They also added to the initial cost, but if the drives failed less often, total life cycle cost of a sufficiently large population of servers would be comparable.  Using RAID nearly eliminated the impact of a failure on operations, in that no single drive failure would take down the server or cause data loss.  However, redundancy required additional hardware, driving up both the initial cost and the cost of maintenance, since the larger number of drives in the server population would experience more failures.

Over the last thirty years, hard drives have dramatically improved MTBF, while cost per unit of storage has fallen to “almost free.”  But despite the reduced risk of a drive failure, nearly all modern servers use redundant drives.  This is because the increased storage capacity allows far more data to be put on them, thus increasing the potential impact of a drive failure.  Thus, the default mitigation is now to reduce the impact of the threat, despite a significant reduction in the probability of the event.

Not all threats can be avoided or transferred.  But when devising a strategy to mitigate the risk, be cognizant of whether your approach will reduce the probability of the event or its impact.  And remember that the cost of accepting a risk is equal to the probability of the event, times the financial impact of the event.  This value should be the basis for development of your risk budget.

This entry was posted in Theory and Practice and tagged , , , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.