Risk Management Approach and Plan


Definition: Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level [1]. The risk management approach determines the processes, techniques, tools, and team roles and responsibilities for a specific project. The risk management plan describes how risk management will be structured and performed on the project [2].

Keywords: risk management, risk management approach, risk management plan, risk management process

MITRE SE Roles & Expectations: MITRE Systems Engineers (SEs) working on government programs propose and influence, and often design, the risk management approach. They prepare and monitor risk mitigation plans and strategies for the government project or program office, and they review risk management plans prepared by government contractors [3].

Background

As a management process, risk management is used to identify and avoid the potential cost, schedule, and performance/technical risks to a system, take a proactive and structured approach to manage negative outcomes, respond to them if they occur, and identify potential opportunities that may be hidden in the situation [4]. The risk management approach and plan operationalize these management goals.

Because no two projects are exactly alike, the risk management approach and plan should be tailored to the scope and complexity of individual projects. Other considerations include the roles, responsibilities, and size of the project team, the risk management processes required or recommended by the government organization, and the risk management tools available to the project.

Risk occurs across the spectrum of government and its various enterprises, systems-of-systems, and individual systems. At the system level, the risk focus typically centers on development. Risk exists in operations, requirements, design, development, integration, testing, training, fielding, etc. (see the SE Life-Cycle Building Blocks section of this Guide). For systems-of-systems, the dependency risks rise to the top. Working consistency across the system-of-systems, synchronizing capability development and fielding, considering whether to interface, interoperate, or integrate, and the risks associated with these paths all come to the forefront in the system-of-systems environment. At the enterprise level, governance and complexity risks become more prominent. Governance risk of different guidance across the enterprise for the benefit of the enterprise will trickle down into the system-of-systems and individual systems, resulting in potentially unanticipated demands and perhaps suboptimal solutions at the low level that may be beneficial at the enterprise level. Dealing with the unknowns increases and the risks associated with these——techniques in the Guide's section on Enterprise Engineering, such as loose couplings, federated architectures, and portfolio management——can help the MITRE SE alleviate these risks.

Risk Management in System-Level Programs

System-level risk management is predominantly the responsibility of the team working to provide capabilities for a particular development effort. Within a system-level risk area, the primary responsibility falls to the system program manager and SE for working risk management, and the developers and integrators for helping identify and create approaches to reduce risk. In addition, a key responsibility is with the user community's decision maker onwhen to accept residual risk after it and its consequences have been identified. The articles in the Risk Management topic area provide guidance for identifying risk (Risk Identification), mitigating risks at the system level with options like control, transfer, and watch (Risk Mitigation Planning, Implementation, and Progress Monitoring), and a program risk assessment scale and matrix (Risk Impact Assessment and Prioritization). These guidelines, together with MITRE SEs using tools such as those identified in the Risk Management Tools article, will help the program team deal with risk management and provide realism to the development and implementation of capabilities for the users.

Risk Management in System-of-Systems Programs

Today, the body of literature on engineering risk management is largely aimed at addressing traditional engineering system projects—those systems designed and engineered against a set of well-defined user requirements, specifications, and technical standards. In contrast, little exists on how risk management principles apply to a system whose functionality and performance is governed by the interaction of a set of highly interconnected, yet independent, cooperating systems. Such systems may be referred to as systems-of-systems.

A system-of-systems can be thought of as a set or arrangement of systems that are related or interconnected to provide a given capability that, otherwise, would not be possible. The loss of any part of the supporting systems degrades or, in some cases, eliminates the performance or capabilities of the whole.

What makes risk management in the engineering of systems-of-systems more challenging than managing risk in a traditional system engineering project? The basic risk management process steps are the same. The challenge comes from implementing and managing the process steps across a large-scale, complex, system-of-systems—one whose subordinate systems, managers, and stakeholders may be geographically dispersed, organizationally distributed, and may not have fully intersecting user needs.

How does the delivery of capability over time affect how risks are managed in a system-of-systems? The difficulty is in aligning or mapping identified risks to capabilities planned to be delivered within a specified build by a specified time. Here, it is critically important that risk impact assessments are made as a function of which capabilities are affected, when these effects occur, and their impacts on users and stakeholders.

Lack of clearly defined system boundaries, management lines of responsibility, and accountability further challenge the management of risk in the engineering of systems-of-systems. User and stakeholder acceptance of risk management, and their participation in the process, is essential for success.

Given the above, a program needs to establish an environment where the reporting of risks and their potential consequences is encouraged and rewarded. Without this, there will be an incomplete picture of risk. Risks that threaten the successful engineering of a system-of-systems may become evident only when it is too late to effectively manage or mitigate them.

Frequently a system-of-systems is planned and engineered to deliver capabilities through a series of evolutionary builds. Risks can originate from different sources and threaten the system-of-systems at different times during their evolution. These risks and their sources should be mapped to the capabilities they potentially affect, according to their planned delivery date. Assessments should be made of each risk's potential impacts to planned capabilities, and whether they have collateral effects on dependent capabilities or technologies.

In most cases, the overall system-of-systems risk is not just a linear "roll-up" of its subordinate system-level risks. Rather, it is a combination of specific lower level individual system risks that, when put together, have the potential to adversely impact the system-of-systems in ways that do not equate to a simple roll-up of the system-level risks. The result is that some risks will be important to the individual systems and be managed at that level, while others will warrant the attention of system-of-systems engineering and management.

Risk Management in Enterprise Engineering Programs

Risk management of enterprise systems poses an even greater challenge than risk management in systems-of-systems programs.

Enterprise environments (e.g., the Internet) offer users ubiquitous, cross-boundary access to wide varieties of services, applications, and information repositories. Enterprise systems engineering is an emerging discipline. It encompasses and extends "traditional" systems engineering to create and evolve "webs" of systems and systems-of-systems that operate in a network-centric way to deliver capabilities via services, data, and applications through an interconnected network of information and communications technologies. This is an environment in which systems engineering at its "water's-edge."

In an enterprise, risk management is viewed as the integration of people, processes, and tools that together ensure the early and continuous identification and resolution of enterprise risks. The goal is to provide decision makers an enterprise-wide understanding of risks, their potential consequences, interdependencies, and rippling effects within and beyond enterprise "boundaries." Ultimately risk management aims to establish and maintain a holistic view of risks across the enterprise, so capabilities and performance objectives are achieved via risk-informed resource and investment decisions.

Today we are in the early stage of understanding how systems engineering, engineering management, and social science methods weave together to create systems that "live" and "evolve" in enterprise environments.

Requirements for Getting Risk Management Started

  • Senior leadership commitment and participation is required.
  • Stakeholder commitment and participation is required.
  • Risk management is made a program-wide priority and "enforced" as such throughout the program's life-cycle.
  • Technical and program management disciplines are represented and engaged. Both program management and engineering specialties need to be communicating risk information and progress toward mitigation. Program management needs to identify contracting, funding concerns, SEs need to engage across the team and identify risks, costs, and potential ramifications, if the risk were to occur, as well as mitigation plans (actions to reduce the risk, and cost/resources needed to execute successfully).
  • Risk management integrated into the program's business processes and systems engineering plans. Examples include risk status included in management meetings and/or program reviews, risk mitigation plan actions tracked in schedules, and cost estimates reflective of risk exposure.

The Risk Management Plan

The Risk Management Plan describes a process, such as the fundamental steps shown in Figure 1, that are intended to enable the engineering of a system that is accomplished within cost, delivered on time, and meets user needs.

Fundamental Steps of Risk Management
Figure 1. Fundamental Steps of Risk Management

Best Practices and Lessons Learned

In supporting both Department of Defense (DoD) and civilian agency projects and programs, MITRE SEs have found the following minimum conditions needed to initiate and continuously execute risk management successfully. With these, the program increases its chance of identifying risks early so the goals and objectives are achieved [5].

Twenty-One "Musts"

  1. Risk management must be a priority for leadership and throughout the program's management levels. Maintain leadership priority and open communication. Teams will not identify risks if they do not perceive an open environment to share risk information (messenger not shot) or management priority on wanting to know risk information (requested at program reviews and meetings), or if they do not feel the information will be used to support management decisions (lip service, information not informative, team members will not waste their time if the information is not used).
  2. Risk management must never be delegated to staff that lack authority.
  3. A formal and repeatable risk management process must be present—one that is balanced in complexity and data needs, such that meaningful and actionable insights are produced with minimum burden.
  4. The management culture must encourage and reward identifying risk by staff at all levels of program contribution.
  5. Program leadership must have the ability to regularly and quickly engage subject matter experts.
  6. Risk management must be formally integrated into program management
  7. Participants must be trained in the program's specific risk management practices and procedures.
  8. A risk management plan must be written with its practices and procedures consistent with process training.
  9. Risk management execution must be shared among all stakeholders.
  10. Risks must be identified, assessed, and reviewed continuously—not just prior to major reviews.
  11. Risk considerations must be a central focus of program reviews.
  12. Risk management working groups and review boards must be rescheduled when conflicts arise with other program needs.
  13. Risk mitigation plans must be developed, success criteria defined, and their implementation monitored relative to achieving success criteria outcomes.
  14. Risks must be assigned only to staff with authority to implement mitigation actions and obligate resources.
  15. Risk management must never be outsourced.
  16. Risks that extend beyond traditional impact dimensions of cost, schedule, and technical performance must be considered (e.g., programmatic, enterprise, cross-program/cross-portfolio, and social, political, economic impacts).
  17. Technology maturity and its future readiness must be understood.
  18. The adaptability of a program's technology to change in operational environments must be understood.
  19. Risks must be written clearly using the Condition-If-Then protocol.
  20. The nature and needs of the program must drive the design of the risk management process within which a risk management tool/database conforms.
  21. Risk management tool/database must be maintained with current risk status information; preferably, employ a tool/database that rapidly produces "dashboard-like" status reports for management.

It is important for MITRE SEs as well as project and program leaders to keep these minimum conditions in mind with each taking action appropriate for their roles. In particular, the SE should provide effective support as follows:

  • Get top-level buy-in. MITRE SEs can help gain senior leadership support for risk management by highlighting some of the engineering as well as programmatic risks. MITRE SEs should prepare assessments of the impact that risks could manifest and back them by facts and data (e.g., increased schedule due to more development, increased costs, increased user training for unique, technology edge capabilities, and potential of risk that capabilities will not be used because they do not interoperate with legacy systems). MITRE SEs can highlight the various risk areas, present the pros and cons of alternative courses of mitigation actions (and their impacts), and help the decision makers determine the actual discriminators and residual impact to taking one action or another. In addition to data-driven technical assessments, success in getting top-level buy-in requires consideration of political, organizational/operational, and economic factors as seen through the eyes of the senior leadership. Refer to [6] for foundational information on the art of persuasion.
  • Get stakeholder trust. Gain the trust of stakeholders by clearly basing risk reduction or acceptance recommendations on getting mission capabilities to users.
  • Leverage your peers. Someone at MITRE generally knows a lot about every risk management topic imaginable. This includes technical, operational, programmatic dimensions of risks and mitigations. Bringing the company to bear is more that a slogan—it is a technique to use, as risks are determined, particularly in system-of-systems and enterprise. In all likelihood, MITRE is working other parts of these large problems.
  • Think horizontal. Emphasize cross-program or cross-organization participation in risk identification, assessment, and management. Cross-team coordination and communication can be particularly useful in risk management. All 'ilities' (e.g., information assurance, security, logistics, software) should be represented in the risk reviews. Communication of risk information helps illuminate risks that have impact across organizations and amplifies the benefits of mitigations that are shared.
  • Stay savvy in risk management processes and tools. Become the knowledgeable advisor in available risk management processes and tools. Many government organizations have program management offices that have defined risk management processes, templates, and tools. These should be used as a starting point to develop the specific approach and plan for an individual project or program. Make sure the government sponsors or customers have the current information about the risk management approach and plan required by their organizations, and assist them in complying with it. Assist the sponsors or customers in determining the minimum set of activities for their particular program that will produce an effective risk management approach and plan.

References & Resources

  1. National Institute of Standards and Technology, July 2002, Risk Management Guide for Information Technology System, Special Publication 800-30, p. 1.
  2. , A Guide to the Project Management Body of Knowledge, (PMBOK Guide), Fourth Edition, ANSI/PMI 99-001-2008, pp. 273––312.
  3. The MITRE Institute, September 1, 2007, "MITRE Systems Engineering (SE) Competency Model, Version 1," pp. 10, 41–42.
  4. International Council on Systems Engineering (INCOSE), January 2010, , INCOSE-TP-2003-002-03.2, p. 213––225.
  5. Garvey, P. R., 2008, Analytical Methods for Risk Management: A Systems Engineering Perspective, Chapman-Hall/CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.
  6. Neugent, B. "Persuasion."

Additional References & Resources

  • Kossiakoff, A. and W.N. Sweet, 2003, Systems Engineering Principles and Practice, John Wiley and Sons, Inc., pp. 98–106.
  • MITRE SEPO .

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team