Risk Handling

Risk handling includes specific methods and techniques to deal with known risks, identifies who is responsible for the risk issue, and provides an estimate of the cost and schedule associated with reducing the risk, if any. It involves planning and execution with the objective of reducing risks to an acceptable level. The evaluators who assess risk should begin the process by identifying risks and developing handling options and approaches to propose to the program manager, who selects the appropriate one(s) for implementation. There are several factors that can influence our response to a risk, including but not limited to:

• Amount and quality of information on the actual hazards that caused the risk (descriptive uncertainty)

• Amount and quality of information on the magnitude of the damage (measurement uncertainty)

• Personal benefit to project manager for accepting the risk (voluntary risk)

• Risk forced upon project manager (involuntary risk)

• Confusion and avoidability of the risk

• The existence of cost-effective alternatives (equitable risks)

• The existence of high-cost alternatives or possibly lack of options (inequitable risks)

• Length of exposure to the risk

Risk handling must be compatible with the RMP and any additional guidance the program manager provides. A critical part of risk handling involves refining and selecting the most appropriate handling option(s) and specific implementation approach(es) for selected risk issues (often those with medium or higher risk levels). The selected risk handling option coupled with the specific implementation approach is known as the risk handling strategy. The procedure to develop a risk handling strategy is straightforward. First, the most desirable risk handling option is selected, then the best implementation approach for that option is chosen. In cases where one or more backup strategies may be warranted (e.g., high risks), the above procedure is repeated. (While the selected option for a backup strategy may be the same as for the primary strategy, the implementation approach will always be different; else the primary and backup strategy would be identical.)

Personnel who evaluate candidate risk handling strategies may use the following criteria as starting points for evaluation:

• Can the strategy be feasibly implemented and still meet the user's needs?

• What is the expected effectiveness of the handling strategy in reducing program risk to an acceptable level?

• Is the strategy affordable in terms of dollars and other resources (e.g., use of critical materials, and test facilities)?

• Is time available to develop and implement the strategy, and what effect does that have on the overall program schedule?

• What effect does the strategy have on the system's technical performance?

Risk handling options include: risk assumption, risk avoidance, risk control, and risk transfer. Although the control option (often called mitigation) is commonly used in many high-technology programs, it should not automatically be chosen. All four options should be evaluated, and the best one chosen for each risk issue.

The options for handling risk fall into the following categories:

• Risk assumption (i.e., retention): The project manager says, "I know the risk exists and am aware of the possible consequences. I am willing to wait and see what happens. I accept the risk should it occur."

• Risk avoidance: The project manager says, "I will not accept this option because of the potentially unfavorable results. I will either change the design to preclude the issue or change the requirements that lead to the issue."

• Risk control (i.e., prevention or mitigation): The project manager says, "I will take the necessary measures required to control this risk by continuously reevaluating it and developing contingency plans or fall-back positions. I will do what is expected."

• Risk transfer: The project manager says, "I will share this risk with others through insurance or a warranty, or transfer the entire risk to them. I may also consider partitioning the risk across hardware and/or software interfaces."

We now explore each of these risk handling options in somewhat greater detail.

Risk assumption is an acknowledgment of the existence of a particular risk situation and a conscious decision to accept the associated level of risk, without engaging in any special efforts to control it. However, a general cost and schedule reserve may be set aside to deal with any problems that may occur as a result of various risk assumption decisions. This risk handling option recognizes that not all identified program risks warrant special handling; as such, it is most suited for those situations that have been classified as low risk.

The key to successful risk assumption is twofold:

• Identify the resources (e.g., money, people, and time) that will be needed to overcome a risk if it materializes. This includes identifying the specific management actions (such as retesting, and additional time for further design activities) that may occur.

• Ensure that necessary administrative actions are taken to identify a management reserve to accomplish those management actions.

Risk avoidance involves a change in the concept (including design), requirements, specifications, and/or practices to reduce risk to an acceptable level. Simply stated, it eliminates the sources of high or possibly medium risk and replaces them with a lower risk solution. This method may be used in parallel with the up-front requirements analysis, supported by cost/requirement trade-off studies. It may also be used later in the development phase when test results indicate that some requirements cannot be met, and the potential cost and/or schedule impact would be severe.

Risk control does not attempt to eliminate the source of the risk but seeks to reduce the risk. This option may add to the cost of a program, and the selected approach should provide an optimal mix among the candidate approaches of risk reduction, cost effectiveness, and schedule impact. A summary of some common risk control actions includes:

• Alternative design: Create a backup design option that uses a lower risk approach.

• Demonstration events: Demonstration events are points in the program (normally tests) that determine if risks are being successfully reduced.

• Design of experiments: This engineering tool identifies critical design factors that are sensitive, therefore potentially medium or higher risk, to achieve a particular user requirement.

• Early prototyping: Build and test prototypes early in the system development.

• Incremental development: This is design with the intent of upgrading system parts in the future.

• Key parameter control boards: The practice of establishing a control board for a parameter may be appropriate when a particular feature (such as system weight) is crucial to achieving the overall program requirements.

• Manufacturing screening: For programs in the mid- to late-development phases, various manufacturing screens (including environmental stress screening) can be incorporated into test article production and low rate initial production to identify deficient manufacturing processes.

• Modeling/simulation: Modeling and simulation can be used to investigate various design options and system requirement levels.

• Multiple development efforts: Create systems that meet the same performance requirements. (This approach is also known as parallel development.)

• Open systems: Use of carefully selected commercial specifications and standards can result in lower risk levels.

• Process proofing: Particular processes, especially manufacturing and support processes, are critical to achieving system requirements.

• Reviews, walk-throughs, and inspections: These three actions can be used to reduce the likelihood and potential consequences of risks through timely assessment of actual or planned events.

• Robust design: This approach uses advanced design and manufacturing techniques that promote quality and capability through design.

• Technology maturation efforts: Normally, technology maturation is used when the desired technology will replace an existing technology that is available for use in the system.

• Test-analyze-and-fix (TAAF): TAAF is the use of a period of dedicated testing to identify and correct deficiencies in a design.

• Trade-off studies: Arrive at a balance of engineering requirements in the design of a system. Ideally, this also includes cost, schedule, and risk considerations.

• Use of mock-ups: The use of mock-ups, especially man-machine interface mock-ups, can be utilized to conduct early exploration of design options.

• Use of standard items/software reuse: Use of existing and proven hardware and software, where applicable, can potentially reduce risks.

Risk transfer may reallocate risk from one part of the system to another, thereby reducing the overall system and/or lower-level risk. It may also redistribute risks between the buyer (e.g., government) and the seller (e.g., prime contractor), or within the buyer or seller teams. It should be considered as part of the requirements analysis process. Risk transfer is a form of risk sharing and not risk abrogation on the part of the buyer or seller, and it may influence cost objectives. An example is the transfer of a function from hardware implementation to software implementation or vice versa. (Risk transfer is also not deflecting a risk issue because insufficient information exists about it.) The effectiveness of risk transfer depends on the use of successful system design techniques. Modularity and functional partitioning are two design techniques that support risk transfer. In some cases, risk transfer may concentrate risk issues in one area of the design. This allows management to focus attention and resources on that area. Other examples of risk transfer include the use of insurance, warranties, bonding (e.g., bid, performance, or payment bonds), and similar agreements. These agreements are typically between the buyer and seller such that the consequent "costs" of failure will be assumed by the seller for some agreed to price. That price may be in terms of profit dollars, schedule changes, product performance modifications, or other considerations.

Risk handling options and the implemented approaches have broad cost implications. The magnitude of these costs are circumstance-dependent. The approval and funding of handling options and specific approaches should be done by the project manager or Risk Management Board (or equivalent) and be part of the process that establishes the program cost, and performance and schedule goals. The selected handling option and approach for each selected risk issue should be included in the program's acquisition strategy.

Once the acquisition strategy includes the risk handling strategy for each selected risk issue, the cost and schedule impacts can be identified and included in the program plan and schedule, respectively.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment