Helioseismic and Magnetic Imager for Solar Dynamics Observatory

Transcription

1 Helioseismic and Magnetic Imager for Solar Dynamics Observatory Concept Study Report Appendix G Risk Management Plan LMSAL-2H July 2003 Stanford University Hansen Experimental Physics Laboratory and Lockheed-Martin Solar and Astrophysics Laboratory

2 The cover of the NASA 1984 report "Probing the Depth of a Star: The Study of Solar Oscillations from Space" featured Hirschhorn's the Pomodoro Sphere. That report led to the helioseismic study of the global Sun. Pomodoro's Cube at Stanford symbolizes HMI data cubes for investigation of localized regions in the Sun.

3 Helioseismic & Magnetic Imager HMI 2H00075, Rev: - Date: 27 June 2003 Total Number of Pages: 24 Solar Dynamics Observatory Helioseismic & Magnetic Imager Risk Management Plan DRAFT Originated by: Approved by: Larry Springer Program Manager Edward McFeaters Mission Assurance Manager Prepared for: Under Contract: Prepared by: Stanford University Hansen Experimental Physics Laboratory Stanford, CA PY-2223 Lockheed Martin Space Systems Company Space & Strategic Missiles Advanced Technology Center CAGE Lockheed Martin Solar & Astrophysics Laboratory (LMSAL) 3251 Hanover Street, Palo Alto, CA

4 2H00075 Rev. - REVISION HISTORY DOCUMENT TITLE: Solar Dynamic Observatory Helioseismic & Magnetic Imager Risk Management Plan REVISION DATE PAGES AFFECTED DESCRIPTION Initial ALL Initial Release ii

5 2H00075 Rev. - CHAPTER 1. CHAPTER 2. CHAPTER 3. CHAPTER 4. TABLE OF CONTENTS INTRODUCTION BACKGROUND AND SCOPE APPLICABLE DOCUMENTS...4 RISK MANAGEMENT PROCESS OVERVIEW RISK MANAGEMENT INTEGRATION RISK MANAGEMENT PHILOSOPHY...6 HMI RISK MANAGEMENT ORGANIZATION AND RESPONSIBILITIES HMI PROGRAM RISK MANAGEMENT ORGANIZATION HMI PROGRAM RISK MANAGEMENT RESPONSIBILITES HMI RISK MANAGEMENT REVIEW BOARD...8 RISK MANAGEMENT PROCESS RISK MANAGEMENT FUNCTIONS...10 APPENDIX A ACRONYMS AND DEFINITIONS...12 APPENDIX B DETAILED PROCESS FOR RISK MANAGEMENT...15 B-1 GROUND RULES...15 B-2 GUIDELINES...16 B-3 IDENTIFYING RISKS...17 B-5 ANALYZING AND CLASSIFYING RISKS...18 B-6 RISK PLANNING...24 B-7 TRACKING AND CONTROL OF RISKS...26 iii

6 Chapter 1. Introduction 2H00075 Rev BACKGROUND AND SCOPE The Helioseismic & Magnetic Imager (HMI) Program, a major element of the Solar Dynamic Observatory (SDO) mission, is under the direction of Stanford University. Lockheed Martin Space Systems Company, Advanced Technology Center (LMSSC ATC) is developing the HMI, as a member of the HMI consortium under contract to Stanford University. The HMI Program includes the development of flight, non-flight, and Ground Support Equipment (GSE) hardware and software, as well as related documentation packages. The LMSSC ATC HMI Risk Management Plan (RMP) is based on guidelines established in the Solar Dynamics Observatory (SDO) Project Continuous Risk Management Plan, 464-SA-PLAN It has been tailored to the HMI program. Within this generic framework the RMP addresses the specific requirements planned for the phase B/C/D portion of the HMI Contract. Risk is characterized by the combination of the likelihood that the project will experience an undesired event and the consequences, impact, or severity of that undesired event should it occur. Risk Management (RM) is a continuous, iterative process to manage risk in order to achieve mission success. RM involves identifying, analyzing, planning, tracking, controlling, documenting, and communicating risks effectively. Continuous RM (CRM) begins in the formulation phase with an initial risk identification and development of a Risk Management Plan and continues through the execution phase with the disposition and tracking of existing and new risks. This process is fundamentally iterative and proactive and contains critical feedback loops to allow for the communication of risk at all levels (e.g., Program, Systems, Subsystem). HMI program management approaches to addressing one or more risks may be periodically revised depending on the degree of success of ongoing risk mitigation efforts or on the phase of the instrument This document establishes the RM Program for the HMI Program at LMSSC ATC. The HMI program utilizes CRM as a decision-support tool to ensure safety and to enable programmatic and technical success. Decisions are made based on an orderly RM effort that includes the identification, assessment, mitigation, and disposition of risks throughout the program s life cycle. Applying the CRM process also ensures that risk communication and documentation are maintained across the entire program. This plan establishes the process for managing risks during the formulation, design, implementation, test and operation of the entire HMI Instrument. The HMI consists of the Instrument and Ground Equipment, and their constituent elements, subsystems, functions, and operations. The scope of this plan also includes risks associated with the use of program financial resources, facilities, procedures, equipment and personnel that have been assigned to or are directly associated with the HMI program. The scope of risks addressed include individual and joint risks addressing technical, cost, and schedule impacts related to the: Successful design, development, manufacture, integration, test, delivery and launch support of the HMI. Performance and reliability of the HMI. Joint risks are considered risks related to such conditions as the use of dedicated facilities and resources at other NASA Centers, international agencies, or contractors that have entered into an agreement with the SDO Project or other NASA organizations in support of the SDO mission. Joint risks and proposed mitigations are considered the responsibility of NASA GSFC SDO Project Management and are tracked within the NASA GSFC SDO Project Risk Management database. 1.1 APPLICABLE DOCUMENTS To the extent referenced herein, applicable portions of the documents listed below form a part of this document. 464-SA-PLAN Solar Dynamics Observatory (SDO) Project Continuous Risk Management Plan 464-SA-PROC Solar Dynamics Observatory (SDO) Project Risk Identification Procedure 4

7 Chapter 2. Risk Management Process 2H00075 Rev OVERVIEW This section provides an overview of the Risk Management process and its relation to HMI program management. As stated, the CRM process begins with the development of this plan, in which the general Risk Management paradigms are tailored to the HMI program. The HMI CRM approach considers Risk Management and Risk Elevation. The Risk Management approach contained in this document is based on the CRM activities defined in NPG Risk Management Procedures and Guidelines. As illustrated in Figure 2-1, the following activities are performed in the Continuous Risk Management process: Identifying Risks: A continuous effort to identify and document risks as they are found Analyzing Risks: An estimation of the likelihood, impact, and timeframe of the risks, classifying sets of related risks, and prioritization of risks relative to each other Risk Planning: Deciding what to do with the risks, which, for important risks, include mitigation plans Tracking And Controlling Risks: Collecting and reporting status information about risks and their mitigation plans (where appropriate) and taking corrective action as needed Communicating And Documenting Risks: Continuous at each process step to support decision making and risk traceability Figure 2-1 Risk Management Function 2.1 RISK MANAGEMENT INTEGRATION The HMI CRM process is integrated into the HMI Project Management and Systems Engineering activities. In general risks are treated in a manner similar to that used to identify and track problems & failures, or changes to configuration control items (e.g., documents, hardware, software), in terms of the level of review, classification, and oversight. The HMI risks will be tracked in an excel spreadsheet maintained by the HMI Risk Management Board. The HMI risks that are not classified as internal team risks per Paragraph 3.3 of 464-SA-PLAN-0003 will be documented and reported to the SDO Project for inclusion in the SDO Project Risk Database. 5

8 2.2 RISK MANAGEMENT PHILOSOPHY 2H00075 Rev. - The HMI program will use a risk management philosophy that defines a multi-layer approach for RM that allows cognizant teams and groups to retain authority for (and control over) risks within their areas of responsibility, and at the same time supports the HMI program management s decision-making processes. This philosophy addresses the three distinct aspects of risk identified in paragraph 2.3 of 464-SA-PLAN These are: 1. Safety Related Risk 2. Mission Performance-related Risk 3. Project Execution Related Risk These risks are separated because, the methods used for identifying the risks are different, the impact and likelihood scales used in evaluating the risks are different, the mitigation options available are different, and the risk review and acceptance processes are different. 6

9 Chapter 3. HMI Risk Management Organization and Responsibilities 2H00075 Rev HMI PROGRAM RISK MANAGEMENT ORGANIZATION This section describes the HMI Program functional organization and CRM process responsibilities. The HMI Program Manager has overall CRM technical and programmatic responsibility from program concept phase through design, manufacture, test, and delivery phases. In general, the responsibility of day-to-day CRM implementation is delegated to the HMI Risk Management Review Board (RMRB) and effectively to each Program team and individual. The RMRB has been created to support the Risk Management Process. The HMI program organization for Risk Management is structured around the RMRB. Each HMI design lead is responsible for assuring that their teams, sub-contractors, and other affiliated organizations fully participate in the CRM process. The Program Manager, Program Scientist, Systems Engineer, Mission Assurance Manager, and engineering specialists, as needed comprise the HMI RMRB. The HMI Program Manager has the responsibility of assuring program compliance with NASA Risk Management policies and guidelines; this responsibility includes implementation and maintenance of the HMI-tailored CRM process. The HMI Program Scientist, in addition to being a member of the HMI Program s Senior Staff and RMRB, is considered a science community representative and is responsible for ensuring that risks to science objectives are identified and mitigated. Responsibilities for risk identification, analysis, planning, tracking, control, and acceptance are overlapping (as depicted in Figure 3-2). Individuals & Teams Identify Analyze Mission Assurance Manager Program Manager Plan Track Control RMRB Accept Figure 3-1 Responsibility and Activity Overlap The CRM paradigm provides an infrastructure with feedback loops, in both planning and implementation, that facilitate an open dialogue and communication. This feedback is used to reevaluate and update each element (e.g., consolidating risk sets into single risks; revising risk descriptions and contexts; updating risk analysis information). 7

10 3.1 HMI PROGRAM RISK MANAGEMENT RESPONSIBILITES 8 2H00075 Rev. - The HMI program manager retains the ultimate responsibility for accepting risk and allocating resources across the program to eliminate, reduce, or mitigate risks. The HMI risk management activities are split between the individuals on the HMI team and the HMI RMRB. The individuals on the HMI Team are responsible for identifying new risks, providing initial estimate of likelihood, impact and mitigation timeline, classifying risks as safety, mission performance or project execution, and recommending mitigation approach and actions. Who Responsibilities Individuals Identify new risks (likelihood, consequence, context) Risk Management Review Board Provide initial estimate of likelihood, impact, and mitigation timeframe Classify risks as either Safety, Mission Performance or Project Execution Recommend mitigation approach and actions Perform analysis of new risks, revising initial information (if necessary) Create action plans; adjust risk mitigation strategy over time Assign (or change responsibility) for each risk and mitigation plan Direct cost, schedule and technical resources to mitigate risks Determine Top 10 risks for overall project and in each area (software, hardware, etc.) Make recommendations to HMI Program Manager regarding expenditure of resources for mitigation Communicate significant risks or changes to the Project Manager Make recommendations to HMI Program Manager regarding risk closure and/or acceptance Program Manager Responsible for overall HMI Program Risk Management Final authority for risk closure and/or risk acceptance Final approval and concurrence for control decisions (analyze, decide, execute) for Top 10 project risks and presentation to senior management Authorizes expenditure of program resources for mitigation Final approval and concurrence for assignments or changes in responsibility for risks and mitigation plans within the HMI Program Communicates significant risk or changes to SDO Project management Delegates responsibilities for performing Risk Management and Risk Mitigation Table 3-1 Risk Management Responsibilities 3.2 HMI RISK MANAGEMENT REVIEW BOARD The HMI RMRB is the official forum for the formal evaluation, deliberation, classification and control of all HMI Program risks. The HMI RMRB is a senior management board that, at a minimum, consists of the Program Manager, Program Scientist, Systems Engineer, Mission Assurance Manager, and engineering specialists, as needed. The final authority for the membership of the RMRB resides with the HMI Program Manager. The RMRB analyzes new risks and makes any necessary revisions to the initial information, as well as creating action plans. The RMRB assigns (or changes) responsibility for each risk and mitigation plan, making adjustments to the risk mitigation strategy over time. Important actions taken by the RMRB are to direct cost, schedule and technical resources to mitigate HMI risks, consolidate duplicate/related risks, and resolve incompatibilities or

11 2H00075 Rev. - conflicts. The RMRB determines the top ten risks for the overall HMI program, and in each functional area, and reports the highest priority risks (including all Primary Risks) to HMI program management. The RMRB members make recommendations to Program Manager regarding expenditure of resources for mitigation, and communicate significant risks or changes. The RMRB members also make recommendations to Program Manager regarding risk closure and/or acceptance. The board members also assist the Program Manager in establishment of HMI Risk Management policies, including communication of HMI risks to SDO Project Management. The HMI Risk Management Process as defined in Appendix B of 464-SA-PLAN-0003 is the responsibility of the HMI RMRB. The HMI RMRB classifies each risk as either an internal team risk to be tracked and mitigated internal to the HMI program or as a SDO Project Risk to be reported to the SDO Risk Management Review Board to be tracked as part of the SDO Risk Management Data Base. 9

12 Chapter 4. Risk Management Process 2H00075 Rev RISK MANAGEMENT FUNCTIONS This section is summary of the Risk Management process. The HMI program identifies risks by continually reviewing mission success criteria, science objectives, designs (systems, subsystem, etc.), interfaces, processes, and safety aspects, as well as baseline requirements, schedules, budgets, and all other relevant program elements. Theses items are assessed against the program baseline estimates/models (and thresholds or other triggers) to ensure objectives support compliance with program requirements and mission success criteria. The HMI Risk Management Process major functional areas are: RISK IDENTIFICATION: Working with the risk Originator(s) (individual, team, or group) the HMI RMRB will ensure that all of the relevant information is gathered and documented. The RMRB facilitates risk capture, reducing originator workload to the maximum possible extent. The RMRB documents the risk statement, consequence, risk context, impact and likelihood for the originator and enters it into the HMI Risk Database. RISK ANALYSIS: The Originator/RMRB will determine attributes of the risks by stating the likelihood of the risk occurring (if no action is taken); the impact on the project (should the risk occur); and the time frame needed to act on the risk (to prevent its occurrence). The Originator/ RMRB will classify the risk by indicating if this is a technical, programmatic, schedule, or cost risk. Lastly, the RMRB determines if the risk is an Internal Team Risk or an SDO Project Risk and enters it in the HMI Risk Database. RISK MITIGATION AND TRACKING: The HMI program manager includes them in the agenda for the next scheduled RMRB meeting. At the RMRB new risks and the status of existing risk items are reviewed. COMMUNICATE & DOCUMENT: After review, approval, and/or disposition by the board, the RMRB updates the HMI Risk Database. Risk Management reports are provided at the HMI Staff meetings to ensure current risk information is available for appropriate action. Any new risks identified during any program-related meeting shall be communicated to the HMI program manager within one week of the meeting. It is the responsibility of the meeting leader to make sure that this is accomplished. 10

13 2H00075 Rev. - Appendix A and Appendix B From 464-SA-PLAN-0003 Solar Dynamics Observatory (SDO) Project Continuous Risk Management Plan Are Included For Reference Only. 11

14 Appendix A Acronyms And Definitions 2H00075 Rev. - CRM ELV ESA FMEA FTA GPMC GSFC LWS MSR NIAT PDL PDT PRA RBD RIS RM RMC RMD RMRB RWG SAM SDO TRL Continuous Risk Management Expendable Launch Vehicle European Space Agency Fault Modes and Effects Analysis Fault Tree Analysis Goddard Program Management Council Goddard Space Flight Center Living With a Star Mission Systems Review NASA Integrated Action Team Product Design Lead Product Design Team Probabilistic Risk Analysis Reliability Block Diagram Risk Information Sheet Risk Management Risk Management Coordinator Risk Management Database Risk Management Review Board Risk Working Group System Assurance Manager Solar Dynamics Observatory Technical Readiness Level Acronyms Definitions Acceptable Risk: A risk that is understood and agreed to by the Project, Program, Goddard Program Management Council (GPMC), Enterprise (and other customers) to have no further planned action or mitigation. Accepting a Risk: A risk is accepted when no further Project expenditures are warranted for mitigating the risk and no further action will be taken. The risk will be handled as a problem if it occurs. Affiliated Organization: Other Government agencies, other NASA centers, research institutions, or contractors that provide support (financial resources, facilities, materials, procedures, equipment and personnel) to or are otherwise associated with the SDO Project or its Instrument Developers. Closed Risk: Risks are closed when the likelihood reaches 0% (e.g., change in requirements or fully mitigated), the likelihood reaches 100% (risk becomes a problem), or is when the risk is accepted by Project management. Note: When risks become a problem, new risks associated with the problem are captured. Fault Tree Analysis (FTA): A qualitative or quantitative 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. The results of a qualitative FTA are cut sets. The results of a quantitative FTA is a prediction of the likelihood of the occurrence of a top event failure. 12

15 2H00075 Rev. - Failure Modes and Effects Analysis (FMEA): 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. Mitigation Plan: An formal plan devised to reduce a risk s exposure by either reducing its likelihood of occurrence and/or its impact. New Risk: Risk information that has not been formally accepted by the RMRB. The new risk must be vetted by Mission Systems Engineering (facilitated by the Risk Management Coordinator) prior to RMRB submittal. Open Risk: Risk assigned and currently being worked on. Primary Risk: A red risk as depicted on the SDO Risk Matrix. Probabilistic Risk Assessment (PRA): A rigorous technical discipline used in complex technological applications to reveal design, operation, and maintenance vulnerabilities, to enhance safety and to reduce costs. Problem: When a risk occurs, its likelihood has now become 100% and the risk has by definition becomes a problem. It is important not to refer to problems as risks. A risk that has occurred should be Closed in the database see status definitions below. Risk: Potential problem that is likely to impact Safety, Mission Performance or Project Execution that: May result in existing project plan modification May result in increased vigilance/reinforcement of existing project plan May be eventually accepted by the Project In effect, a risk is the combination of the likelihood that a project will experience an undesired event (e.g., safety mishap, environmental exposure, failure to achieve mission success criteria, cost overrun, schedule slippage) and the severity of the consequences of the undesired event, were it to occur. Risk Assignee: The person assigned a risk by his or her group manager, and who is therefore responsible for working a risk. In general, this means that the risk assignee is responsible for planning what to do to reduce the risk s exposure via a combination of risk mitigation, risk research, risk acceptance and/or risk watching (see below for definitions of new terms). The risk assignee is also tasked with carrying out the risk plan to its conclusion (or at least leading this effort). Risk Management Review Board: A board established by the Project Manager to make SDO risk control decisions. Risk Context: The portion of the RIS or Risk data that provides an explanation of the risk giving a fuller understanding of the conditions under which the risk has occurred. The context should be sufficient to give another person unfamiliar with the risk sufficient understanding of the general situation, in particular, after some time has passed. Risk Control: The process of risk assessment, risk mitigation activities, risk tracking, and consolidation of other information to make decisions regarding funding support, diversion of resources from one mitigation effort to another, etc. Risk Description (example): Risk Title: Schedule delay in XYZ simulator could adversely affect ABC delivery. Formal Risk Statement: IF the delivery of the XYZ simulator to the ABC integration is delayed more than W weeks; THEN the ABC integration could be delayed, adversely affecting ABC delivery. Risk ID: Unique identifier for each risk in the risk database (e.g., 061). Risk List: A formal report that lists the title of all SDO risks, their status and the responsible engineer. The Risk List is considered a formal International Standards Organization (ISO) Quality Record that the Project must maintain. Risk Management: A process wherein the Project Manager or designated person(s) (Risk Management Coordinator, Risk Management Review Board, Team Leads, etc.) leads the team in identifying, analyzing, planning, tracking, controlling, and communicating the risks and the actions to handle them. Effective communication must occur within the team, management, and customers. Risk Management is driven by established success criteria and is a continuous, iterative process to manage risk in order to achieve Safety, Mission Performance and Project Execution success. Risk Planning: Activity of selecting a definite strategy (called a Risk Action Plan) for reducing the exposure of a risk, where in qualitative terms, risk exposure = risk likelihood * risk impact. 13

16 2H00075 Rev. - Risk Research: Risk planning may lead to the conclusion that specific research is warranted before deciding between a specific risk mitigation or risk acceptance. The risk action plan in the RMT then takes the form of a research plan with a commitment for the research report to be delivered by a specific date. Risk Statement: Listed in the SDO Risk Management database, takes a more precise IF; THEN form consisting of two clauses, the first of which (or IF clause) is the precipitating factor, and the second (or THEN clause) is the impact or consequence factor. Risk Status: Current status (New, Open, Closed, Accepted, etc.) of any Risk. Risk Identifier/Originator: The person who fills out and submits/reports a potential risk. The Identifier/Originator is responsible to work with Risk Management Coordinator to develop the initial version of the risk title and selecting an initial group or product (see definition of group below), which will receive the risk and address it. Once a risk is submitted, the risk has a status of New. Risk Timeframe: A time (date or event) when mitigation action must be taken to prevent the risk from being realized. Risk Title: expressed in the SDO Risk Management database, is a short statement of the risk in which allows a reader to grasp its relevance and significance and localize its impact in the hierarchy of SDO systems and subsystems. Risk Tracking: Action taken by the risk team to track the mitigation activities of all open risks, to verify that the strategies and/or plans are being followed and are effective, evaluated in terms of the risk s likelihood and impact measures. Other risk-specific metrics may also be required. Risk Watching/Critical Watch List: In this case no immediate action is taken, but neither is the risk accepted. Instead, a timetable is set up for specific times to re-evaluate the risk and to see at those times if a change in the planning for that risk might be in order. The watch points might be at regular time intervals, or at specific points in the Project, such as at major reviews. Team: A (generally small) formal or informal SDO team, working on a specific hardware/software or other product, across products under a given systems engineering discipline, or as a business or administrative unit. Under SDO Risk Management, risks are assigned to teams to be worked. Team Lead: The leader of a group or team who is responsible to assign risks to group members and also to verify that new risks submitted to his or her team have been routed correctly. Note: If a given risk appears to pertain to at least two subgroups belonging to a single team higher in the organization, than the risk should be reassigned to the higher team after which it becomes the responsibility of that team lead or manager. 14

17 Appendix B Detailed Process For Risk Management 2H00075 Rev. - B-1 Ground Rules Any individual, team, or group can identify and submit risk information to the RMRB for evaluation. All risk information/risk item submittals (whether accepted as formal trackable risks or otherwise dispositioned) shall be documented and retained as part of the official project records. As a minimum, a period of five working days following the submission of a new risk information/risk items is reserved for the Risk Management Coordinator, the Originator, and the Team Lead (if identified) to review the proposed risk item for wording, to determine its applicability, and to ensure accuracy of the information. The risk status will then be marked as (O)pen, making it public and formally traceable as a risk item. The SDO Managers, Instrument organizations, contractors and other affiliated organizations shall identify the top risks in their respective areas and implement mitigation strategies (corrective actions, action plans, mitigation plans, contingencies, etc.) to control these risks. At least once every month, the SDO Project will collect, the Top 10 risks for each of these organizations, combine them with SDP Project identified risks, and further prioritize them into the Top 10 Risks for the overall SDO Project. It is anticipated that only a selected number of the Top 10 Risks for the overall SDO Project shall have additional resources expended for mitigation. The remainder of the Top 10 Risks for the Overall Project shall be monitored and managed by the project within established project constraints. The status of all identified risk items, however, will continue to be tracked with appropriate re-evaluation initiated if required. 15

18 B-2 Guidelines 2H00075 Rev. - The SDO Managers (Systems Assurance Manager, Business Manager, Mission Systems Manager, Observatory Manager, Instrument Systems Manager, Ground Systems and Mission Operations Manager) and Project Scientist will each routinely present their open high-priority risks for management review (generally monthly at the SDO Monthly Status Review) together with the status of the plans to address each risk. Detailed risk-related issues such as a proposed risk mitigation, additional resources (funds or schedule relief) beyond those already allocated for a mitigation effort or technical issues will be discussed at the next scheduled meeting of the SDO Senior Staff designated as the RMRB. Newly identified risks and any other risks or significant risk-related concerns requiring Board action will also be presented. The SDO Project encourages each project element or group (Mission Systems, Spacecraft Systems, Subsystems, Ground Systems, etc.), as well as, Instrument Developers and Contractors to conduct their own informal Risk Working Group (RWG) Meetings, facilitated by the Risk Management Coordinator as needed, to consider the group s individual risks before formally submitting them to the Risk Management Review Board for evaluation. Any risk that straddles group boundaries, i.e., a risk that involves a potential change to an interface (e.g., an interface between two different groups, teams, or subsystems), an identifiable primary risk attributes (high likelihood & high impact), or a credible safety or on-orbit performance consequence (e.g., critical or catastrophic hazard, loss of redundancy or critical function(s), etc.) should be elevated for review to the next higher-level risk, up to and including the Risk Management Review Board (i.e., Individual Team Lead Subsystem Lead Spacecraft Systems Mission Systems Manager Risk Management Review Board). 16

19 B-3 Identifying Risks 2H00075 Rev. - The risk identification process is designed to determine potential issues or concerns before they become problems and to document and communicate this information throughout the project. Table B-1 summarizes the risk identification process. Step Action 1 New risk is identified. 2 A Risk Statement is written for the new risk in the standard format (condition; consequence). A clear distinction is made to identify whether the consequence applies to Safety, Mission Performance, or Project Execution. A description of the situation surrounding the risk is provided as risk context, as well as the likelihood, impact and timeframe. 3 Risk statement, consequence, likelihood, and context of the new risk are further developed with the Risk Management Coordinator. 4 Risk statement and context of the new risk are reviewed by Systems Engineering (i.e., Spacecraft Systems Engineers, Ground Systems Engineers and Project Support). 5 Once approved by Systems Engineering, the Risk Management Coordinator enters the new risk into the SDO Risk Management Database. 6 Risk statements entered into the database are reviewed monthly by Risk Management Review Board. Table B-1 Risk Identification The SDO Project shall identify risks by continually reviewing mission success criteria, science objectives, designs (systems, subsystem, instruments, etc.), interfaces, processes, and safety, as well as baseline requirements, schedules, budgets, and all other relevant project elements. Theses items are assessed against the project baseline estimates/models and thresholds or other triggers to ensure objectives support compliance with project requirements and mission success criteria. The risk consequence is identified as effecting Safety, Mission Performance, or Project Execution. Safety risks include the potential for personnel injury and damage to hardware and/or facilities. Mission Performance risks pertain to the Flight/Ground Segments and the End Products performing their desired function in their operational environment. Project Execution risks pertain to development activities and the Project s ability to deliver the desired product meeting requirements, on time and within budget constraints. Every individual and PDT is encouraged to identify and communicate risk concerns to the Project. The most direct means for communicating potential risks is through the Risk Management Database. All other methods (verbal, electronic mail, written, etc.) methods for communicating risks should be directed to Team Leads, Managers, and/or the Risk Management Coordinator for action. All project personnel are expected to help identify new risks and are encouraged to review the RMD at least once a month. Project metrics, such as cost and schedule, shall be reviewed whenever a threshold or trigger is reached that would indicate that a risk is becoming problem. 17

20 B-5 Analyzing and Classifying Risks 2H00075 Rev. - Risk analysis and classification is used to ascertain as accurately as possible the validity of an identified risk, the likelihood of that risk, the magnitude of the consequence of such an event, and timing for mitigating the risk(s). The following steps are used to analyze risks: Step Action 1 Risk attributes (impact, likelihood, and timeframe) are evaluated by the identifier of the risk. 2 Risk attributes are validated by Mission Systems Engineering. 3 Risk attributes are entered into the Risk Management Database. 4 Risk attributes are reviewed and corrected periodically by the Risk Management Coordinator and the RMRB. 5 Risks are validated and prioritized in their respective areas by the SDO Manager(s), the RMRB, and the SDO Project Manager. Table B-2 Analyzing and Classifying Risks The evaluation of risks will consist of the following: Impact Classification based on severity if the risk is realized. Likelihood Classification based on the likelihood of the risk occurring. Timeframe Classification based on the period when mitigation action(s) is needed To reduce the subjective factor in making such assessments, the SDO risk process utilizes rating scales for each of these measures defined in advance with each of five impact, likelihood, and timeframe levels described in Tables B-3 and B-4. The impact of a risk event can be to cost, schedule and/or technical performance simultaneously. For any risk, it is the impact with the most severe rating that is used to determine the risk exposure. The 5-Level Attribute Evaluation method shall be used for evaluating attributes. Initial classification of risks shall identify project level (Mission, Project, System, Subsystem, Instrument, etc.); organizational element (Power Subsystem, C&DH, Ground Station, etc.); and Mission Consequence (Safety, Mission Performance, or Project Implementation) with subcategories of Technical, Resources, Cost, and Schedule. Risk attributes of likelihood, impact, and timeframe are initially estimated by the originator and entered at the same time the risk is identified and documented. If the originator does not know the value of the estimates, they can be skipped. The Risk Management Coordinator works with the originator to further develop the risk and determine attributes of the risks. If warranted, the RMRB may also request more comprehensive and quantitative analyses to determine risk attributes. The primary methods used in analyzing risks are qualitative. In general, qualitative methods are considered adequate for making Risk Management decisions; in some cases, qualitative methods may not be considered precise enough to understand the magnitude of the risk, or to allocate limited risk reduction resources. The RMRB will need to decide whether the risk identification and classification is adequate, or whether the increased precision of quantitative analyses (more detailed reliability analyses, a more comprehensive PRA, Probabilistic Cost & Schedule Analyses, Monte Carlo modeling, etc.) or testing (test-to-failure, life-testing, etc.) are needed to reduce risk uncertainties. In making this determination, the RMRB will need to balance the (relatively) higher cost of risk analysis against the value of the additional insights. The allocation of additional resources for analysis of some risks may limit the availability of resources for mitigating other risks. It is therefore imperative that mission/system-wide effects of various strategies be understood in order to make a rational allocation of resources. In each successive level of review, SDO Systems Engineering, the SDO Manager(s), the RMRB, and the Project Manager will evaluate the validity of all risk items submitted. A risk is deemed valid if it truly represents a credible condition with the consequence having an impact on the Project. At the discretion of the RMRB and with concurrence of the Project Manager, a risk may be rejected if it is determined that it has no merit or has no potential for impact on the Project. Similarly, the RMRB with concurrence for the Project Manager may return elevated risks for resolution at the lower level. 18

21 2H00075 Rev. - Rank Impact 5 Very High Safety (NPG ) Mission Performance Project Execution I Catastrophic - A condition that may cause death or permanently disabling injury, facility destruction on the ground, or loss of crew, major systems, or vehicle during the mission. 4 High II Critical - A condition that may cause severe injury or occupational illness, or major property damage to facilities, systems, equipment, or flight hardware. 3 Moderate III Moderate - A condition that may cause minor injury or occupational illness, or minor property damage to facilities, systems, equipment, or flight hardware. 2 Low IV Negligible - A condition that could cause the need for minor first aid treatment though would not adversely affect personal safety or health. A condition that subjects facilities, equipment, or flight hardware to more than normal wear and tear. Total Loss of Mission Loss of Science - (Does Not Meet Minimum Success Criteria) Degraded Mission - (Does Not Meet Full Success Criteria, Meets Minimum Success Criteria) 1 Very Low Not Used Loss of Non-Critical Function - Technical Threatens ability to meet minimum mission success criteria, estimates exceed established margins (mass, power, volume) Cost Greater than 10% increase over that allocated and/or exceeds available reserves Schedule Major impact to critical path and cannot meet major milestone. Technical Threatens established margins Cost Between 7% and 10% increase over that allocated, and/or threatens to reduce reserves below prudent levels Schedule Significant impact to critical path, and cannot meet established lowerlevel milestone. Level 2 milestone slip of > 1 month, or Project critical path impacted. Technical Can handle within established margins. Cost Between 5% and 7% increase over that allocated, and can be handled within available reserves. Schedule Impact to critical path, but can handle within schedule reserve, no impact to milestones. Level 2 milestone slip of < 1 month. Not Used Technical Can handle within established margins. (Loss or Degradation of Redundancy) 0 Non-Credible Risk (Meets Full Success Criteria, Negligible or Minor Impact) Cost Between 2% and 5% increase over that allocated, and can be handled within available reserves. Schedule Minor schedule impact, but can handle within schedule reserve; no impact to critical path. Some additional activities may be required. Technical No impact on margins. Cost Less that 2% increase over that allocated, and can be handled within available reserves. Schedule Minimal or no impact to schedule, no impact to schedule reserve; no impact to critical path. 19

22 Table B-3 Risk Impacts 2H00075 Rev. - 20

23 2H00075 Rev. - The Risk Matrix shown in Figure B-1 provides a framework for displaying the risk exposure represented by the various items of risk that have been identified. Using this approach the SDO Project can rank risks and provide relative values of the likelihood of occurrence and potential consequence of each risk. After the likelihood and the impact of the risk are separately analyzed, these two factors are combined to arrive at a measure of the risk exposure. A Risk Exposure or Risk Acceptance Code (RAC) shall be determined for each risk item. The intersection of the likelihood rating with the impact rating is used to assign the RAC. The purpose of the RAC is to allow for a common classification of High, Medium, or Low (Red, Yellow, or Green) for all risks regardless of source, type, or consequence. The Risk Analysis process may optionally include grouping one or more risks into sets of similar risks that can be treated together for risk mitigation. Finally, the time frame is assigned to each risk to further prioritize the risks. Timeframe is the time by which action must be taken to mitigate the risk. 21

24 2H00075 Rev. - Likelihood Impact (Technical, Cost or Schedule) E D C B A 5 Very High High 4 High 3 Moderate Medium 2 Low 1 Very Low Low Risk Assessment Code Actions High Unacceptable. Imperative to mitigate risk and reduce severity and/or likelihood to lower level. Requires mitigation strategy, written mitigation plan, contingency plan, or alternative/descope options. Project Management decision required. Medium Undesirable. Requires mitigation strategy, written action plan, time-limited deviation or waiver. Upon completion of mitigating activities, accepted with review and concurrence by Project Management Low Permissible. Acceptable without review by Project Management Note: Risk Assessment Codes and actions remain consistent regardless of Risk Consequence or Attributes Figure B-1 Risk Matrix 22

25 2H00075 Rev. - Rank Likelihood Safety Mission Performance Project Execution 5 Very High > 10-1 >50% % 4 High 10-1 > X > 10-2 <50%..-.. >10% 60-80% 3 Moderate 10-2 > X > 10-3 <10%..-.. >1% 40-60% 2 Low 10-3 > X > 10-6 <1%..-.. >.1% 20-40% 1 Very Low <10-6 <.1% 0-20% 0 Non Credible Table B-4 Risk Likelihood 23

26 B-6 Risk Planning 2H00075 Rev. - Planning takes the input from the Risk Analysis function and, for the high- and medium-priority risks, formulates action plans to address them. The risk must first be assigned to an individual who has the ability and knowledge to address the risk. As newly-identified risks are brought to a manager's immediate attention through meeting, database reports or other communication, the manager shall determine whether to delegate responsibility or transfer or elevate responsibility up the project organization. Table B-5 identifies the steps in the risk planning process. Step Action 1 Individual or team assigned responsibility for all Top 10 Risks for the Overall Project risks by the Project Manager. 2 Individual or team responsible for a risk determines approach to be taken by writing an action plan. Possible actions: research, accept, watch, transfer, or mitigate. 3 If a mitigation plan is appropriate, it shall either be an action item list or follow the standard template for SDO action plans. 4 If a mitigation plan is created, a contingency plan shall also be created. 5 All action plans are reviewed by the Project Manager Table B-5 Risk Planning Steps An individual, PDT, or group within the Project shall be assigned responsibility for each risk identified and validated by the RMRB. The Project Manager shall also ensure that resources for mitigating each of the Top 10 Risks are appropriately allocated. Responsibility for a risk means that the assigned person is responsible for the status and mitigation of the risk. A number of possible actions can be planned. A given action may include thresholds or trigger points at which decisions are planned. These decision points are established in advance to address such things as the initiation of a contingency plan. One of the following actions is initiated for each risk identified: Risk Research: Investigate the risk until sufficient information is obtained to decide on further action. Risk Acceptance: It is accepted that the risk may become a problem if the concern is realized; however, no further resources are allocated to the risk. Risk assumption is a conscious decision to accept the associated level of risk, without engaging in any special efforts to control it. A general cost or schedule reserve may be set aside to deal with any problems that may occur due to the risks that have been accepted. Risk Watching: Similar to Risk Acceptance, but with the addition that the Project monitors the risk and its attributes for early warnings of critical changes in impact, likelihood, time frame or other aspects. The warnings are defined in terms of triggers that if they occur, action is warranted. Risk Closure: This strategy involves a change in the concept, requirements, specifications and/or practices that close the risk. Simply stated, it eliminates the sources of the risk. Risk Mitigation/Risk Control: These two terms refer to taking action to reduce the risk exposure, by reducing either the likelihood of occurrence, the impact, or both. Risk Transfer: Risk transfer may reallocate risk during the concept development and design processes from one part of the system to another, thereby reducing the overall system or lower-level risk, or re-distributing risks. Risk transfer may also transfer non-conformances to the Non-Conformance Reporting (NCR) system or safety related concern to hazard analyses. Risk transfer may also involve elevating a risk. A risk may be elevated to the attention of higher management (in general) for three reasons: a) the risk exposure is high (that is, it has both high likelihood and high impact); b) the risk spans more than one product area, or discipline, and must therefore be addressed at the next higher level in the product organization; or, c) resources are required beyond those available in the original product area s reserves. The SDO Project has established the following risk mitigation precedence: elimination or control of all Safety risks; elimination and control of Mission Performance risks; and control of Project Implementation risks. 24

27 2H00075 Rev. - 25

28 B-7 Tracking and Control of Risks 2H00075 Rev. - Risk tracking and monitoring is the collection of status data for risks with currently implemented action plans. The data is collected for general progress, but also specifically for the metrics identified in the risk planning step. The responsible individual or PDT has the responsibility for specifying such metrics, with review by the SDO RMRB. The individual or PDT responsible for a risk in the Top 10 Risks for the Overall Project shall provide routine status reports to Project Manager during regular weekly functional area meetings and the weekly and monthly Project meetings. The status for each of the Project Top 10 Risks shall be reported each week in their respective meetings. Status on all watch lists shall also be reported during the monthly meetings. The RMD shall be used to report summary status information for risks. On a monthly basis, individuals and PDTs assigned responsibilities for risks shall control risks through use of four options: Continue Tracking a Risk, Re-plan, Invoke Contingency Plan or Close a Risk. Continue Tracking a Risk shall require no action. Closing a risk shall require the completion, review, and approval (signature) for that risk. Re-plan shall require modification and resubmission. Invoking of the Contingency Plan shall require a formal concurrence from the Project Manager. In general, risk control is the management process that oversees the Risk Management process as a whole. The risk control process oversees the options of consolidating risk sets into single risks, re-writing risk descriptions and contexts (to make them more precise, or to reflect current information) and revising risk analysis information, including time frame, likelihood, and impact. The RMRB has the responsibility of risk control, by which the board reviews the present allocation of resources to risk action activities, and considers whether to recommend a change in that allocation. Alternatively, if risk mitigation is not succeeding, the RMRB may recommend moving the funding for that mitigation to another high-priority risk. Risks can be moved as part of risk control from mitigation to watching status, or vice versa. Items that are no longer risks (for example, the initiating event can no longer happen, or the impact can no longer occur) should be closed. 26