Risk Management Map

Elaine Hall, Ph. D. - Level 6 Software

Introduction

In software-intensive product development, relatively risk-free opportunities are long gone. Software risk is actually on the rise because it increases as system complexity increases. Managing risk is necessary when software risk prevents us from achieving our goals and objectives. People inherit risk at work by assuming one (or more) of the project roles. Unfortunately, people do not inherit the ability needed to manage the risk. The ability to manage risk is a developmental process that is learned through education and experience.

Managing risk is a lot like playing golf. Known risks on a golf course include sand traps and water hazards. We can recognize a golfer ’s skill level by how the person manages these risks, for example:

Novice: In a round of golf, novices have no idea how many balls they will lose in the water.

Beginner: Around the water hazard, beginners play their less expensive balls. They would rather lose old balls than new ones. Intermediate: Because they know their capability with each iron, intermediates often switch clubs and lay up before they attempt to cross the water.

Advanced: Those who are advanced determine the length of the water hazard and select the appropriate club. They may push the limits of their capability or play it safe, depending on the margin needed to win.

Expert: Experts do not see the water as an obstacle. When they take aim, they account for both wind direction and velocity. They visualize the ball landing in the best position for their next shot.

No two golf courses or software projects are ever the same. For this reason, software engineers, like golfers, must develop general skills for managing risk through practice. To progress from risk management novice to expert, you can use the Risk Management Map described in the book Managing Risk: Methods for Software Systems Development1. Developed from empirical data on software-intensive projects (1992-1997), the Risk Management Map charts the course for increasing the ability to manage software risk. As shown in Figure 1, the map contains five evolutionary stages: Problem, Mitigation, Prevention, Anticipation, and Opportunity.


Risk Map

Figure 1. Risk Management Map


Risk Management Map

The Risk Management Map is a practical guide to understanding the path to increasing your ability to manage risk by transitions through five stages. At each stage, a vision provides the direction for your journey.

Stage 1: Problem
The problem stage describes the circumstances when risk identification is not seen as positive. It is characterized by a lack of communication, which causes a subsequent lack of coordination. People are too busy solving problems to think about the future. Risks are not addressed until they become problems, because either management was not aware of the risk or inaccurately estimated the risk’s probability of occurrence. Since management reaction to hearing risks is typically to shoot the messenger, most people will not deliver bad news. Crisis management is used to address existing problems. People learn that fire fighting can be exciting, but it causes burnout.

Stage 2: Mitigation
The second stage, the mitigation stage, details the shift from crisis management to risk management. Management now incorporates risk management technology by asking, “What can go wrong?” and “What are the consequences?” This stage is characterized by an introduction to risk concepts. That is, people become aware of risks but do not systematically confront them. Since their knowledge and experience using risk management are limited, they may be unsure of how to communicate risks. In this stage, managers use risk management to reduce the probability and consequence of critical risks by implementing a contingency plan if the original plan fails.

Stage 3: Prevention
The prevention stage discusses the shift from risk management viewed as a manager’s activity to a team activity. This third stage is a transitional one where the approach changes from avoidance of risk symptoms to identification and elimination of the root cause of risk. It is characterized by team and occasional customer involvement, as managers understand that risk management is a dynamic process that cannot be performed in isolation. Instead of focusing on cost and schedule risk (a management perspective, usually a symptom of technical risk), a focus on technical risks leads to a discovery of the source of risk. Prevention is a turning point from a reactive to a more proactive approach to risk management. Most people are experienced and comfortable in risk identification but are unsure how to quantify risks.

Stage 4: Anticipation
The fourth stage, the anticipation stage, describes the shift from subjective to quantitative risk management through the use of measures to anticipate predictable risks. It is characterized by the use of metrics to anticipate failures and predict future events. The project team and customer use risk management to quantify risks with reasonable accuracy to focus on the right priorities. A proactive approach to attacking risks and assessing alternatives is used. Alternatives are easier to compare using a quantitative approach. By this early warning system, anticipated problems are avoided through corrective action.

Stage 5: Opportunity
The final stage, the opportunity stage, is a positive vision of risk management that is used to innovate and shape the future. Potentially the most powerful paradigm shift is in perceiving risks as chances to save money and do better than planned. Risk, like quality, is everyone’s responsibility. Professional attitudes of engineering excellence allow for open communication and individual contribution. We admit that there are things that we do not know and allow for their existence using a best-case, worst-case scenario. People understand there is an opportunity cost associated with every choice, and knowing these trade-offs improves their decision-making ability. In the hands of the many, a positive expectation of using risk management to exceed established goals becomes a powerful weapon.

The structure of the Risk Management Map is similar to the arrow of a state-transition diagram that takes you to another node. As shown in Figure 2, a “stage” transition takes you to a higher level of risk management capability. Stages describe incremental enhancements in the capability to manage risk. To achieve the next stage of development, you need the vision, goals, and strategy provided by the Risk Management Map.


Map Architecture

Figure 2. Map Architecture


Map Architecture:

The underlying structure of the Risk Management Map supports the transition between stages. Stages provide incremental enhancements in the capability to manage risk. Vision guides the way to the next stage. Goals are accomplished to achieve the vision. Strategy is the activity that supports goal attainment. Vision: Vision is an ideal state of the practice that guides the journey. It acts as a driving force that provides the motivation required to continue our effort. For each stage, a vision provides direction and guides the way to the next stage. The Risk Management Map paints a picture of five progressive stages through visions of competitive advantage, customer satisfaction, increased predictability, and maximized opportunities.

Goals: To achieve the vision, you must accomplish goals. The Risk Management Map provides the goals to bring each vision into reality. It is based on evolving the major factors that affect risk management capability: people, process, infrastructure and implementation. [Note: Chapters in Managing Risk describe each of the following map goals.]

People are a critical factor in communicating the issues, concerns, and uncertainties in their work that translate to risk. Goals for the people are Stage 1: Problem, Stage 2: Mitigation, Stage 3: Prevention, Stage 4: Anticipation, and Stage 5: Opportunity.

Process is a major factor because it describes the steps to predictable risk management results. Process goals are identify risk, analyze risk, plan risk, track risk, and resolve risk.

Infrastructure is a major factor because it establishes the culture that supports use of risk management. Infrastructure goals are develop the policy, define standard process, train risk technology, verify compliance, and improve practice.

Implementation is a major factor because it assigns to the project the responsibility and authority to execute the plan. Implementation goals are establish the initiative, develop the plan, tailor the standard process, assess risk, and control risk.

Strategy: Strategy is the activity that supports goal attainment. The Risk Management Map provides a strategy to realize each goal. It specifies an approach to achieve goals and yields activity to check for results. If the results do not support goal attainment, you can make tactical adjustments. [Note: Subsections of each chapter in Managing Risk outline the strategy the map provides and arrange the required activities in their proper order.] Transformation from risk management novice to expert is a process of gradual growth and change. The Risk Management Map provides a practical focus needed for this evolution. The ability to manage risk is a “use-it-or-lose-it” proposition. You must apply your ability to manage risk to achieve the control, higher return, or opportunities that you envision. If you develop the skill to manage risk but choose not to use this ability, you will lose your competitive edge. Knowledge without action is insufficient to derive the benefits of risk management.

About the Author

Elaine M. Hall is founder of Level 6 Software and author of Managing Risk: Methods for Software Systems Development (c)1998 - (Addison Wesley SEI Series in Software Engineering).

Dr. Hall is chair of the International Council on Systems Engineering Risk Management Working Group.

Contact Information

Dr. Elaine M. Hall
Level 6 Software
530 Franklyn Ave.
Indialantic, FL 32903
Phone/Fax: (407) 728-RISK
www.level6software.com


Table of Contents Next

Footnotes
  1. Hall E. Managing Risk: Methods for Software Systems Development.
    Reading, MA: Addison Wesley, 1998.2.