Systems Engineering: Risk Mitigation

Risk mitigation planning, implementation, and progress monitoring comprise the fourth and fifth critical steps in the risk management process. Other steps include:

• Risk Identification
• Risk Management Approach and Plan
• Risk Impact Assessment and Prioritization
• Risk Mitigation Planning, Implementation, and Progress Monitoring
• Selecting Risk Management Tools

Read an introduction to risk management  to learn more about this collection of resources originally published in MITRE’s Systems Engineering Guide.

Risk Mitigation Planning, Implementation, and Progress Monitoring: Context

As part of an iterative process, the risk mitigation step involves development of mitigation plans designed to manage, eliminate, or reduce risk to an acceptable level. Once a plan is implemented, it is continually monitored to assess its efficacy with the intent of revising the course of action if needed.

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) working on government programs develop actionable risk mitigation strategies and monitoring metrics; monitor implementation of risk mitigation plans to ensure successful project and program completion; collaborate with the government team in conducting risk reviews across projects and programs; and analyze metrics to determine ongoing risk status and identify serious risks to elevate to the sponsor or customer.

Risk Mitigation Strategies

General guidelines for applying risk mitigation handling options are based on the assessed combination of the probability of occurrence and severity of the consequence for an identified risk. These guidelines are appropriate for many, but not all, projects and programs.

Risk mitigation handling options include:

• Assume/accept: Acknowledge the existence of a particular risk and make a deliberate decision to accept it without engaging in special efforts to control it. Approval of project or program leaders is required.
• Avoid: Adjust program requirements or constraints to eliminate or reduce the risk. This adjustment could be accommodated by a change in funding, schedule, or technical requirements.
• Control: Implement actions to minimize the impact or likelihood of the risk.
• Transfer: Reassign organizational accountability, responsibility, and authority to another stakeholder willing to accept the risk.
• Watch/monitor: Monitor the environment for changes that affect the nature and/or the impact of the risk.

Each of these options requires developing a plan that is implemented and monitored for effectiveness. More information on handling options is discussed under best practices and lessons learned below.

From a systems engineering perspective, common methods of risk reduction or mitigation with identified program risks include the following, listed in order of increasing seriousness of the risk:

1. Intensified technical and management reviews of the engineering process
2. Special oversight of designated component engineering
3. Special analysis and testing of critical design items
4. Rapid prototyping and test feedback
5. Consideration of relieving critical design requirements
6. Initiation of fallback parallel developments

When determining the method for risk mitigation, the MITRE SE can help the customer assess the performance, schedule, and cost impacts of one mitigation strategy over another. For something like "parallel" development mitigation, MITRE SEs could help the government determine whether the cost could more than double, while time might not be extended by much (e.g., double the cost for parallel effort, but also added cost for additional program office and user engagement).

For conducting rapid prototyping or changing operational requirements, MITRE SEs can use knowledge in creating prototypes and using prototyping and experimenting for projecting the cost and time to conduct a prototype to help mitigate particular risks (e.g., requirements). Implementing more engineering reviews and special oversight and testing may require changes to contractual agreements. 

MITRE systems engineers can help the government assess these (schedule and cost) by helping determine the basis of estimates for additional contractor efforts and providing a reality check for these estimates. 

Best Practices and Lessons Learned

What actions are needed? When must actions be completed?

Handling Options

Assume/accept. Collaborate with the operational users to create a collective understanding of risks and their implications. Risks can be characterized as impacting traditional cost, schedule, and performance parameters. Risks should also be characterized as impact to mission performance resulting from reduced technical performance or capability. Develop an understanding of all these impacts. Bringing users into the mission impact characterization is particularly important to selecting which "assume/accept" option is ultimately chosen. Users will decide whether accepting the consequences of a risk is acceptable. Provide the users with the vulnerabilities affecting a risk, countermeasures that can be performed, and residual risk that may occur. Help the users understand the costs in terms of time and money.

 Avoid. Again, work with users to achieve a collective understanding of the implications of risks. Provide users with projections of schedule adjustments needed to reduce risk associated with technology maturity or additional development to improve performance. Identify capabilities that will be delayed and any impacts resulting from dependencies on other efforts. This information better enables users to interpret the operational implications of an "avoid" option.

Control. Help control risks by performing analyses of various mitigation options. For example, one option is to use a commercially available capability instead of a contractor developed one. In developing options for controlling risk in your program, seek out potential solutions from similar risk situations of other MITRE customers, industry, and academia. When considering a solution from another organization, take special care in assessing any architectural changes needed and their implications.

Transfer. Reassigning accountability, responsibility, or authority for a risk area to another organization can be a double-edged sword. It may make sense when the risk involves a narrow, specialized area of expertise not normally found in program offices. But transferring a risk to another organization can result in dependencies and loss of control that may have their own complications. Position yourself and your customer to consider a transfer option by acquiring and maintaining awareness of organizations within your customer space that focus on specialized needs and their solutions. Acquire this awareness as early in the program acquisition cycle as possible, when transfer options are more easily implemented.

Watch/monitor. Once a risk has been identified and a plan put in place to manage it, there can be a tendency to adopt a "heads down" attitude, particularly if the execution of the mitigation appears to be operating on "cruise control." Resist that inclination. Periodically revisit the basic assumptions and premises of the risk. Scan the environment to see whether the situation has changed in a way that affects the nature or impact of the risk. The risk may have changed sufficiently so that the current mitigation is ineffective and needs to be scrapped in favor of a different one. On the other hand, the risk may have diminished in a way that allows resources devoted to it to be redirected.

Determining Mitigation Plans

Understand the users and their needs. The users/operational decision makers will be the decision authority for accepting and avoiding risks. Maintain a close relationship with the user community throughout the system engineering life cycle. Realize that mission accomplishment is paramount to the user community and acceptance of residual risk should be firmly rooted in a mission decision.

Seek out the experts and use them. Seek out the experts within and outside MITRE. MITRE's technical centers exist to provide support in their specialty areas. They understand what's feasible, what's worked and been implemented, what's easy, and what's hard. They have the knowledge and experience essential to risk assessment in their area of expertise. Know our internal centers of excellence, cultivate relationships with them, and know when and how to use them.

Recognize risks that recur. Identify and maintain awareness of the risks that are "always there"—interfaces, dependencies, changes in needs, environment and requirements, information security, and gaps or holes in contractor and program office skill sets. Help create an acceptance by the government that these risks will occur and recur and that plans for mitigation are needed up front. Recommend various mitigation approaches—including adoption of an evolution strategy, prototyping, experimentation, engagement with broader stakeholder community, and the like.

Encourage risk taking. Given all that has been said in this article and its companions, this may appear to be an odd piece of advice. The point is that there are consequences of not taking risks, some of which may be negative. Help the customer and users understand that reality and the potential consequences of being overly timid and not taking certain risks in your program. An example of a negative consequence for not taking a risk when delivering a full capability is that an adversary might realize a gain against our operational users. Risks are not defeats but simply bumps in the road that need to be anticipated and dealt with.

Recognize opportunities. Help the government understand and see opportunities that may arise from a risk. When considering alternatives for managing a particular risk, be sure to assess whether they provide an opportunistic advantage by improving performance, capacity, flexibility, or desirable attributes in other areas not directly associated with the risk.

Encourage deliberate consideration of mitigation options. This piece of advice is good anytime, but particularly when supporting a fast-paced, quick reaction government program that is juggling many competing priorities. Carefully analyze mitigation options and encourage thorough discussion by the program team. This is the form of the wisdom "go slow to go fast."

Not all risks require mitigation plans. Risk events assessed as medium or high criticality should go into risk mitigation planning and implementation. On the other hand, consider whether some low criticality risks might just be tracked and monitored on a watch list. Husband your risk-related resources.

Mitigation Plan Content

Determine the appropriate risk manager. The risk manager is responsible for identifying and implementing the risk mitigation plan. He or she must have the knowledge, authority, and resources to implement the plan. Risk mitigation activities will not be effective without an engaged risk manager. It may be necessary to engage higher levels in the customer organization to ensure the need for the risk manager is addressed. This can be difficult and usually involves engaging more senior levels of the MITRE team as well.

Develop a high-level mitigation strategy. This is an overall approach to reduce the risk impact severity and/or probability of occurrence. It could affect a number of risks and include, for example, increasing staffing or reducing scope.

Identify actions and steps needed to implement the mitigation strategy. Ask these key questions:

1. What actions are needed?

• Make sure you have the right exit criteria for each. For example, appropriate decisions, agreements, and actions resulting from a meeting would be required for exit, not merely the fact that the meeting was held.
• Look for evaluation, proof, and validation of met criteria. Consider, for example, metrics or test events.
• Include only and all stakeholders relevant to the step, action, or decisions.

2. When must actions be completed?

• Backward Planning: Evaluate the risk impact and schedule of need for the successful completion of the program and evaluate test events, design considerations, and more.
• Forward Planning: Determine the time needed to complete each action step and when the expected completion date should be.
• Evaluate key decision points and determine when a move to a contingency plan should be taken

3. Who is the responsible action owner?

• What resources are required? Consider, for example, additional funding or collaboration.
• How will this action reduce the probability or severity of impact?

Develop a contingency plan ("fall back, plan B") for any high risk.

• Are cues and triggers identified to activate contingency plans and risk reviews?
• Include decision point dates to move to fallback plans. The date to move must allow time to execute the contingency plan.

Evaluate the status of each action. Determine when each action is expected to be completed successfully.

Integrate plans into IMS and program management baselines. Risk plans are integral to the program, not something apart from it.

Monitoring Risk

Include risk monitoring as part of the program review and manage continuously. Monitoring risks should be a standard part of program reviews. At the same time, risks should be managed continuously rather than just before a program review. Routinely review plans in management meetings.

Review and track risk mitigation actions for progress. Determine when each action is expected to be completed successfully.

Refine and redefine strategies and action steps as needed.

Revisit risk analysis as plans and actions are successfully completed. Are the risks burning down? Evaluate impact to program critical path.

Routinely reassess the program's risk exposure. Evaluate the current environment for new risks or modification to existing risks.