![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppedixD | ALL | | |||||
3.1.1 As discussed in Chapter 2, Roles and Responsibilities, the applicability of these requirements to individual organizational units is determined by the management of the organizational hierarchy within which those organizational units function.
3.1.2 Four categories of requirements are presented in this chapter: General Risk Management Requirements, Requirements for the RIDM Process, Requirements for the CRM Process, and Requirements for Risk Acceptance. Acceptance of risks to safety needs to be justified in part by a finding that all that can be done practically to eliminate or mitigate risks to safety has been done.
3.1.3 If it becomes evident that it is not practical to satisfy one or more requirements, it may be necessary to obtain a waiver to those requirements, rebaseline those requirements, or rebaseline the requirements overall. Insofar as such actions affect risk to safety or mission success, they constitute risk acceptance decisions and are treated with special formality (see paragraphs 3.5 (for program/project risks) or 3.6 (for institutional risks)). This is the case even if, administratively, the risk is not dispositioned as "accepted" under the CRM Plan requirements of paragraph 3.4.2.i.(1).
3.1.4 In the subsections below, requirements are levied on "the manager." This term is used in this NPR to refer to the manager of the organizational unit. The manager can delegate the execution of certain processes as specified in the Risk Management Plan. However, the wording is meant to convey that the manager is accountable for fulfilling the requirements of this NPR and for the decisions that are made, specifically including risk acceptance decisions as defined in the Risk Management Plan.
3.2.1 Some of the following requirements apply specifically to either Acquirers or Providers. Those requirements are labeled either "Acquirer organizations" or "Provider organizations," according to their context.
3.2.2 The manager of each organizational unit (hereafter "the manager") shall:
a. Ensure that the RIDM and CRM processes are implemented within the unit and that key decisions of the organizational unit are risk-informed. Note: Examples of key decisions include: architecture and design decisions, make-buy decisions, source selection in major procurements, budget reallocation (allocation of reserves), and acceptance of risks to safety or mission success.
b. Allocate performance requirements to Provider organizations that are consistent with the unit's own performance requirements. (Acquirer organizations)
c. Ensure, during procurement activities, that risks are identified and analyzed in relation to the performance requirements for each offeror to the unit and that risk analysis results are used to inform the source selection. (Acquirer organizations)
Note: Appendix C contains good practices for procurement/contract risk management.
d. Establish elevation criteria to be applied by Provider organizations reporting to the unit. (Acquirer organizations)
e. Ensure that cross-cutting risks and interdependencies between risks are properly identified as cross-cutting and either managed within the unit or elevated.
Note 1: In general, the cross-cutting character of a given risk is best determined by an organizational unit at a level above the level at which that risk is first identified.
Note 2: Tools of KM are expected to be particularly valuable in this regard.
f. Coordinate the management of cross-cutting risks being managed within the unit with other involved organizational units, e.g., Centers, Mission Support Offices, programs, projects.
g. Ensure that dissenting opinions arising during risk management decision making are handled through the dissenting opinion process as defined in NPD 1000.0.
h. Ensure that risk management activities of the organizational unit support, and are consistent with, ongoing internal control activities defined in NPD 1200.1.
i. Ensure the development of a Risk Management Plan that:
(1) Explicitly scopes all the risk types within the purview of the organizational unit, e.g., for programs/projects, these would be safety, mission success, cost, and schedule risks.
(2) Delineates the unit's approach for applying RIDM and CRM within a graded approach (see Glossary in Appendix A).
(3) Cites the documents that capture the complete set of requirements (within the scope established in (1), above) to be met by the organization, including the top-level Safety and Mission Success requirements levied on the organization, derived requirements, process requirements, and commitments (e.g., testing) (Provider organizations).
Note 1: This plan serves to clarify what detailed requirements (and commitments) the Provider expects to address in the ensuing development of the system. Satisfaction of these requirements is intended to provide evidence of satisfaction of the top-level requirements; correspondingly, risks to fulfillment of the commitments or satisfaction of the requirements are a key focus of Risk Management and, in particular, the specification of risk acceptability criteria (see item (7) below). The Acquirer's review of this portion of the plan provides an early opportunity to ensure that the Provider is adequately addressing the safety and mission success requirements and is implementing a risk-informed process in development of the system.
Note 2: For each requirement, this portion of the plan will designate whether the associated risks (including the aggregate risk) are to be assessed quantitatively or qualitatively.
Note 3: NPR 7123.1 describes processes for systematically treating top-level performance requirements and derived requirements implied by them. Accordingly, the present requirement allows for citation, rather than replication, of those requirements in the Risk Management Plan. However, in addition to such requirements on performance of the system or service being developed, the Risk Management Plan also contains Provider commitments (e.g., to perform tests) that are deemed to provide evidence (assurance) to the Acquirer of satisfaction of the performance requirements.
Note 4: Within this formulation, cancellation of commitments to perform tests or demonstrations amounts to either a rebaselining or a waiver proposal and is correspondingly subject to requirements on Risk Acceptance in paragraphs 3.5 (for program/project risks) or 3.6 (for institutional risks).
Note 5: Per NPR 7120.5, cost and schedule commitments are derived from JCL analysis.
(4) Is coordinated with other management plans, such as higher level risk management plans and the Systems Engineering Management Plan (SEMP), when applicable per NPR 7123.1.
(5) Defines categories for likelihood and consequence severity, when risk characterization requires specifying risks in terms of such categories. Determines and documents the protocols for estimation of the likelihood and severity of the consequence components of risks, including uncertainty characterization and quantification.
Note: The characterization of uncertainty is to be implemented in a graded fashion. If uncertainty can be shown to be small based on a simplified (e.g., bounding) analysis, and point estimates of performance measures clearly imply a decision that new information would not change, then detailed uncertainty analysis is unnecessary. Otherwise, some uncertainty analysis is needed to determine whether the expected benefit of the decision is affected significantly by uncertainty. In some cases, it may be beneficial to obtain new evidence to reduce uncertainty, depending on the stakes associated with the decision, the resources needed to reduce uncertainty, and programmatic constraints on uncertainty reduction activities (such as schedule constraints).
(6) Documents risk acceptability criteria/thresholds and elevation protocols (the specific conditions under which a risk management decision is elevated through management to the next higher level). (Agreement between Acquirer and Provider organizations)
Note 1: A "risk acceptability criterion" is a rule for determining whether a given organizational unit has the authority to decide to accept a risk.
Note 2: The Risk Management Plan required in 3.2.2.i. delineates (refer to subparagraph (3)) a body of performance requirements to be met by the Provider. Risk acceptability criteria are formulated to allow the Provider engineering discretion, while still assuring satisfaction of those performance requirements. As long as the performance requirements are being satisfied, the Provider has discretion to act; if satisfaction of the requirements would be placed in doubt by acceptance of a risk, then either the risk is elevated, or the requirements are rebaselined.
(7) Identifies stakeholders, such as Risk Review Boards, to participate in deliberations regarding the disposition of risks.
(8) Establishes risk communication protocols between management levels, including the frequency and content of reporting, as well as identification of entities that will receive risk tracking data from the unit's risk management activity.
Note 1: This communication may be accomplished using standard reporting templates, including risk matrices, whose formulation and interpretation are agreed between the affected units, recognizing that risk communication inputs to any given level (e.g., the program level) from different units (e.g., projects) should be defined consistently, in order to support decision-making at that level.
Note 2: In general, elevation protocols and communication protocols are specific to levels and units. A risk decision that requires elevation from one level to the next may well be manageable at the higher level, since the unit at that level has more flexibility and authority. The overall effectiveness of the risk management effort depends on the proper assignment of risk acceptability criteria and thresholds.
Note 3: For Center mission support and institutional organizations, protocols are needed for reporting risks to affected program/project units and vice versa.
(9) Establishes a form for documentation of the manager's decisions to accept risks to safety or mission success, the technical basis supporting those decisions, the concurrence of the cognizant Technical Authorities, and consent of the Risk Takers (if applicable) (refer to paragraph 3.5.3 for application of this form).
(10) Establishes an interval for the periodic review of the assumptions on which risk acceptance decisions are based.
(11) Delineates the processes for coordination of risk management activities and sharing of risk information with other affected organizational units.
(12) Documents the manager's signature and the concurrence of the Acquirer to which the manager reports, which includes concurrence that the Risk Management plan meets the Acquirer's requirements. (Provider organizations)
j. Ensure that decisions to rebaseline performance requirements, grant waivers, or modify Risk Management Plans that affect safety, mission success, or institutional risk are risk-informed consistent with the RIDM process described in Chapter 1 and that they are processed as risk acceptance decisions (refer to requirements in paragraphs 3.5 (for program/project risks) or 3.6 (for institutional risks)). Note: Per requirements in paragraph 3.2.2.i., the Risk Management Plan contains not only performance requirements, but also commitments (e.g., to testing or demonstration activities). A reduction in certain commitments could entail acceptance of some risk to safety or mission success.
k. Ensure that risk documentation for both RIDM and CRM is maintained in accordance with NPD 1440.6 and NPR 1441.1, and under formal configuration control, with a capability to identify and readily retrieve the current and all archived versions of risk information and the Risk Management Plan.
3.2.3 Within a graded approach, managers responsible for lower-cost, lower-priority missions that may have lower likelihood of success (e.g., Cubesat, Risk Class D missions (see NPR 8705.4)) fulfill the above requirements by committing to satisfy levied technical requirements and reporting at milestone reviews on the status of satisfying the requirements, including concurrence(s) from the concurring authority for the assets put at risk by the project.
Note: Satisfaction of properly defined technical requirements means that the project will "do no harm" to assets potentially put at risk by the project. For example, a secondary payload does not pose risk to the launch vehicle, primary payload(s), host platform (e.g., International Space Station), or operational environment (e.g., orbital debris environment, etc.).
3.3.1 The manager shall ensure that key decisions, including risk acceptance decisions, are informed by Analysis of Alternatives carried out by applying the RIDM process (refer to Figure 3) with a level of rigor that is commensurate with the significance and the complexity of the decisions.
3.3.2 The manager shall ensure that:
a. The rationale for the selected decision alternative is developed and documented to include contending decision alternatives considered, a summary of risk analysis results for each alternative, and the pros and cons of each alternative.
b. The bases for performance requirement baselines (or rebaselines) informed by the RIDM process are captured and documented and that these baselines (including associated institutional requirements) are applied to scope the unit's CRM implementation.
3.4.1 The manager shall coordinate the unit's CRM process (refer to Figure 4) with the CRM processes of organizational units at levels above and below, including contractors.
3.4.2 The manager shall ensure that:
a. Risk identification is comprehensive and consistent with the baseline performance requirements of that unit. (related to IDENTIFY step)
b. Risk analyses performed to support RIDM (see paragraph 3.3.) are used as input to the "IDENTIFY" step of CRM. (related to IDENTIFY step)
c. The results of risk identification are documented to provide input to the "ANALYZE" step and to characterize the risks for purposes of tracking. (related to IDENTIFY step)
Note: When this documentation takes the form of a "risk statement" or "risk scenario," NASA/SP-2011-3422 uses the following format: "Given that [CONDITION], there is a possibility of [DEPARTURE] from the baseline adversely impacting [ASSET], thereby leading to [CONSEQUENCE]." (Refer to NASA/SP-2011-3422 for more information on risk statements.) Each risk statement or scenario is accompanied by a descriptive narrative, which captures the context of the risk by describing the circumstances, contributing factors, uncertainty, range of possible consequences, and related issues (such as what, where, when, how, and why).
d. When a risk management decision is elevated from a lower-level organizational unit, the associated risk is recalibrated with respect to the requirements, thresholds, and priorities that have been established at the higher level, and the recalibrated risks are entered into the "PLAN," "TRACK," and "CONTROL" steps (paragraphs h. through q.) at the higher level. (related to ANALYZE step)
e. Wherever determined to be feasible (as documented in the Risk Management Plan), aggregate risk is characterized through analysis (including uncertainty evaluation), as an input to the decision-making process. (related to ANALYZE step)
f. Analyzed risks are prioritized and used as input to the "PLAN," TRACK," and "CONTROL" steps. (related to ANALYZE step)
g. The results of the "ANALYZE" step are documented. (related to ANALYZE step)
h. Decisions made on the disposition of risks (including decisions regarding implementation of control measures) are informed by the risk analysis results and are consistent with the defined thresholds established in paragraph 3.2.2.i.(6). (related to PLAN step)
i. Only one of the following possible risk dispositions is applied to any given risk. (related to PLAN step)
(1) When a decision is made to ACCEPT a risk, each acceptance is clearly documented in the organizational unit's risk database, including the rationale for acceptance, the assumptions (including the conditions (e.g., programmatic constraints)) on which the acceptance is based, the applicable risk acceptance criteria, and the interval (as required by the Risk Management Plan) after which the assumptions will be periodically reviewed for any changes that might affect the continued acceptability of the risk. Additionally, for risk acceptance decisions, the requirements in paragraphs 3.5 (for program/project risks) or 3.6 (for institutional risks) apply.
(2) When a decision is made to MITIGATE a risk, a risk mitigation plan (including contingency planning) is developed and documented in the risk database (including the parameters that will be tracked to determine the effectiveness of the mitigation).
(3) When a decision is made to CLOSE a risk, the closure rationale is developed, and both rationale and management approval are documented in the risk database.
(4) When a decision is made to WATCH a risk, tracking requirements are developed and documented in the risk database. All risks categorized as "WATCH" have triggering events, decision points, dates, milestones, necessary achievements, or goals identified.
(5) When additional information is needed to make a decision, efforts to RESEARCH a risk (obtain additional information) are documented and tracked in the risk database.
(6) When dispositions (1), (2), (3), (4), or (5) above cannot be applied, the decision is elevated to the organizational unit management at the next higher level (typically the Acquirer) and the action taken is documented in the risk database.
j. For "MITIGATE," "WATCH," and "RESEARCH," an entity is designated to implement the disposition. (related to PLAN step)
k. A process for acquiring and compiling observable data to track the progress of the implementation of risk management decisions is developed and implemented. (related to TRACK step)
l. The cumulative effects of risk management decisions and risk acceptance decisions (i.e., the aggregate effect of accumulated, accepted risks, to ensure the aggregate risk remains tolerable) are tracked. (related to TRACK step)
m. The assumptions on which risk acceptance decisions are based (see 3.4.2.i.(1)) are periodically tracked. (related to TRACK step)
n. Tracking data are disseminated to entities identified in the Risk Management Plan as recipients of these data. (related to TRACK step)
o. Tracking data are evaluated in order to assess the effectiveness of decisions implemented in paragraph 3.4.2.i. (related to CONTROL step)
p. Feedback is provided to affected organizational units, including the Acquirer at the next higher level, on any changes in the status of tracked risks such as, but not limited to, acceptance of a risk or changing a mitigation plan. (related to CONTROL step)
q. If warranted by the tracking data, necessary control action(s) is(are) implemented. (related to CONTROL step)
Note: Because the "Document and Communicate" function of CRM is integral to all of the steps in the CRM process (Figure 4), requirements for documentation and communication are integrated into the preceding steps rather than treated as a separate step.
3.5.1 All key program/project decisions that threaten: 1) fulfillment of the Acquirer's top-level safety and mission success (S&MS) requirements levied on the Provider; 2) fulfillment of derived S&MS requirements developed by the Provider and accepted by the Acquirer as sufficing to demonstrate compliance with top-level requirements; or 3) satisfaction of other Provider commitments (e.g., commitments to conduct flight testing), are subject to the requirements of this section on creation of the basis for the decision, TA concurrence, and risk taker consent (if applicable). This includes decisions made at Key Decision Points (KDP); significant milestones (e.g., Flight Readiness Reviews), which entail consideration of decisions to proceed despite existing risks; when performance requirements are being rebaselined, e.g., rebaselining to relax safety requirements, which tacitly accepts safety risk; when waivers are being considered, e.g., waivers of safety requirements, which may increase risk; and when an Acquirer is taking delivery of a system or capability, which entails assumption of responsibility for managing the associated risks, including risks previously accepted by the Provider.
3.5.2 Although the above decisions are not necessarily couched as "risk acceptance" decisions, they nevertheless have implications for safety or mission success. Each KDP functions as an integrated system-level roll-up of the many decisions at different levels in the organization through which risk has been implicitly or explicitly accepted up to that point, and a decision to proceed represents both formal acceptance of this risk and accountability for this risk going forward.
3.5.3 Each manager shall ensure that each decision accepting risk to safety or mission success (e.g., requirements definition/compliance/waiver, change requests, formal board directives and decisions, dissenting opinion dispositions, etc.) is clearly documented in the organizational unit's risk database, in the formal configuration management system where the associated decision was approved, or in a formal safety process system, on a program-defined form including:
a. The manager's signature, documenting or referencing:
(1) The case (technical and programmatic) relied upon to justify the decision;
(2) The assumptions, programmatic constraints, evaluation of aggregate risk, and the acceptance criteria on which the decision is based;
(3) The rationale for acceptance, including satisfaction of the organization's risk acceptance criteria.
Note 1: The form and content of the "case (technical and programmatic) relied upon" depends on the circumstances. For example: 1) for acceptance of individual risks, the case may include Analysis of Alternatives considering the balance between safety, mission success, cost, and schedule performance considerations. 2) At a KDP, a comprehensive, integrated case will have been developed to support a decision to progress to the next phase of the life cycle.
Note 2: The purpose of this requirement is not to compel execution of the formal processes for acceptance of every minor risk or decision individually but rather to foster the identification and management of credible risks, both individually and as a group, based on a technically sound analysis, in order to promote understanding of the aggregate risk being accepted, and to assign accountability for risk acceptance with the programmatic decision makers.
b. The TAs' signatures with their concurrence positions, documenting or referencing their evaluations of the technical merits of the case, the manager's authority to accept the risk, and the acceptability of the risk. Note: Refer to Note under paragraph 2.3.3.c.
c. When there is risk to humans, the signature of actual risk-taker(s) (or official spokesperson[s] and applicable supervisory chain) documenting their consent to assume the risk.
3.5.4 In the event of TA or risk taker nonconcurrence in a manager's risk acceptance decision, the TA(s) or risk taker(s) shall elevate the risk acceptance decision one level up in the organizational hierarchy in accordance with the dissenting opinion process (NPD 1000.0).
3.5.5 In the event of TA concurrence and risk taker consent (if applicable) in a manager's risk acceptance decision, the manager shall report each decision accepting risks to safety or mission success one level up in the organizational hierarchy.
Note: Risks are reported up one level because it is important to track and manage the aggregate risk at the Acquirer's level.
3.5.6 When an Acquirer takes delivery of the system or service, management of the outstanding risks of the system or service, including risks previously accepted by the Provider, becomes the Acquirer's current responsibility. The Acquirer shall integrate the outstanding risks into the Acquirer's risk management process, based on:
a. The TA (at the Provider's level) findings accompanying the Provider's technical basis.
b. Independent evaluation of the technical basis by the TA at the Acquier's level.
Note 1: Risks that were previously accepted by the Provider may now be reducible, given the additional resources and flexibility available to the Acquirer.
Note 2: A decision by the Acquirer not to accept responsibility for managing (or accepting) the risk is tantamount to refusing delivery of the system. This situation is intended to be precluded by processes described above.
3.5.7 For lower-cost, lower-priority missions that may have lower likelihood of success (e.g., Cubesat, Risk Class D missions (see NPR 8705.4)), responsible project managers may limit formal risk acceptance decisions (excluding those related to personnel or public safety) to milestone and flight readiness reviews (see paragraph 3.2.3).
Note: Refer to paragraph 3.2.3 for "graded approach" considerations.
For "institutional risks" (as defined in Appendix A), the Center Director shall develop, document in the institutional risk management plan, and implement a process for institutional risk acceptance that meets the intent of the requirements of paragraph 3.5. Depending upon the nature of the risk, the process should specify who the individual risk acceptor is and who serves as the concurring authority (analogous to the TA role in paragraph 3.5), with the understanding that the Center Director remains accountable for institutional risk acceptance decisions at the Center.
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppedixD | ALL | |
| | NODIS Library | Program Management(8000s) | Search | |