GPR 7120.4 Updated.pdf

DIRECTIVE NO. GPR 7120.4D APPROVED BY Signature: Original Signed By

EFFECTIVE DATE: August 9, 2012 NAME: Judith N. Bruner

EXPIRATION DATE: August 9, 2022 TITLE: Director, Safety and Mission Assurance

CHECK THE GSFC DIRECTIVES MANAGEMENT SYSTEM AT

http://gdms.gsfc.nasa.govTO VERIFY THAT THIS IS THE CORRECT VERSION PRIOR TO USE.

08/16

Goddard Procedural Requirements (GPR)

COMPLIANCE IS MANDATORY

Responsible Office: Code 300/Safety and Mission Assurance Directorate

Title: Risk Management

TABLE OF CONTENTS

PREFACE

P.1 PURPOSE

P.2 APPLICABILITY

P.3 AUTHORITIES

P.4 APPLICABLE DOCUMENTS

P.5 CANCELLATION

P.6 SAFETY

P.7 TRAINING

P.8 RECORDS

P.9 MEASUREMENT/VERIFICATION

PROCEDURES

CHAPTER 1: GSFC RISK MANAGEMENT

1.1 Overview

1.2 Potential Risk Areas

CHAPTER 2: ROLES AND RESPONSIBILITIES

2.1 Safety and Mission Assurance (SMA) Director

2.2 Center Integrated Risk Manager

2.3 Directorates, Code 100 Offices, and Programs/Projects

2.4 Directorate and Code 100 Office Risk Point of Contact

CHAPTER 3: PROCEDURE

3.1 Risk Identification

3.2 Risk Analysis

3.3 Risk Documentation

3.4 Planning (Handling Strategy)

DIRECTIVE NO.

GPR 7120.4D

EFFECTIVE DATE: August 9, 2012

EXPIRATION DATE: August 9, 2022

08/16

3.5 Risk Tracking

3.6 Risk Control

3.7 Reports and Recommendations

3.8 Process for Handling Dissenting Opinions

CHAPTER 4: REQUIREMENTS

4.1 Risk Management Process Requirements

Appendix A – Definitions

Appendix B – Acronyms

Appendix C – GSFC Risk Scorecards and Risk Reporting Examples

Appendix D – Reference Documents

LIST OF FIGURES

Figure 1, RIDM-CRM Risk Management Process Flow Figure 2, GSFC Risk Management Hierarchy

Figure 3, GSFC Risk Matrix Standard Scale ............................................ Error! Bookmark not defined.

Figure 4, GSFC Risk Matrix Standard Scale Instructions

Figure 5, Institutional Risk Scorecard Figure 6, Integration of RIDM/CRM Process Figure 7, Top Risk List Chart Example Figure 8, Risk Closure Report Example Figure 9, Risk Matrix to Waterfall Translation Example

Figure 10, Risk Focus Chart Example

PREFACE

P.1 PURPOSE

This GPR establishes risk management requirements and procedures at the Goddard Space Flight Center

(GSFC).

P.2 APPLICABILITY

a. Risk management procedures shall be applied to space flight programs and projects, ground system programs and projects, institutional projects, and organizations.

b. The risk management requirements defined in this GPR apply to suborbital programs and projects

(e.g., sounding rockets, balloons, aircraft, cubesats, and small ISS payloads) as required by NPR

7120.8 and at a level of rigor commensurate with the cost and complexity and risk acceptance posture of the project. The flow down of NPR 8000.4 requirements for Suborbital Programs and

Projects shall be documented in Project Risk Management Plans and implemented at a level commensurate with the cost, complexity, and risk of the suborbital mission.

c. In this directive, all document citations are assumed to be the latest version unless otherwise noted.

d. In this directive, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall.” The terms “may” or “can” denote discretionary privilege or permission; “should” denotes a good practice and is recommended but not required; “will” denotes expected outcome; and

“are/is” denotes descriptive material.

P.3 AUTHORITY

a. NPD 7120.4, Program/Project Management

b. NPR 8000.4, Agency Risk Management Procedural Requirements

P.4 APPLICABLE DOCUMENTS AND FORMS

a. NPD 1000.5, Policy for National Aeronautics and Space Administration (NASA) Acquisition

b. NPR 7120.5, NASA Space Flight Program and Project Management Requirements

c. NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project

Management Requirements

d. 200-PG-8000.0.1, Risk Management Plan

P.5 CANCELLATION

GPR 7120.4C, Risk Management

GSFC-STD-0002, Risk Management Reporting http://nodis3.gsfc.nasa.gov/lib_docs.cfm?range=7___

P.6 SAFETY

None

P.7 TRAINING

Personnel who are responsible for risk management activities shall be trained in Risk Management

(RM), including Continuous Risk Management (CRM) and Risk-Informed Decision Making (RIDM).

P.8 RECORDS

Record Title Record Custodian Retention

Risk Management Plans Program, Project, or

Organization

*NRRS 8/103 – Temporary

Destroy/delete between 5 and 30 years after program/project termination.

Program/Project Level Risk Data Program, Project, or

Organization

*NRRS 8/101 - Permanent. Cut off records at close of program/project or in 3-year blocks for long term program/projects. Transfer to records center storage. Transfer to National

Archives 7 years after cutoff.

*NRRS – NASA Records Retention Schedules (NRRS 1441.1)

P.9 MEASUREMENT/VERIFICATION

The GSFC programs and projects shall keep metrics such as number of open and closed risks, number of accepted (residual) risks, when the risk was open, estimated completion date for the risk.

http://nodis3.gsfc.nasa.gov/library/lib_docs.cfm?range=1___

PROCEDURES

CHAPTER 1: RISK MANAGEMENT

1.1 Overview

a. Risk Management is a deliberative, systematic process to analyze and communicate the risk of performance shortfalls. This process involves development of risk handling and mitigation options, and implementation of approved strategies to reduce or eliminate the likelihood of occurrence and/or severity of consequence.

b. The overall Risk Management process includes two key components that are used iteratively: RIDM and CRM. The RIDM component supports decision-making at each management tier by applying quantitative and qualitative risk information. Then, CRM is applied to facilitate implementation of the mitigation.

c. This approach is consistent with the Agency risk management procedures; and will provide insight to address technical, management, and business challenges and opportunities at the Center.

1.1.1 Risk-Informed Decision Making

a. As prescribed by the Agency Risk Management Procedural Requirements (NPR 8000.4), when a risk is identified, initiate the risk management process to formulate a mitigation strategy using the following steps:

(1) Identify decision alternatives: Consider challenges and opportunities based on stated objectives.

(2) Analyze alternatives: Apply subject matter expertise across disciplines as needed to bound risk scenarios; integrate all key drivers and impacts, and consider performance measures.

(3) Select an option: After a deliberative review informed by risk analysis results, select a decision alternative and develop risk mitigation strategies.

b. This approach is particularly useful when a threat entails high stakes, complexity, uncertainty, multiple attributes or competing objectives, or a diverse range of stakeholders (refer to section 3 for more details).

1.1.2 Continuous Risk Management

a. As prescribed by NPR 8000.4, implement the mitigation strategy using the following key steps

(refer to section 3 for more details):

(1) Identify: State the risk in terms of an existing condition that may lead to degraded performance; and capture the risk context, including key drivers.

08/16

(2) Analyze: Perform quantitative/qualitative assessments to determine risk likelihood

(probability) and severity of consequences (impact of degraded performance). Consider the timeframe for action. Consider grouping with similar or related risks, and prioritize.

(3) Plan: Assign a risk owner and develop a mitigation plan (handling strategy). The level of mitigation should be commensurate with the threat complexity and the end-goal of this document.

(4) Track: Acquire/update, compile, analyze, and organize risk data; and report tracking results. Verify and validate mitigation actions over time.

(5) Control: Analyze tracking results, and decide how to proceed (e.g., re-plan, close the risk, invoke contingency plans, or watch). Execute the risk control decisions.

(6) Communicate and Document: Report status and request direction or concurrence at the appropriate decision level. Document supporting information to track details, plans, progress, and risk decisions.

b. Application of RIDM and CRM uses an approach that says the level of risk mitigation and prioritization should be commensurate with the complexity of the risk or severity of consequence if a risk is realized. These factors dictate the rigor applied to make a risk-informed decision

(Figure 1).

Figure 1, RIDM-CRM Risk Management Process Flow

Understand

Performance

Criteria

Identify

Alternatives

Analyze

Alternatives

Deliberate and

Decide

Implement

Decision

Track and Control

Implementation

1.2 Potential Risk Areas

1.2.1 Potential adverse impacts constitute GSFC risks. The following are examples of areas where risks are identified:

a. Budget/Finance

b. Infrastructure – Workforce, Facilities, Information Technology

c. Health, Safety and Environment (HSE)

d. Program/project

e. Acquisition

f. Agreements & Commitments (internal/external stakeholders)

g. Outreach

h. Transition

i. Knowledge Capture and Retention

CHAPTER 2: ROLES AND RESPONSIBILITIES

2.1 Safety and Mission Assurance (SMA) Director

The SMA Director shall:

a. Approve the Center risk management procedure

b. Appoint the Center Integrated Risk Manager

2.2 Center Integrated Risk Manager

The Integrated Risk Manager shall:

a. Serve as the point of contact for Center risk management activities, procedures, and processes

b. Develop Center risk management procedures

c. Ensure that risk management plans are developed, approved, and implemented

d. Concur with risk management plans for directorates, Code 100 Offices, and Programs/Projects

e. Report integrated risk management findings to the SMA Director and to the GSFC Management

Committee on a regular basis

2.3 Directorates, Code 100 Offices, and Programs/Projects

Directorates, Code 100 Offices, and Programs/Projects shall:

a. Develop and implement a risk management plan

b. Assign a point of contact for risk management

c. Inform Center management of significant risks

2.4 Directorate and Code 100 Office Risk Point of Contact (POC)

The Risk POC shall perform:

a. Ensure development, approval, and implementation of a risk plan

b. Assist personnel in developing risk information

c. Facilitate discussions related to risk formulation, tracking, and retirement

d. Facilitate development of a risk list and inform Center management

e. Ensure implementation of appropriate risk management training

Note: requirement is to assure that the function is performed, not to constrain how the project manager assigns responsibilities.

CHAPTER 3: PROCEDURE

Risk is a potential threat with sufficient information to indicate a negative consequence when measured against a safety, technical, cost or schedule performance objective. Risk is also the potential inability to fully implement agreements with NASA stakeholders or partners (commercial, governmental, or international). Resolution requires focused management attention.

3.1 Risk Identification

Risk management begins with identification of a perceived shortfall against a performance objective, including key drivers and impacts.

3.1.1 Risk identification is a continuous effort to capture, acknowledge and document potential risks as they are found based on a condition; event; or review of requirements, products, and services needed to execute a planned mission. Emphasis is on early identification of potential risks related to: HSE, Technical

Performance, Center capabilities (infrastructure, personnel), and cost or schedule threats. Risks also may be identified when implementing corrective or preventative actions.

3.1.2 Examples of key considerations for risk include:

a. Funding requirements and priority: Likelihood of budget shortfall and rationale, impact if not funded (e.g., reduced scope, impact to internal/external stakeholders), risk buy-down that would be achieved with full or incremental funding.

b. Cross-cutting risks: A risk-owning organization has primary impact but based on potential risk handling/disposition and mitigation timeframe, consequences also may impact one or more

NASA organizations or external stakeholders.

c. Center capabilities: Infrastructure and resources as required for achievement of institutional objectives and Program/Project support requirements.

d. Transition planning: Requirements for changing Agency or Center conditions or objectives.

3.1.3 An identified risk shall be documented in a risk statement in the following format: “Given the

[condition], there is a possibility that [consequence] will occur with the result that [outcome].” The condition must be a fact, short and concise.

08/16

3.1.4 A candidate risk with information that is insufficient or immature to analyze or define mitigation options may be captured as a Concern in project database. Concerns may be managed internally within existing resources and processes. The concern may be elevated to a risk and then to the next higher level as needed.

3.2 Risk Analysis

3.2.1 Risks shall be analyzed to determine likelihood of occurrence and impact to the performance objective. In accordance with RIDM-CRM principles (NPR 8000.4), the risk analysis steps are as follows:

a. Evaluate risk data. Identify and understand the impact from each risk contributor, including the uncertainty inherent in each.

b. Perform quantitative and/or qualitative analysis. Assess risk consequences (degraded performance, loss of function, key milestone slip, personal injury, cost escalation, etc.).

(1) Quantitative risk analyses are preferred and shall be applied to the maximum extent practical.

Use of quantified analysis is based on scope of the decision to be made and similarities among suitable alternatives (graded approach)

(2) Select one or more analysis methodologies for each consequence, for example:

(a) Analysis of historical data (similarity)

(b) Probabilistic Risk Assessments or other quantitative analyses

(c) Maintenance/Repair/Replacement (MRR) cost estimates.

c. Determine the risk of cost impact. Identify all constraints and thresholds (For more details see

Section 3.2.2).

(1) Include the cost threat for all applicable fiscal years.-

(2) Constrain assessment of risk consequences to the current Planning, Programming, Budgeting and Execution (PPBE) period, to provide a consistent frame of reference.

d. Determine risk likelihood and consequences. Map risk assessment results to the descriptions listed on the GSFC Risk Scorecard (Appendix C).

e. Communicate the risk. In the appropriate management forum, the risk owner shall periodically review and update risk status, validate new concerns, review progress of mitigation plans, and determine if any risks require escalation to the next level, remains unchanged and/or changed to lower level. At the Center-level, risks will be reviewed monthly, alternating between internal reviews with the Center Managers and reviews with the full GSFC Management Council (GMC).

f. Document expected likelihood and consequences in the project level risk list, risk database or risk tracking tool.

3.2.2 Impact of Liens, Threats, and Encumbrances on Budget Contingency

Risks are a key element in understanding the potential cost liabilities that a program or project may incur. The purpose of this section is to establish the method for determining the potential cost impact associated with risks. This section provides definitions for the terms to categorize the real and potential reductions to budget contingency, and the requirements for calculating and applying them for budgeting and reporting purposes. The intent is to provide a more realistic reflection of potential project cost growth.

Whether a risk is a threat or a lien – and the magnitude of its calculated cost impact – depends on its placement on the 5x5 risk matrix. Risks having cost or schedule impacts shall be reported and shown against contingency levels as part of budget submissions and Monthly Status Reviews (MSR).

Situations or circumstances that have either already occurred or are inevitable regardless of risk management strategy shall be identified as issues, not as risks.

a. Threat, Lien, and Encumbrance Definitions:

(1) Threats are all risks (red, yellow, and green) with a likelihood (L) of 2, 3 or 4 that have potential cost impacts.

(2) Liens are all risks with a likelihood, L=5, or issues, that have potential cost impacts (liens are usually realized, at least in part).

(3) Encumbrances are issues/risks that are fully realized and have a final cost impact.

There may be unusual circumstances where a lien or threat is not associated with a risk, but, in general, all threats and liens should result from risks.

b. Threat, Lien, and Encumbrance Calculations:

(1) Threats shall be calculated and budgeted based on an assessment of likelihood, consistent with placement on the risk matrix, according to the following:

Expected Value of the Threat = Probability (P) x Estimated Cost Impact.

P = 20% for L of 2 (Low)

P = 40% for L of 3 (Moderate)

P = 60% for L of 4 (High)

Lien for L of 5 (very high)

(2) Liens shall be calculated and budgeted at 100% of the estimated cost impact

(3) Encumbrances shall be budgeted at 100% of the final cost impact.

3.3 Risk Documentation

3.3.1 As risks are identified and mitigation strategies developed, the Risk POC shall document the risk with the following information:

a. Risk Title

b. Risk Owner

c. Risk Statement

d. Likelihood x Consequence (LxC) Score and Rationale

e. Risk Description (context)

f. Impact/Consequences

08/16

g. Estimated Completion Date (ECD) and criteria for risk closure or acceptance

h. Current Status

i. Handling Strategy and task mitigation steps with ECD

j. Cost impact, if known.

3.4 Planning (Handling Strategy)

3.4.1 The Risk POC is responsible to ensure that the plan of action for each risk, referred to as the handling strategy. Pairing likelihood of occurrence with the highest impact rating yields a relative characterization of severity, a key consideration when selecting a strategy:

a. High Risk – Expected to occur with severe impacts, if realized; denoted in the upper right-hand (red) region of the GSFC Risk Scorecard.

b. Moderate Risk – May occur and impacts would be significant, but not catastrophic; denoted in the middle (yellow) region of the Risk Scorecard.

c. Low Risk – Not likely to occur or potential impacts are not expected to be significant; denoted in the lower left-hand (green) region of the Risk Scorecard.

3.4.2 Options for Handling Strategy

The intent of a handling strategy is to minimize the LxC over time. However, the option to “Do

Nothing” should be addressed first. Then, the preferred strategy and supporting data are approved at the appropriate management level. Options include:

a. Research – Consider and review all pertinent information sources to understand the risk.

b. Mitigate – If “do nothing” is not acceptable, develop a mitigation strategy to measurably reduce the

LxC. Specify the mitigation ECDs, resulting LxC score and rationale, and success criteria.

c. Watch – For risks where circumstances do not warrant immediate mitigation steps, define triggers that indicate the need for action. Include a timeframe for re-evaluation and active mitigation or alternate handling strategies.

d. Accept – If further mitigation is not cost-effective and no further resources will be expended to mitigate residual risk, a risk owner may recommend ceasing active mitigation with key assumptions and conditions on which the decision to accept will be based. To accept a risk, rationale must be approved by the owning organization and key stakeholders. Periodically assess for changing conditions.

3.4.3 Risk Escalation

Risk owners shall perform due diligence to understand the risk scoring rationale, ranking, and escalation. The Project Manager and Risk Manager determine if a risk requires escalation to the next level. Reasons for escalation may include:

a. Additional resources are needed to mitigate the risk.

b. Direction is needed from the next level of management.

08/16

c. External integration is required (for example, with other programs/projects/centers).

d. The risk has cross-cutting significance.

Escalation shall reflect the hierarchical level of insight or control of resources needed to handle the risk.

The risk escalation process is iterative to accommodate changes to a risk throughout its life-cycle.

Each successive tier in the organization shall review its risks on a periodic basis (Figure 2). The following levels are defined to support the Center’s escalation process:

a. Top Center Problems/Issues – Requires Center management resources or direction to resolve; could have cross-cutting impacts that affect two or more GSFC organizations.

b. Top Directorate Risk (TDR) – Requires Directorate Management direction and/or resources to resolve; affects one or more divisions within the Directorate.

c. Top Organizational Risk (TOR) – Requires Division Management direction and/or resources to resolve; affects one or more sub-organizations.

Figure 2, GSFC Risk Management Hierarchy

To escalate or de-escalate, the risk is assessed by the Risk POC that a valid reason exists for the proposed change. The proposed risk is presented to appropriate management level for approval of content, resource requirements, and priority ranking. The Risk POC changes the risk level designation in GSFC database. As escalated, risk scores may change to reflect the significance of the impact at the next level.

Center Director

GSFC

Directorate

Division Chiefs

Branch Management and Team Leaders

Risks Resources, Directions

GSFC Management Council

Directorate Risk Review

Division Level Risk Review

Branch Level Risk Review

08/16

For Center organizations with Top Program Risks (TPRs) requiring Program Management direction and resources to resolve, escalate risks via the program’s risk review process. Coordinate any cross-cutting risks with all affected Center organizations.

3.5 Risk Tracking

3.5.1 The risk owner shall track risk attributes over the risk life-cycle to determine if: 1) mitigation steps are performed in a timely manner and 2) steps taken are effectively managing the risk. The owner tracks observable data related to performance measures such as cost/schedule variance or changing conditions.

3.5.2 The Risk Managers track and update risks on a recurring basis to reflect current status and progress, and use the results to communicate risk status and information (quantitative or qualitative) as required for effective control and management decisions.

3.6 Risk Control

Risks are a key input to the Risk Control process and reflect specific challenges to meeting commitments.

Recommendations for resource allocation take into consideration the trade-offs between finite resources and prioritized risks. Collaboration with GSFC organizations is essential for incorporating risk management into the Center Management decision-making process.

3.6.1 The risk control function is to assess and verify that the mitigation plan is effectively reducing the LxC threat. Based on analysis of tracking data, types of control decisions may include:

a. Continue as planned – Progress is satisfactory (as expected).

b. Re-plan – Mitigation is not achieving the desired outcome or conditions have changed.

c. Invoke a contingency plan – If the current plan proves inadequate, an alternative is developed, approved, and implemented.

d. Close – To close a risk, rationale must be approved at the appropriate management level to demonstrate that the risk has been eliminated; residual risk is negligible such that further steps are unnecessary; or the threat has been subsumed by a new risk.

e. Transfer – To re-allocate the risk to an organization that is better suited to handle the risk mitigation processes which are mutually agreed upon by the affected parties.

3.7 Reports and Recommendations

Relevant risks recommended and prioritized as Top Center Problems/Issues or Proposed Top Center

Problems/Issues are reviewed at GSFC Management Forums such as MSR. Summary reports are generated and presented based on risk information in the Program/Project risk database or equivalent.

Recommendations may derive from related Center, Directorate, and Program/Project risk review forums.

3.8 Process for Handling Dissenting Opinions

Resolution for dissenting opinions of any nature (e.g., programmatic, safety, engineering, acquisition, accounting, etc.) are handled in accordance with NPR 7120.5, Section 3.3 when an individual deems it to be of sufficient importance to warrant a specific review and decision by higher-level management.

Elevation of a dissenting opinion is performed at the discretion of the dissenting party.

CHAPTER 4: REQUIREMENTS

4.1 Risk Management Process Requirements

4.1.1 The Project Manager (PM) shall implement a systems management approach that formalizes and integrates the RM process throughout the system life cycle. All elements of the system shall be addressed (e.g., flight, ground and launch vehicle segments, hardware and software, critical ground support equipment). All phases of the life cycle shall be considered (concept through decommissioning).

This implementation shall include the use of tools and methodologies such as Failure Modes and

Effects Analysis (FMEA), Fault Tree Analysis (FTA) and Probabilistic Risk Assessment (PRA) to support the qualitative and quantitative assessment of risk inherent in the system design and associated development and operations activities to:

a. Evaluate alternative design concepts, redundancy and cross-strapping approaches, and part substitutions.

b. Identify the elements of the design that are the greatest detractors of system reliability.

c. Identify those potential mission limiting elements and components that will require special attention in part selection, testing, environmental isolation, and/or special operations.

d. Assist in evaluating the ability of the design to achieve the mission life requirement and other reliability goals and requirements as applicable.

e. Evaluate the impact of proposed engineering change and waiver requests on reliability.

The results of these risk assessments shall be used to support project management decisions with respect to safety and mission success, and programmatic commitments.

4.1.2 The PM shall incorporate the requirements of the Risk-Based Acquisition Management (R-

BAM) initiative as part of the RM process (refer Appendix D). The purpose of R-BAM is to convey

NASA’s focus on safety and mission success to NASA contractors.

4.1.3 The PM shall document project-specific implementation of the CRM + RIDM process in the

Project/Program Risk Management Plan (RMP). The RMP shall be reviewed by the Chief Safety and

Mission Assurance Officer (CSO) and Mission Systems Engineer (MSE) (for flight projects), approved by the PM, and concurred by the Safety and Mission Assurance Director or designee. The RMP shall be

08/16 developed, approved, and implemented early in project formulation, no later than the mid-point of the planned formulation period and prior to any mid-formulation review gates imposed by the funding

Mission Directorate (i.e., Science Mission Directorate Initial Confirmation Review). The RMP is a controlled document and shall be maintained by the PM throughout the project life cycle.

The RMP shall include:

a. Introduction - Specify the project risk objectives and policy toward risk. Explain the purpose, scope, assumptions, constraints, key ground rules, and policy pertaining to the project CRM process.

Overview of process - Provide an overview of the CRM process and information flow; describe how the CRM process integrates and relates to other project management and system engineering activities. Include general risk mitigation strategies to be employed throughout project life cycle.

b. Organization - Show the organization, roles, and responsibilities of program, project, customer, and supplier key personnel with regard to CRM. Document how team members will be trained in the application of CRM methodology.

c. Process details - Provide the CRM + RIDM process details and related procedures, methods, tools, and metrics. Include here, or in an appendix, the specific methodologies to be used for risk identification, analysis, planning, tracking, and controlling. Include the process to be used for continual assessment of the project risk profile. Describe how risk information will be communicated both internally to the project staff and throughout the NASA management chain.

Document the use of PRA and/or similar techniques in the project systems engineering process.

d. Documentation of risks - Specify the format and data elements that will make up the project Risk

List, how configuration control will be applied, and how the list will be used and updated. Tell how team members will be able to access the current list at any time. Include in the RMP the initial set of identified risks and the action plan (for research, acceptance, tracking, or mitigation) for each risk.

4.1.4 The PM shall provide CRM training early in project formulation to the project team, including major partners and suppliers, as defined in the RMP. CRM training is available to PMs and other project systems management personnel designated by the PM from the Safety and Mission Assurance

Directorate and the Headquarters Chief Safety and Mission Assurance Officer.

4.1.5 The PM shall ensure that accepted risks/residual risks are linked to the results of the

FMEA/Critical Items List (CIL), FTA, and PRA where applicable.

4.1.6 The PM shall report the results of FMEA’s, FTA’s, and any numerical reliability assessments or predictions at system-level critical milestone reviews. The presentations shall include descriptions of how the analysis was used to perform design trade-offs and how the results were taken into consideration when making design or risk management decisions.

4.1.7 The PM shall maintain a Risk list throughout the project life cycle, along with programmatic impacts. The list shall indicate which risks have the highest probability, which risks have the highest

08/16 consequences, and which risks represent the greatest risk to mission success. The list shall also identify actions being taken to address each specific risk. The Risk list is a controlled document.

4.1.8 The PM shall communicate risk status on a regular basis to the project team and customers appropriately. Risk status shall be communicated to the Program Management Council (PMC) through the MSR.

4.1.9 For each primary risk (those having both high probability and high impact/severity), the PM develops and maintains the following information, where applicable:

a. Description of the risk, including primary causes and contributors, actions embedded in the program/project to date to reduce or control it, and information collected for tracking purposes.

b. Primary consequences, should the undesired event occur.

c. Estimate of the probability (qualitative or quantitative) of occurrence together with the uncertainty of the estimate. The probability of occurrence shall take into account the effectiveness of any implemented risk mitigation measures.

d. Potential additional mitigation measures, including a cost comparison, which addresses the probability of occurrence multiplied by the cost of occurrence versus the cost of risk mitigation.

e. Characterization of the risk as “acceptable” or “unacceptable” with supporting rationale.

Characterization of a primary risk as “acceptable” shall be supported by the rationale, with the concurrence of the PMC, that all reasonable mitigation options (within cost, schedule, and technical constraints) have been instituted.

f. Risk reporting (see examples in Appendix C, Figures 7 through 10).

Appendix A – Definitions

A.1 Acceptable Risk - Acceptable risk is the risk that is understood and agreed to by the program/project, Governing Program Management Council (GPMC), Enterprise and other customer(s) sufficient to achieve the defined success criteria within the approved level of resources.

A.2 Analysis of Risk - An evaluation of all identified risks either qualitatively and/or quantitatively to estimate the likelihood of occurrence, consequence of occurrence, timeframe when mitigation actions are needed, classification into sets of related risks, and priority ranking.

A.3 Concern - A candidate risk with insufficient or immature information to analyze or define mitigation options.

A.4 Center Management Council - The body of GSFC center management, Program Management representatives, and Directors which serves as a governing body over activities at GSFC.

A.5 Failure Modes and Effects Analysis (FMEA) - A Failure Modes and Effects Analysis is a procedure by which each potential failure mode of each element of a system is analyzed to determine the effects of the failure mode on the system and to classify each potential failure mode according to the severity of the effects.

A.6 Fault Tree Analysis (FTA) - A Fault Tree Analysis is a qualitative technique to uncover credible ways that a top event (undesired) can occur. The results of the FTA are documented in a fault tree, which is a graphical representation of the combination of faults that will result in the occurrence of an undesired top event.

A.7 Issue - An event or incident that is impacting the organization which may be a risk that has been realized or identified.

A.8 Primary Risk - A Primary Risk is a risk that is assessed as both a high probability and high impact/severity.

A.9 Probabilistic Risk Assessment (PRA) - Probabilistic Risk Assessment is a rigorous technical discipline used in complex technological applications to reveal design, operation and maintenance vulnerabilities, to enhance safety and to reduce costs.

A.10 Residual Risk - Residual risk is the remaining risk that exists after all mitigation actions have been implemented and/or exhausted in accordance with the RM process.

A.11 Risk - The combination of a) the probability (qualitative or quantitative) that an organization will experience an undesired event such as cost overrun, schedule slippage, safety mishap, or failure to achieve a needed technological breakthrough; and b) the consequences, impact, or severity of the undesired event were it to occur.

A.12 Risk Acceptance - Determination that the consequences of an identified risk, should they occur, are acceptable without further mitigation. No further resources are expended in managing this risk except periodic review (every six months) to ensure assumptions or circumstances have not changed.

A.13 Risk Assessment - Determination of perceived acceptability or severity of a risk following analysis of the risk (e.g., analysis indicates a schedule slip of 1 week; assessment determines if a

1 week slip is acceptable or catastrophic)

A.14 Risk-Based Acquisition Management - Risk-Based Acquisition Management (RBAM) is a management initiative to apply CRM earlier and throughout the acquisition process (i.e., 08/16 requirements development, acquisition planning, Request For Proposal development/solicitation, source selection, and post-award acquisition management).

A.15 Risk Control - An activity that utilizes the status and tracking information to make a decision about a risk or risk mitigation effort, including resource allocation. Risk control is comprised of four decisions; continue as planned, re-plan, invoke a contingency plan, or close the risk.

A.16 Risk Elevation - The process of increasing the visibility of a concern to a risk.

A.17 Risk Escalation - The process of raising risk visibility by reporting the risk to a higher level in the organization. This is done either to raise the awareness and visibility of a risk, calling attention to adverse changes in consequence, likelihood of occurrence or timeframe, or to request resources that are not available to handle the risk at the lower level. Risks are escalated to one or more levels above the level at which it is owned and mitigated.

A.18 Risk Escalation Level - Levels of escalation include: Top Center Problems/Issues, Top

Directorate Risk (TDR), Top Organizational Risk (TOR) - (i.e. divisions and offices into which directorates are subdivided).

A.19 Risk Identification - A continuous effort to capture, acknowledge and document risks as they are found.

A.20 Risk List - The Risk List is the listing of all identified risks in priority order from highest to lowest risk, together with the information that is needed to manage each risk and document its evolution over the course of the project.

A.21 Risk Management (RM) - RM is an organized, systematic decision making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving goals. RM is performed continuously which is an essential element and an integral part of NASA project management and system engineering.

A.22 Risk Mitigation - The elimination or reduction of an identified risk by reducing the consequences, likelihood, or by delaying the projected time of occurrence (i.e. to allow time to mitigate, or beyond time which impacts the tasks being performed).

A.23 Risk Owner - Identifies, implements, and tracks the risk mitigation approach and actions (the focal point for integrating all the risk information and ensuring adequate management and closure). The risk owner has the necessary resources (budget and workforce) required to mitigate the risk, either by delegation or routine operations.

A.24 Risk Planning (Handling Strategy) - Establishes the proper course of action for dealing with a particular risk. Resulting actions are to watch, accept, research, or mitigate.

A.25 Risk Tracking - An activity to capture, compile, and report risk attributes and metrics which determine whether or not risks are being mitigated effectively and whether risk mitigation plans are being implemented correctly.

A.26 Success Criteria - The minimum set of measures that establish the accomplishment of predefined goals and objectives for a given activity or undertaking. Within the practice of risk management it usually refers to the establishment of goals and objectives for risk mitigation activities.

A.27 Transfer - The act of allocating authority, responsibility, and accountability for a risk to another person or organization.

A.28 Validate Risk - The process of examining an identified concern to verify that it has been written in such a way as to allow further analysis and those mitigation actions are within the scope of the program or initiative in question.

08/16

A.29 Watch - The monitoring of an identified risk and its attributes for early warning of critical changes in consequences, likelihood, timeframe, or other indications that might reveal a risk event is imminent.

Appendix B – Acronyms

CIL Critical Items List

CMO Center Management and Operations

CRM Continuous Risk Management

CSO Chief Safety and Mission Assurance Officer

ECD Estimated Completion Date

FAR Federal Acquisition Regulations

FMEA Failure Modes and Effects Analysis

FTA Fault Tree Analysis

HSE Health, Safety and Environment

GMC GSFC Management Council

GPMC Governing Program Management Council

GPR Goddard Procedural Requirements

GSFC Goddard Space Flight Center

MOA Mission Operations Assurance

MSR Monthly Status Review

MRR Maintenance, Repair and Replacement

MSE Mission Systems Engineer

NASA National Aeronautics and Space Administration

NFS NASA Federal Acquisition Regulation Supplement

NPD NASA Policy Directive

NPR NASA Procedural Requirements

PM Project Manager

PMC Program Management Council

POC Point of Contact

PPBE Planning, Programming, Budgeting, and Execution

PRA Probabilistic Risk Assessment

R-BAM Risk-Based Acquisition Management

RIDM Risk-Informed Decision Making

RM Risk Management

RMP Risk Management Plan

SMA Safety and Mission Assurance

TDR Top Directorate Risk

TOR Top Organizational Risk

TPR Top Program Risk

08/16

Appendix C – GSFC Risk Scorecards and Risk Reporting Examples

A risk criticality of high, medium, or low is assigned to each risk using the Goddard risk matrix standard scale, Figures 3 and the instructions for the use of the scale are provided in Figure 4. In addition, Figure

5 shows Institutional Risk Scorecard.

Figure 3, GSFC Risk Matrix Standard Scale

Likelihood

5 Very High

4 High

3 Moderate

2 Low

1 Very Low

Safety

Technical Cost Schedule Estimated likelihood of not meeting performance requirements

Estimated likelihood of Safety event occurrence

Estimated likelihood of not meeting cost or schedule commitment

Consequence Categories

LOW RISK

MODERATE

RISK

HIGH RISK

Risk

Safety

1 Very Low 2 Low 3 Moderate 4 High 5 Very High

Technical

Schedule

Cost

Negligible or not impact

Could cause the need for only minor first aid treatment

May cause minor injury or occupational illness or minor property damage

May cause severe injury or occupational illness or major property damage.

May cause death or permanently disabling injury or destruction of property.

No impact to full mission success criteria

Minor impact to full mission success criteria

Moderate impact to full mission success criteria. Minimum mission success criteria is achievable with margin

Minimum mission success criteria is not achievable

Major impact to full mission success criteria. Minimum mission success criteria is achievable

Negligible or no schedule impact

Minor impact to schedule milestones;

accommodates within reserves; no impact to critical path

Impact to schedule milestones;

accommodates within reserves; moderate impact to critical path

Major impact to schedule milestones; major impact to critical path

Cannot meet schedule and program milestones

<2% increase over allocated and negligible impact on reserve

Between 2% and 5% increase over allocated and can handle with reserve

Between 5% and 7% increase over allocated and cannot handle with reserve

Between 7% and 10% increase over allocated, and/or exceeds proper reserves

>10% increase over allocated, and/or can’t handle with reserves

(PSE > 10-1)

(10-2 < PSE ≤ 10-1)

(10-3 < PSE ≤ 10-2)

(10-5 < PSE ≤ 10-3)

(PT > 50%)

(25% < PT ≤ 50%)

(15% < PT ≤ 25%)

(2% < PT ≤ 15%)

(0.1% < PT ≤ 2%)

(PCS > 75%)

(50% < PCS ≤ 75%)

(25% < PCS ≤ 50%)

(2% < PCS ≤ 10%)

(10-6 < PSE ≤ 10-5)

(10% < PCS ≤ 25%)

Purpose: The Risk 5x5 is a qualitative tool used for executive level management reporting and independent assessment to communicate individual and composite risk in the context of mission success. This tool is not intended for rigorous risk assessment needs and should be used in conjunction with other analytical tools and risk analysis techniques for a complete understanding of any risk insight which may have implications over mission successes. Users should concentrate on and assess all the consequences of risk.

Likelihood Scale Explained (Estimated likelihood value P should be based on analytic techniques whenever possible.)

Safety: Use this scale specifically for safety related risk. The 5 groups of likelihood bins come directly from the NASA Safety

Manual NPR 8715.3. The specified probability ranges (or likelihood bins) are the likelihood that an identified hazardous event will occur. These types of events should result directly in safety impacts, either as a mishap, an incident or accident based on assessments of such factors as location, exposure in terms of cycles or hours of operation, and affected population.

Technical: This scale of likelihood bins is used for ranking technical type of risks, which are measured using different scales from safety risks. A technical risk issue or event is primarily measured based on the likelihood of occurrence of such an event in terms of not meeting required minimum technical performances of a mission, or drifting from a specified design and performance margin. Percentage values are used here to better indicate likelihood of any events of technical risk impact.

Cost/Schedule: This scale of likelihood bins is used for ranking any programmatic type of risks, such as Cost and Schedule.

These risks are measured similarly as technical risks except using a slightly different likelihood scale. A Cost or Schedule risk issue or event is primarily measured based on the likelihood of occurrence of any such events in terms of not meeting program budget constraints or schedule requirement. Percentage values are used here to better indicate likelihood of any events of Cost/Schedule risk impact.

Consequences Scale Explained Safety: Use this consequence scale to rank the severity levels of safety related risk consequences which result directly from occurrence of any hazardous events that have safety impact only.

Technical: Use this consequence scale to rank the severity levels of technical or mission performance related risk consequences that result directly from occurrence of any technical or mission operational events that have direct risk impact on meeting technical requirement or suffer from degraded design/operating margin or mission performance.

Cost/Schedule: Use this consequence scale to rank the severity levels of programmatic type of risks, such as Cost/Schedule related consequences, that result directly from occurrence of any events (either technical or programmatic) having direct risk impact on established Cost/Schedule requirements or degraded program performance, etc.

Figure 4, GSFC Risk Matrix Standard Scale Instructions

High risk – Generally unacceptable and needs concurrence of Center leadership or PMC attention

Moderate risk – Generally acceptable and needs concurrence of PMC

Low risk – No need for Center or PMC management attention

Figure 5, Institutional Risk Scorecard

Likelihood Rating

L I K E L I H O O D

Very Likely

Likely

Possible

Unlikely

Highly Unlikely

Expected to happen. Controls have minimum to no effect.

Likely to happen. Controls have significant limitations or uncertainties.

Could happen. Controls exist with some limitations or uncertainties.

Not expected to happen. Controls have minor limitations or uncertainties.

Extremely remote possibility that it will happen. Strong controls in place.

SEVERITY

Consequences Categories

Technical

Cost

Schedule

High – Mitigate, implement new processes, charge requirements, or re-baseline

Moderate – Manage/consider alternative processes, or Accept

Low – Manage within normal processes or close

Subcategories 1 2 3 4 5

Center Capabilities

HE,

(Health

Environment)

System, Facility

Environment

Performance

Infrastructure

Workforce

Organizational or CMO impact

Minor damage to asset

Minor or non-reportable hazard or incident

Minor impact to mission objectives or requirements

Minor impact or reduced effectiveness

Minor impact to human capital

<2% Budget increase or <$1M CMO threat

Minor milestone slip

Moderate impact or degraded performance

Moderate hazard or reported violation

Incomplete compliance with a key mission objective

Moderate impact or damage to infrastructure

Moderate impact to human capital

2 – 5 % Budget increase or $1M - $5M CMO threat

Moderate milestone slip:

Schedule margin available

Loss of non-critical asset

Significant violation; event requires immediate remediation

Non-compliance:

significant impact to mission

Significant damage to infrastructure or reduced support

Significant impact: loss of critical skill

5 – 10% Budget increase of $5M - $10M CMO threat

Project milestones slip: no impact to a critical path

Damage to critical asset

Noncompliance: Major impact on Center or Spaceflight operations

Mission delays or major impact to Center operations

Major violation: event causes temporary work stoppage

Major impact: loss of skill set

10 – 15% Budget increase of $10M- $60M CMO threat

Major milestone slip:

impact to a critical path

Loss of critical asset or emergency evacuation

Catastrophic hazard

Failure to meet mission objectives

Extended loss of critical capabilities

Loss of Core Competency

>15% Budget increase or >$60M CMO threat

Failure to meet critical milestones

Figure 6, Integration of RIDM/CRM Process

Definitions

Risk Management: An organized, systematic process to effectively identify and analyze the risk of performance shortfalls, develop mitigation, and implement approved mitigation strategies to reduce or eliminate risk likelihood and/or consequence. The RM process includes two key components: Risk-Informed Decision Making and Continuous Risk Management (see below).

Risk: A potential threat with negative consequence to safety, Center-controlled cost or schedule. Or mission objectives for which a resolution is unlikely without focused management attention, or potential inability to fully implement with NASA stakeholders or partners (commercial, governmental, international).

Top Center Risk: Requires Center Management resources or direction to resolve: could have cross-cutting impacts that affect two or more GSFC organizations Top Directorate Risk: Requires Directorate Management direction and/or resources to resolve: effects one or more Directorate organizations, or other organizations Top Organizational Risk: Requires Division Management direction and/or resources to resolve: effects on or more sub-organizations

Concern: A candidate risk with insufficient or immature information to analyze or define mitigation options.

Writing a Risk Statement

Given CONDITION CONSEQUENCE Resulting in

RM Process

There is a POSSIBILITY that, Risk-informed Decision Making (RIDM): to inform GSFC decision-making through use of quantitative and qualitative risk information to establish baseline performance requirements for mission support organizations, programs, and projects.

Continuous Risk Management (CRM): To manage risk associated with the implementation of baseline performance requirements

Understand

Performance

Criteria

Identify

Alternatives

Analyze

Alternatives

Deliberate and

Decide

Implement

Decision

Track and Control

Implementation

IMPACT

Figure 7, Top Risk List Chart Example

Top Risk List

Figure 7 is an example of a Risk List that presents a summary of the top risks for a program/project. Although a project may be tracking many risks, the risk matrix presented for management review typically includes the top ten. In the case of two or more risks have the same LxC value, the consequence takes precedence over Likelihood.

ID

Rank

LxC

Approach

Risk Title

Criticality

LxC

Trend

Approach

High

Med

Low

Decreasing (Improvising)

Increasing (Worsening)

Unchanged

New this month

M – Mitigate

W – Watch

R – Research

C – Close

A – Accept

MMS-78

MMS-75

MMS-81

MMS-76

MMS-68

M

Axial Boom Comm. Interference

Complete IRAS TRL 6 Test

HV801 High Voltage

Optocouplers

KTH Quality Assurance

Axial Boom Stability

Requirements

Figure 8,…