1. Minimum Recommended Content

The content of the Risk Management Plan is established by NPR 8000.4C ⁰⁰⁹.  Minimum content is: 

1. 1. Risk Strategy
   2. Risk Management Process
   3. Risk Documentation Methods
   4. Risk Reviews
   5. Communication Plan
   6. Stakeholders
   7. Roles and Responsibilities
   8. Risk Types
   9. Risk Sources
   10. k.    Organizational and Project Requirements
   11. Configuration Control

2. Rationale

Software development requires thought and planning before implementation. It is important to document, review, and approve the activities, tools, responsibilities, and other tasks needed to develop software before beginning the work. Planning helps the team consider and put in place those elements needed to efficiently produce the software in the allotted time frame and within the allotted budget.  The plan also provides a basis for monitoring the project's adherence to these processes.

Planning allows others within the project and external to the project to evaluate, integrate, and critique the proposed approach, and the resulting plan helps new members of the software team get up to speed when joining the project. Planning also allows a current project to consider lessons learned from previous projects to avoid previously experienced difficulties.

3. Guidance

Risk management will be performed on all projects (see SWE-086 - Continuous Risk Management ). The risk management plan addresses initial risks and mitigation approaches for them,  as well as the plan for identifying and mitigating new risks as the software development progresses. Risk management also includes the risk strategy, such as the criteria or process by which risks get raised to the mission level or determining which risks need mitigation plans. NPR 8000.4C ⁰⁰⁹ establishes the guidelines by which projects will manage and maintain their risk.

The content of the RM Plan is established by NPR 8000.4C

1. Reflects the risk leadership principles the organizational unit is directed to apply by the next higher level in the pursuit of its objectives, and defines a corresponding risk posture via the definition of risk tolerances and explicit risk acceptance criteria to be applied in the execution of the unit’s activities and projects.
2. Explicitly scopes all the risk types within the purview of the organizational unit, e.g., for projects: safety, mission success, physical security and cybersecurity, cost, and schedule risks.
3. Addresses all the principal possible sources of risk, e.g., for projects or defined activities: both internal and external random events, both internal and external intentional actions.
4. Delineates the unit's approach for applying RIDM and CRM within a graded approach (see Definitions in Appendix A).
5. 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 acceptance criteria (see item (8)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: 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 RMP. However, in addition to such requirements on performance of the system or service being developed, the RMP 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. For additional information, see NPR 7123.1, NASA Systems Engineering Processes and 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 project risks), 3.6 (for institutional risks), or 3.7 (for cross-cutting risks).
   
   Note 5: Cost and schedule commitments are derived from JCL analysis in major programs and projects, or from simpler processes of estimations judged adequate for the purpose, in other programs or projects. For additional information, see NPR 7120.
   
   
6. Is coordinated with other management plans, such as higher-level risk management plans and the Systems Engineering Management Plan (SEMP) when applicable. For additional information, see NPR 7123.1.
7. Defines categories for likelihood and consequence severity, when risk characterization requires specifying risks in terms of such categories, and determines and documents the protocols for estimation of the likelihood and severity of the consequence components of risks, including uncertainty characterization and quantification. For risks resulting from intentional-action sources, where the likelihood dimension of risk may be characterized in conditional terms, i.e., assuming that an intentional source is present, provides and documents corresponding definitions and determinations for categories or metrics that it selects to characterize the conditional likelihood characterization of such risks.
   
   Note 1: As part of the definition of likelihood / probability categories, the RMP can also establish criteria that can be used to apply practical distinction between conditions to be treated as risks and those that can be considered existing issues. Generally, a risk event can be considered to be an “issue” when its undesired consequences have already occurred, or are going to occur with very high likelihood if no remedial action is taken.
   
   Note 2: 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).
   
   
8. Reflects the overall programmatic risk posture by documenting risk acceptance 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 acceptance criterion" is a rule for determining whether a given organizational unit has the authority to decide to accept a risk.
   
   Note 2: The RMP required in 3.2.2i. delineates (refer to subparagraph (3)) a body of performance requirements to be met by the Provider. Risk acceptance criteria are formulated to allow the Provider 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.
   
   
9. Identifies stakeholders, such as Risk Review Boards and the information system Authorizing Official (for cybersecurity risk), to participate in coordinated deliberations regarding the disposition of risks.
10. 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. Also establishes guidance to make sure that communication between management levels and across the organization reflects any criteria established to distinguish “risks” from “issues,” especially when this is associated with different types of handling and assignment of order of priority.
    
    Note 1: This communication may be accomplished using standard reporting templates defined in the RMP, including risk matrices (and conditional risk matrices for intentional-action risks; see Note 2 below), whose formulation and interpretation are agreed between the affected units, recognizing that communication of risk from one level to another level (e.g., from project to program level) must be executed consistently with the risk classification criteria of the receiving organization, in order to support decision-making at that level.
    
    Note 2: In case of intentional-action risk scenarios, such as cybersecurity risk, conditional-risk matrices may be used, to communicate the risk level corresponding to a given type of intentional threat, if the latter is assumed to be present. This type of communication may be adopted when it is judged that a probability or frequency-based representation of the potential types of threat is not possible or meaningful.
    
    Note 3: 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 be manageable at the higher level, since the organizational unit at that level has more flexibility and authority.
    
    Note 4: For Center mission support and institutional organizations, protocols are particularly important for reporting risks to affected project units and vice versa.
    
    
11. 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, if applicable, the agreement of the Risk Takers’ responsible managers to assume the risk (refer to paragraph 3.5.3 for application of this form).
12. Establishes an interval for the periodic review of the assumptions on which risk acceptance decisions are based.
13. Delineates the processes for coordination of risk management activities and sharing of risk information with other affected organizational units and responsible authorities (e.g., the information system Authorizing Official for cybersecurity risk). This includes management of cross-cutting risks (risks affecting multiple organizational units), including risks affecting both programmatic and institutional organizations.
14. Documents the manager's signature, as well as:

1. 1. 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), and
   2. the concurrence of the cognizant Technical Authorities or other Institutional Authorities (e.g., Institutional Safety Authorities) that the Risk Management Plan meets the requirements of this NPR.

The following roles may be involved in creating the SDP/SMP:

• Software Lead Engineer.
• Test Team Lead. ⁴⁵³
• Software Engineers.
• Software Assurance Engineer (to coordinate assurance activities and schedule).
• Software Acquisition personnel.
• Users/customers.
• Software Configuration Management Engineer.
• System Engineer.

The content of the SDP/SMP is the recommended minimum content; additional content may be included as appropriate for the project. This content may be entirely captured in the SDP/SMP, or it may be captured in the SDP/SMP and some number of other plans. When other plans capture any of the recommended SDP/SMP content, reference those plans in the SDP/SMP.

When developing an SDP/SMP, consider the following guidance for each of the minimum recommended elements of the plan:

3.1 Project organizational structure

Describe in text, graphics, or both the authority and responsibility of each unit of the organization having a role in the development of the software. Include both internal and external organizations relevant to the software development effort:

• Software Engineering.
• Organizational support, such as configuration management, verification and validation (V&V), training, metrics, process development.
• Hardware development and manufacturing.
• System Engineering.
• Safety and Mission Assurance.
• Independent Verification and Validation (IV&V).
• Software/Engineering Technical Authority.
• Subcontractors.
• Users.
• NASA Engineering and Safety Center.
• NASA Safety Center.

3.13 Approval required

Describe approvals required by the project for acceptance, operation, and maintenance activities, including regulatory approvals, required certifications, proprietary, usage, ownership, warranty, and licensing rights.

See also SWE-055 - Requirements Validation, 

3.14 Process for scheduling, tracking, and reporting

Describe how task scheduling, progress tracking, and reporting will be performed for this project. Include information such as:

• The "plan for tracking the progress and cost of the individual work elements in each WBS category using an approved method."
• A description of the use of Earned Value (EV) or similar technique, as applicable.
• A description of the lowest WBS where progress reporting will be performed and how those low-level progress values will be rolled up and reported.
• "Methods, tools, techniques used to estimate and periodically re-estimate project cost, schedule, and resource requirements."
• Basis of estimation.
• Triggers for re-estimation.
• Types of reports and frequency of reporting (to Mission project, Branch, division, etc.).

See also SWE-024 - Plan Tracking, 

3.22 Content of software documentation to be developed on the project

Provide content lists for the documents to be created as part of the project or a list of templates or standards governing and describing that content. This topic in the Handbook provides recommended content lists for several software documents. The content lists need not be incorporated in the SDP/SMP; they may be included by reference.

*Management, development, and testing approach for COTS (Commercial Off the Shelf), GOTS (Government Off the Shelf), MOTS (Modified Off the Shelf) , reused, open-source software component(s) that are included within a NASA system or subsystem*

Describe or reference processes specific to development, management, and testing of COTS, GOTS, MOTS, reused, or open-source software for this project. By their nature, these types of software present challenges because access may be limited to requirements, design, and testing documentation. Additionally, software stability, access and inclusion of updates and upgrades, and access to persons with critical knowledge of the software can present challenges not found in new software development.

Guidance for SWE-027 - Use of Commercial, Government, and Legacy Software in this Handbook also describes special considerations relative to these types of software and their inclusion in NASA projects.

Include plans for dealing with these challenges and considerations in the SDP/SMP, or include references to the project documents that address them.

3.24 Risk Management updates

Review at regular intervals, revise, and update the Risks to keep its content current.  Criteria that often trigger re-planning include:

• Significant changes in scope, schedule, or budget.
• Delay in receipt of key component or service that is externally supplied.
• Inability to meet a major milestone." ⁴⁵³

Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews provides guidance for the maintaining Records of Continuous Risk Management at various life cycle reviews.

3.25 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

4. Small Projects

Risk Management Plans are required for every project because they provide the overall view of how risks will be managed. Instead of writing a Risk Management Plan for each project, organizations may wish to write a generic plan that can be referenced and used by all projects. The organization could have one Risk Management Board that manages and tracks risks for all of its projects instead of having one for each.

5. Resources

5.1 References

5.2 Tools

5.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

5.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

6. Lessons Learned

6.1 NASA Lessons Learned

• No Lessons Learned have currently been identified for this plan.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this plan.