« Soporific Speaker Stereotypes
Introduction to Emotional Intelligence - Part II »

Risk Management Approaches

June 24, 2008 | Author: admin | Filed under: Risk Management, Risk Identification, Risk Quantification & Analysis, Risk Response & Control

Risk Management Approaches (#4 in the series Know Your Enemy: Software Risk Management)
By Karl E. Wiegers

Risk management is the application of appropriate tools and procedures to contain risk within acceptable limits. It consists of several sub-activities.

  • Risk assessment is the process of examining a project and identifying areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, or by examining the contents of an organizational database of previously identified risks and mitigation strategies (both successful and unsuccessful).. Risk analysis involves examining how project outcomes might change with modification of risk input variables.

    Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss on a relative scale of 1 (no problemo) to 10 (deep tapioca). Multiplying these factors together provide an estimation of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It may be easier to simply estimate both probability and impact as High, Medium, or Low. Those items having at least one dimension rated as High are the ones to worry about first.

  • Risk avoidance is one way to deal with a risk: don’t do the risky thing! You may avoid risks by not undertaking certain projects, or by relying on proven rather than cutting edge technologies when possible.

  • Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution is execution of the plans for dealing with each risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Simply identifying the risks facing your project is not enough. We need to write them down in a way that lets us communicate the nature and status of risk factors throughout the affected stakeholder community over the duration of the project. Figure 1 shows a form I have found to be convenient for documenting risks; this information can also be stored in a spreadsheet. This risk list could be included as a section in your software project plan, or it could remain as a standalone document.

Figure 1. Risk Documentation Form.

ID: (sequence number is fine)
Description: (List each major risk facing the project. Describe each risk in the form “condition – consequence”.)
Probability: (What’s the likelihood of this risk becoming a problem?) Loss: (What’s the damage if the risk does become a problem?) Exposure: (Multiply Probability times Loss to estimate the risk exposure.)
First Indicator: (Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.)
Mitigation Approaches: (State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.)
Owner: (Assign each risk mitigation action to an individual for resolution.) Date Due: (State a date by which the mitigation approach is to be implemented.)

When documenting risk statements, use a condition-consequence format. That is, state the risk situation (condition) that you are concerned about, followed by at least one potential adverse outcome (consequence) if that risk should turn into a problem. Often, people suggesting risks may state only the condition (“the customers don’t agree on the product requirements”) or the consequence (“we can only satisfy one of our major customers”). Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.”

The P, L, and E cells in the form provide locations to capture the probability of a risk materializing into a problem (P), the loss we could incur as a result of that problem (L), and the overall risk exposure (P times L). Keep the high-exposure items at the top of your priority list. You can’t address every risk item, so use this prioritization mechanism to learn where to focus your risk control energy. Set goals for determining when each risk item has been satisfactorily controlled. For some items, your mitigation strategies may focus on reducing the probability, while the approach for other items may emphasize reducing the loss.

The cell labeled Risk Mitigation Approaches allows you to identify the actions you intend to take to keep the risk item under control. With any luck, some of your mitigation approaches can be used to address multiple risk factors. For example, one group I’ve worked with identified several risks related to failures of components of their web delivery infrastructure (servers, firewall, e-mail interface, and so on). A mitigation strategy that addressed several of those risks was to implement an automated monitoring system that could check the status of the servers and communication functions periodically and alert us to any failures.

As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a “risk czar” for the project, who is responsible for staying on top of the things that could go wrong, just as the project manager is staying on top of the activities leading to project completion. One company I know of assigned an individual to such a role, and dubbed him “Eeyore,” after the Winnie-the-Pooh character who always bemoaned how bad things could become.

Keep the top ten or so risks highly visible, and track the effectiveness of your mitigation approaches regularly. As the initial list of top priority items gradually gets beaten into submission, new items may float up into the top ten. Don’t kid yourself into concluding that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk may mean that you have to change your mitigation strategy if you conclude it is ineffective. You can drop the risk off your threat-detection radar when you determine that your mitigation approaches have indeed reduced the loss exposure from that item to an acceptable level.

Adapted from “Practical Project Initiation: A Handbook with Tools” (Microsoft Press, 2007), with permission from author.

Karl Wiegers, Ph.D., is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. Karl’s most recent book is “Practical Project Initiation: A Handbook with Tools.” Karl is also the author of four other books and 170 articles. Karl is a frequent speaker at software conferences and professional society meetings. You can reach Karl through www.projectinitiation.com or www.processimpact.com.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Tuesday, June 24th, 2008 and is filed under Risk Management, Risk Identification, Risk Quantification & Analysis, Risk Response & Control. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

Karl,
Great series. While the information provides valueable insight into the world of risk management, the multiplication of probability of occurance and the consequences of the occurance is no longer allowed in defense and space risk management. Both the numbers are random variables, drawn from an underlying probability distribution. The operation of “multiplication” can not be performed on them. Although PMBOK and others describe such actions, the DOD PMBOK has removed that chapter and replaced it with the correct approach. This guidebook can be found on the web under “dod pmbok”
The primary source of this correctde approach is Edmund Conrows work for the DoD Risk Management Guide and his text http://www.risk-services.com/.
A 5×5 matrix with the Green/Yellow/Red cells predefined for the 5 levels of assessment is now mandatory on all defense and space risk management processes.

Glen B. Alleman
VP, Program Planning and Controls
Defense and Space
Lewis & Fowler, Denver Colorado

Glen B. Alleman wrote on July 9, 2008 - 9:13 am | Visit Link

Karl,
Another small issue. The DoD Risk Management Guide, http://www.sei.cmu.edu/programs/acquisition-support/publications/dod-riskguide.pdf is the source for Risk Management.
http://herdingcats.typepad.com/my_weblog/2007/05/risk_management.html has the diagram for structuring a risk management process.
Risk avoidance is one of 4 mitigation choices, rather than a risk management activities. The activity is “mitigation.” In the current paradigm, “risk retirement” is a better choice, with the retirement activities built into the schedule, complete with funding and resources.

Glen B. Alleman
VP, Program Planning and Controls
Defense and Space
Lewis & Fowler, Denver Colorado

Glen B. Alleman wrote on July 9, 2008 - 9:27 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories