GP-B Post-Flight Analysis—Final Report - Gravity Probe B - Stanford ...

Hardware risks were evaluated using probability and impact of potential failure using a complete FMEAprocess; other program risks (budget, schedule, personnel) were evaluated using a similar method. Thecommittees solicited advice from independent councils of experts to ensure our evaluations were correct.Table 16-1 summarizes the five risk categories and definitions used by GP-B.Table 16-1. GP-B Risk categories and definitionsEvent Likelihood Consequences—Impact to Program if Event OccursRiskValueChance ofOccurrenceProgram CostIncreaseCritical PathImpactTechnical Impact5 Near certainty: > $8 M > 60 days Loss of mission.(90%)4 Highly likely: >$4M but < 8M 31 - 60 days Mission performance requirements degraded.(75%)3 Moderate: (50%) >$1M but < 4M 8 - 30 days Loss of some system level redundancy; nocompromise of mission requirements2 Low: (25%) 1M 1 - 7 days Technical impact without loss of system levelperformance or redundancy.1 Not likely: (10%) $100K None No compromise in mission performance orredundancy.Based on potential impact to the program, each risk was evaluated using Table 16-1above as a guideline andassigned to one of three categories:• Mitigate. Eliminate or reduce the risk by reducing the impact, reducing the probability or shifting thetime frame. If a risk is marked as “mitigate” the user will input a summary of the mitigation plan in theMitigation Strategy Summary field and a detailed plan if necessary.• Watch. Monitor the risks and their attributes for early warning of critical changes in impact, probability,time frame, or other aspects. If a risk is marked as “watch”, the user will input triggers for changing thatapproach in the Contingency plan/trigger field and any other appropriate/applicable plans.• Accept. Do nothing. The risk will be handled as a problem if it occurs. No further resources areexpended managing the risk. If a risk is marked as “accept”, the user will be prompted to input amandatory acceptance rationale along with any plans for handling the risk if it does occur.Risks were promoted or demoted as program need or technical understanding evolved.Best Practices:A formal risk management process with strong management support significantly improves the efficiency andtechnical understanding of the project team.16.3 Management Lessons from the Calder-Jones ReportBecause some aspects of GP-B program management were unique among NASA programs, and because GP-Bwas viewed as a management experiment as well as a scientific experiment—as described in Chapter 6, The GP-B Management Experiment—in 2005, NASA Headquarters commissioned two former GP-B team members,Ned Calder from the Engineering Systems Division at MIT and Brad Jones, from the Aeronautics &Astronautics Department at Stanford University to research and prepare an independent study on themanagement of GP-B. Calder and Jones presented their finished report, entitled: Gravity Probe B: A ManagementStudy to NASA in April 2006. A PDF copy of the complete Calder-Jones Report is available for downloadingfrom the GP-B Web server at: http://einstein.stanford.edu/pao/pfar/cj_report-apr2006.pdf.Gravity Probe B — Post Flight Analysis • Final Report March 2007 457