Sample Selection

Chapter 8: Risk Mitigation Strategies

Each strategy is discussed in turn.

8.1 Risk avoidance

Risk avoidance is concerned with changing the situation to reduce the probability of a potential problem to an acceptable level. If a timing constraint in a real-time system is of concern perhaps the timing constraint can be relaxed or perhaps a faster hardware processor can be used; if there is insufficient time to complete the project perhaps the schedule can be extended, thus avoiding the risk of late delivery.

As mentioned above, risk factors are often created by project constraints and can sometimes be avoided by modifying the constraints. Process constraints (schedule, budget, resources), product constraints (features and quality attributes), and technology constraints (processor speed, available memory) should be examined. Some constraints may be essential to a successful outcome. Others, on closer examination, may be relaxed or removed.

8.2 Risk transfer

Risk transfer involves reallocating the requirements that created the risk factor to another system component or another organizational unit that can better handle the risk factor. Data compression, for example, may have to be implemented in a special purpose chip if the data compression algorithm cannot be executed rapidly enough in software. Or, you may decide to use a subcontractor for certain parts of your project if your project team does not have the necessary expertise to implement those parts.

Care must be taken that transfer of a risk factor does not create other unacceptable risks. The time and expense required to design and develop a special purpose chip may create unacceptable risks to cost and schedule. Managing a subcontractor may represent a greater risk to success than the learning curve required for your team; and, your project will fail if the subcontractor fails to deliver acceptable components within an acceptable time frame.

8.3 Risk acceptance

Risk acceptance is the third strategy for mitigating a risk factor. Acceptance involves acknowledging the risk factor but taking no action at the present time other than placing the risk factor on a watch list. Although risk acceptance does not result in a specific mitigation activity, each risk factor on a watch list is frequently re-examined on a periodic basis to determine if the level of probability, impact, or time frame has become prominent enough to warrant additional mitigation activities (e.g., avoidance, transfer, immediate action, or contingent action).

A watch list thus serves as a constant reminder to re-examine risk factors that may become more serious as your project progresses. Project staffing for example, might be sufficient for the next 3 months but a concern for future staffing might result in placing staffing issues on the watch list. If staffing issues have not been resolved as the time of need approaches an immediate action plan might be developed and implemented to acquire the needed staff members.

8.4 Immediate action

Immediate actions are risk mitigation activities that are undertaken now to reduce the probability and/or potential impact of a potential problem (i.e., a risk factor) that may later become a real problem. Immediate actions are specified in immediate action plans. Suppose, for example, that your project team has insufficient skill in using the Java programming language. You might implement an immediate-action training plan to improve their skills and thereby reduce the risk of delivering an unacceptable product and/or overrunning the delivery schedule.

8.5 Contingent action

Contingent action is the fifth mitigation strategy listed in Table 16. Contingent actions are specified in contingency plans that are prepared for potential problems for which no immediate actions are warranted. If, for example, you are pursuing an incremental development strategy, lack of sufficient memory or inadequate response time may become a problem later but, for the elements implemented thus far, memory usage and the response time are within allocated limits for those system parameters. These kinds of risk factors become problems when (if) objective risk indicators (objective measures) cross predetermined thresholds (the problem triggers).

A template for, and an example of a contingency plan is presented in Table 18; as indicated, a contingency plan specifies:

• the risk indicator to be measured,
• the frequency of measurement,
• the threshold value for contingent action (i.e., the problem trigger),
• the contingent-action plan, and
• the specified duration for the contingent actions to resolve the problem.

The last item (specified duration) is an important element of a contingency plan because a project enters crisis mode if the contingent actions do not achieve the success criteria specified in the plan within the specified duration.

Product Descriptions, Author Bios, Table of Contents