| NODIS Library | Program Management(8000s) | Search |

NPR 8000.4B
Effective Date: December 06, 2017
Expiration Date: December 06, 2022
Printable Format (PDF)

Subject: Agency Risk Management Procedural Requirements

Responsible Office: Office of Safety and Mission Assurance

| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppedixD | ALL |

Chapter 1. Introduction

1.1 Background

1.1.1 Generically, risk management is a set of activities aimed at understanding, communicating, and managing risk to the achievement of objectives. Risk management operates continuously in an activity, proactively risk-informing the selection of decision alternatives and then managing the risks associated with implementation of the selected alternative. In this NPR, risk management is defined in terms of RIDM and CRM. This NPR addresses the application of these processes to all Agency activities directed toward the accomplishment of Agency strategic goals, including: strategic planning and assessment; program and project concept development, formulation, and implementation; institutional management of infrastructure, including physical, human, and information technology resources; and acquisition. This NPR also adds requirements for a formal process of risk acceptance that assigns accountability for each risk acceptance decision to a single responsible, authoritative individual (e.g., organizational unit manager), rather than to a committee or group of individuals. In addition, institutional risks and the coordination of risk management activities across organizational units are addressed.

1.1.2 The purpose of integrating RIDM and CRM into a coherent framework is to foster proactive risk management: to inform better decision making through better use of risk information, and then to manage more effectively implementation risks using the CRM process, which is focused on the baseline performance requirements informed by the RIDM process. Within a RIDM process informed by Analysis of Alternatives (AoA), decisions are made taking into account applicable risks and uncertainties; then, as the decisions are carried out, CRM is applied to manage the associated risks in order to achieve the performance levels that drove the selection of a particular alternative. NPD 1000.0 cites this NPR with regard to the topics of "Clear Roles, Responsibilities, and Decision Making" and "Authority roles regarding risk." Figure 1 shows that this NPR intersects with program/project management (e.g., NPD 7120.4), safety and mission success (e.g., NPD 8700.1), health and medical (e.g., NPD 8900.5), and other domain-specific directives (e.g., NPD 2810.1) and associated requirements.

1.1.3 This NPR supports NASA's internal control activities as specified in NPD 1200.1, which implements Office of Management and Budget (OMB) Circular A-123 and the related Government Accountability Office Standards for Internal Control in the Federal Government, including GAO-14-704G). The framework in this NPR for conducting risk management across strategic, programmatic, financial, and institutional activities is compatible with the Enterprise Risk Management (ERM) integrated framework provided by the Committee of Sponsoring Organizations of the Treadway Commission Framework (COSO, 2004) and the guidance provided in OMB Circulars A-11 and A-123. This risk management framework and associated activities provide a basis for establishing internal controls to ensure that identified risks are maintained within acceptable levels. The effectiveness of the internal controls is assessed and reported in accordance with the requirements contained in NPD 1200.1.

Figure 1. Intersection of NPR 8000.4 with Program/Project and
Domain-Specific Directives and Requirements

1.1.4 This NPR supports NASA's information security activities as specified in NPD 2810.1, which implements security policy best practices and guidance outlined by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800 Series and Federal Information Processing Standards. The framework in this NPR for managing risks associated with cybersecurity threats is compatible with the Framework for Improving Critical Infrastructure Cybersecurity provided by NIST. The NIST framework, which presents a risk-based approach to managing cybersecurity risk that complements NASA's existing risk management processes and cybersecurity programs, supports the implementation of and compliance with the Federal Information Security Modernization Act (FISMA) of 2014 (Public Law 113-283) and is mandated for use by NASA per Presidential Executive Order 13800 on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure.

1.1.5 This NPR is not intended to dictate organizational structure, but rather to be applied and implemented within existing organizations.

1.2 Risk Management within the NASA Hierarchy

1.2.1 Key Concepts In general, risk is concerned with uncertainty about future outcomes. For the purposes of this NPR, risk is the potential for shortfalls with respect to achieving explicitly established and stated objectives. As applied to programs and projects, these objectives are translated into performance requirements, which may be related to institutional support for mission execution or related to any one or more of the following domains:

a. Safety

b. Mission Success (Technical)

c. Cost

d. Schedule In this NPR, the term "Performance Measure" is defined generically as a metric to measure the extent to which a system, process, or activity fulfills its intended objectives. Performance Measures for mission execution may relate to safety performance (e.g., avoidance of injury, fatality, or destruction of key assets), mission success (technical) performance (e.g., thrust or output, amount of observational data acquired), cost performance (e.g., execution within allocated budget), or schedule performance (e.g., meeting milestones). Similar performance measures can be defined for institutional support. Conceptually, the risk to an objective consists of the following set of triplets:

a. The scenario(s) leading to degraded performance with respect to one or more performance measures (e.g., scenarios leading to injury, fatality, destruction of key assets; scenarios leading to exceedance of mass limits; scenarios leading to cost overruns; scenarios leading to schedule slippage);

b. The likelihood(s) (qualitative or quantitative) of those scenario(s); and

c. The consequence(s) (qualitative or quantitative severity of the performance degradation) that would result if the scenario(s) was (were) to occur.

Note: "Likelihood" is the probability that a scenario will occur. Its assessment accounts for the frequency of the scenario and the timeframe in which the scenario can occur. For some purposes, it can be assessed qualitatively. For other purposes, it is quantified in terms of frequency or probability. A complete assessment of likelihood also calls for characterization of its uncertainty. Each "Acquirer" is accountable for overseeing the risk management processes of its "Providers" at the next lower level, as well as for managing risks identified at its own level. The term "Acquirer" is used to denote a NASA organization that tasks one or more "Provider" organizations, either within NASA or external to NASA, to produce a system or deliver a service (see Glossary in Appendix A). In most cases, an Acquirer, at a given level within NASA negotiates with each Provider a set of objectives, deliverables, performance measures, baseline performance requirements, resources, and schedules that define the tasks to be performed by the Provider. Once this is established, the Provider is accountable to the Acquirer for managing its own risks against these specifications.

Note: The definition of the relationship between an "Acquirer" and a "Provider" in this NPR is not intended to supersede or alter any provisions of previously approved Agency directives or any other official NASA document (e.g., Program Plan, Memorandum of Understanding, etc.). The Provider reports risks and/or elevates decisions for managing risks to the Acquirer, based on predetermined risk thresholds (illustrated below) that have been negotiated between the Provider and Acquirer. Figure 2 depicts this concept. Risk management decisions are elevated by a Provider when those risks can no longer be managed by the Provider. This may be the case if, for example, resources are not available, or the Provider lacks the decision authority needed in order to manage those risks. In many cases, elevation needs to occur in a timely fashion, in order to allow upper management to respond effectively. The approach is performance-based in the sense that each unit determines the best way to achieve its objectives and performance requirements, rather than being told in detail how these are to be achieved. Risk management decisions may be elevated beyond the next higher level, but it is assumed that a risk management decision is elevated through a stepwise progression.

Note: The relationships between a performance requirement, risks, and associated thresholds can be illustrated using the following example. Suppose that for development of a particular science module, a "mass" performance measure has a baseline performance requirement of 50 kg. Lower mass is preferred; mass significantly greater than 50kg has not been allowed for. The risk associated with this performance requirement is characterized in terms of one or more scenarios leading to higher mass, their associated likelihoods, and the severity of the associated mass exceedance in each case. A threshold for elevation might be established probabilistically, e.g., as a specified probability (P) of exceeding the baseline mass requirement (50 kg in this case). Mission Directorates are responsible for management of technical and programmatic risks within their domains and are responsible for elevating risks to the Program Management Council at the Agency level. Center Directors are responsible for management of institutional risks at their respective Centers. Headquarters Administrator Support Offices and Mission Support Offices are responsible for Agency-wide risk management in their domains in accordance with NPD 1000.3. Center Directors and Mission Support Offices are responsible for elevating risks to the Mission Support Council. Program and project managers are responsible for program and project risks within their respective programs and projects. Refer to Chapter 2 for a full description of roles and responsibilities.

Figure 2. Risk Management in NASA's Organizational Hierarchy Risk management at the Agency level addresses risks identified at the Agency level, as well as risk decisions elevated from Administrator Support Offices, Mission Directorates, and Mission Support Offices. These may have been elevated for any of several reasons, including:

a. A need for the Agency to allocate additional resources for effective mitigation.

b. Agency-level coordination/integration is needed with other organizations/stakeholders.

c. A finding that a risk identified within a Center or Mission Directorate is, in fact, an Agency-level risk. Risk management at the Agency level integrates the full spectrum of risks by:

a. Dealing with risk strategically from an Agency-level perspective. At the Agency level, emphasis is placed on achievement of the Agency's mission objectives and goals versus individual project or program goals/objectives. Per NPD 1000.0, this is carried out by the Agency's Management Councils.

b. Engaging all functions and line management levels.

c. Risk-informing program, mission support, and capability portfolio development and management.

d. Supporting institutional management of infrastructure, e.g., cybersecurity risk management.

1.2.2 RIDM As shown in Figure 3, RIDM within each organizational unit involves:

a. Identification of Alternatives: Formulate Objectives and a diverse set of Performance Measures (to support decision making); Formulate Decision Alternatives, Recognizing both Risks and Opportunities.

b. Analysis of Alternatives: Conduct Integrated Analysis of Risk of Each Alternative; Develop the Technical Basis for Deliberation.

c. Risk-Informed Alternative Selection: Deliberate; Select an Alternative and Accept the Associated Risk Informed by Risk Analysis Results, and Document the Decision and its Rationale. Rather than an isolated activity, RIDM is a key element of the risk management approach used by institutional and programmatic organizations. It informs all aspects of strategic, program and mission, and mission-enabling decision making and is, therefore, conducted in many different venues based on the organization and management processes of the implementing organizational unit. These include council, board, and panel meetings, Authority to Proceed milestone reviews, Safety Review Board meetings, Risk Reviews, Engineering Design and Operations Planning decision forums, and commit-to-flight reviews, among others. Within the RIDM process, the complete set of performance measures (and corresponding assessed risks) is used, along with other considerations, within a deliberative process to improve the basis for decision making. Deliberation helps the organization to make the best possible use of its experience and tacit knowledge. For example, in order to inform decisions that affect safety, safety performance measures (such as crew safety) and related risks (such as contributions to the probability of loss of crew due to micrometeoroid impact) can be considered in light of aspects of performance history that are not captured in the risk models, or aspects of risk that do not relate immediately to existing performance measures. Moreover, deliberation may identify opportunities not only for improvements that are within the purview of the organizational unit, but also for improvements that could be realized by the acquiring organization or by the program as a whole. Communication of such opportunities to the organizational units best situated to seize them can result in modifications to previously selected alternatives and a rebaselining of the requirements (safety, mission success, cost, schedule) that are flowed down to Provider organizations. Once a decision alternative has been selected for implementation, the performance measure values that informed its selection define the baseline performance requirements for CRM. As discussed in paragraph, situations may arise in which it is necessary to revisit the decision and rebaseline the performance requirements.

Figure 3. RIDM Process In order to focus effort and accountability during implementation of the selected alternative, CRM may focus on a set of individual risk contributors (i.e., specific "risks"). However, for some purposes, decision making needs to be supported by evaluation of the "aggregate risk" associated with a given performance measure, i.e., aggregation of all contributions to the risk associated with that performance measure. For example, it may not be sufficient to consider only a list of "risks" to the crew of a human-crewed space vehicle; in order to support some decisions, it is necessary to evaluate the total probability of loss of crew, considering all contributions, as an aggregated risk. Similarly, cost and schedule risk are analyzed probabilistically in an integrated fashion using a Joint Confidence Limit (JCL) analysis per NPR 7120.5. For some performance measures, it may not be practical to quantify the aggregate risk; the feasibility of quantifying aggregate risk is determined for each performance measure and then documented in the Risk Management Plan (see paragraph 3.2.2.i) for each organizational unit.

1.2.3 CRM NASA uses a specific process for the management of risks associated with implementation of designs, plans, and processes. This process, which is represented by the graphic in Figure 4, is referred to as CRM.

Figure 4. CRM Process Steps in the CRM process include: a. IDENTIFY: Identify contributors to risk (shortfalls in performance relative to the baseline performance requirements).

Note: Performance measures determine the scope of CRM. Sometimes, the relationship between an identified risk and performance measures is indirect, but risks within the proper scope of CRM are addressed because they may affect one or more performance measures.

b. ANALYZE: Estimate the probability and consequence components of the risk through analysis, including uncertainty in the probabilities and consequences and, if feasible, estimate aggregate risks.

c. PLAN: Decide on risk disposition and handling, develop and execute mitigation plans, develop contingency plans, and decide what will be tracked.

Note: Risk acceptance is among the possible dispositions (see paragraph 3.4.2.i.(1)). The requirements of paragraphs 3.5 (for program/project risks) or 3.6 (for institutional risks) apply to risk acceptance decisions.

d. TRACK: Track observables relating to performance measures (e.g., technical performance data, schedule variances), as well as the cumulative effects of risk disposition (handling) decisions.

e. CONTROL: Evaluate tracking data to verify effectiveness of mitigation plans, making adjustment to the plans as necessary and executing control measures.

f. Communicate and Document: Communicate and document the above activities throughout the process.

1.2.4 Coordination of RIDM and CRM Within and Across Organizational Units The right-hand portion of Figure 5 shows RIDM (previously shown in Figure 3) and CRM (previously shown in Figure 4) as complementary processes that operate within every organizational unit. Each unit applies the RIDM process to decide how to fulfill its performance requirements and applies the CRM process to manage risks associated with implementation. The left portion of Figure 5 (previously shown in Figure 2) shows the hierarchy of organizations tasked with carrying out a mission. At any given level below the Agency level, there may be multiple organizational units conducting RIDM and CRM. Associated coordination activities include flowdown of performance requirements, risk reporting, and elevation of decisions. Coordination of risk management is suggested by Figure 5. This coordination enables the optimum flow of risk information at all levels of the Agency.

Note: Tools of Knowledge Management (KM) are expected to be particularly valuable in this regard. Each organizational unit reports on its risk management activities to the Acquirer at the next higher level and may elevate individual risk management decisions to that level, if it is determined that those risks cannot be addressed by the originating unit. Refer to paragraph Within each organizational unit, disposition of risks includes the use of defined thresholds whose exceedance should initiate a risk control response by the unit, including the possible elevation of risk management decisions to the Acquirer at the next higher level (as discussed in paragraph It is the responsibility of the Acquirer to assure that the performance requirements assigned to the Provider reflect appropriate tradeoffs between/among competing objectives and risks. It is the responsibility of the Provider to establish the feasibility of managing the risks of the job it is accepting, including risks to fulfillment of derived requirements, and identification of mission support requirements. The performance requirements can be changed, if necessary, but redefining and rebaselining them needs to be negotiated with higher level organizations, documented, and subject to configuration control. Performance requirements work together, so redefinition and rebaselining one performance requirement may force redefinition and rebaselining of another, if the overall program/project objectives are to be satisfied. Redefinition and rebaselining, therefore, imply a tradeoff that needs to be approved by the Acquirer.

Figure 5. Coordination of RIDM and CRM within the NASA Hierarchy (Illustrative) Both CRM and RIDM are applied within a graded approach (refer to the Glossary in Appendix A). At each Center, management of institutional risks affecting programs/projects at the Center is done within the Center institutional hierarchy and coordinated with the program/project units as needed. Since the program/project units are affected by institutional risks without being in a position to control them, in the event that institutional risks threaten accomplishment of program/project unit performance requirements, the program/project units may need to elevate them to the next level within the program/project or Center hierarchies. Agency-wide institutional risks are addressed by NASA Headquarters Administrator Support Offices, Mission Support Offices, and the Mission Support Council.

| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppedixD | ALL |
| NODIS Library | Program Management(8000s) | Search |


This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.