![Course Content ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
En vedette
En vedette (12)
Similaire à Fussell.louis
Similaire à Fussell.louis (20)
Plus de NASAPMC
Dernier
Dernier (20)
Fussell.louis
- 1. Project Risk Management Louis Fussell Used with permission
- 11. Risk Management in the Context of Agency Decision Making Strategic Goals Decompose Objectives into Imposed Constraints and Performance Measures ARCHITECTURE ALTERNATIVES SYSTEM ALTERNATIVES Program Requirements Project Requirements Risks to Reqs Risks to Reqs Reassess Alternatives or Rebaseline Reqs Reassess Alternatives or Rebaseline Reqs SUBSYSTEM ALTERNATIVES Subsystem Requirements Risks to Reqs Reassess Alternatives or Rebaseline Reqs CRM CRM CRM
- 12. Performance Requirements & Performance Measures Priorities Set Top-Down Requirements Flow Top-Down Risk Reported Bottom-Up Decisions Elevated Bottom-Up
- 13. Risk-Informed Decision Making (RIDM)
- 15. Identification of Alternatives Overview Identification of Stakeholders Upper Level Requirements & Specifications Identification of Alternatives Step 1 – Understand Stakeholder Expectations and Derive Performance Measures from Objectives Step 2 – Compile Feasible Alternatives Requirements & Expectations Concept of Operations Performance Measures List of Alternatives
- 18. Identification of Alternatives Overview Performance Measures List of Alternatives Risk Analysis of Alternatives Step 3 – Set the Framework and Choose the Analysis Methodologies Step 4 – Conduct the Risk Assessment and Document the Results Analysis Methodology Analysis of Performance Measures Performance Commitments Analysis Documentation
- 22. Identification of Alternatives Overview List of Alternatives Technical Basis for Deliberation Risk-Informed Alternative Selection Step 5 – Develop Risk Normalized Performance Commitments Step 6 – Deliberate, Select and Alternative, and Document the Decision Rationale Decision Decision Rationale Risk-Informed Selection Report
- 26. Continuous Risk Management (CRM)
- 32. Quantitative Risk Analysis Schedule Analysis Mission Risk Analysis Bad Thing X Fails Y Fails Z Fails A project … … produces a product … … and a process that operates the product. Model : Integrated Master Schedule Method: Monte Carlo Schedule Simulation Tool: @Risk for Project Model: Functional Flow Block Diagrams Method: Monte Carlo Process Simulation Tool: ARENA Model: Fault Trees Method: Probabilistic Risk Analysis Tool: SAPHIRE … that generates values. WBS Task 100 Task 101 Task 102 Task 103 Task 104 Task 105 Task 106
- 36. Risk Waterfall Chart Example Risk: Given that the Star Tracker is a new technology and may not perform to expectations, there is a possibility that the schedule may be impacted to allow time to fix shortfalls in performance Risk Exposure Time High Moderate Low 8/98 10/98 2/98 4/98 6/98 8/99 New ACS Selected Integration Testing Planned Tasks Actual Tasks Exit Criteria Met
- 39. Communication and Documentation Takes Place Throughout CRM Risk Statements Risk Attributes Action Plans Metric Reports Decisions
- 44. Please Take the 1-Day Course Check SATERN for Dates
Notes de l'éditeur
- Course material today is drawn from new NPR 8004A – Aency Risk Mangement PRocedureal Requirements, NASA Systems Engineering Handbook, NASA General Safety Program Requirements, SEI’s CRM Guidebook, and Examples from Futron’s RM experiences This is where people will sprinkle their own history
- There are a number of definitions and uses for the term risk, but there is no universally accepted definition . What all definitions have in common is agreement that risk has two characteristics: uncertainty : An event may or may not happen. loss : An event has unwanted consequences or losses. This course uses the NPR 8000.4 definition of risk. Risk is a triplett of some scenario that leads to degrated performance, the likelihood of the scenario happening, and the consequence if scenario wer e to occur
- The Continuous Risk Management paradigm illustrates a set of functions that are identified as continuous activities through out the life cycle of a project. The paradigm is a conceptual or abstract view of risk management. Same chart
- In the new NASA RM paradigm, RM is the integration of Risk Informed Decision Making and CRM whereas in the past it was just CRM In order to put CRM to work it has to be implemented into RIDM The purpose of RIDM is to better inform through…. The purpose of CRM is to manage risk associated…..
- The decision making process is fairly straightforward. If you go to any type of text for decision making process, you’ll see these steps You’ll need to understand your own biases before getting into decision making There are other APPEL courses available to help understand decision analysis and decision making PMSE – the first week deals with systems engineering, goes through decision making process; same with next two bullets Our focus on this class is how do we risk inform the decision analysis process We’re going to put on risk colored glasses to inform risk processes
- CRM is also a continuous process by the circular style of graphic Developed at DoD with Carnegie Mellon in the 70’s and provides a disciplined environemtn, what can go wrong, implement actions, and track actions until successful completion, while documenting what you come up with
- The NPR states that performance requirements flow down from agency strategic goals down to the Performance Requirements / Performance Measures to … The performance requirements stated…. The performance measures are metrics…. Performance criteria are…. Risk is the potential for performance…. Performance requirement may not always be expressed quantitatively The risk is the criteria of performance shortfalls This graphic is from the NPR and focusing on the LH side
- Break down Walk through steps in RM process and describe process steps in how manage risk process Discussed remainder of class
- Input Individuals have uncertainties and issues about the project and project progress that may or may not be risks . In group activities, individuals may collaborate to identify uncertainties and issues. The project data is supporting information that consists of items such as the schedule, budget, plans, work breakdown structure, etc. that may provide information helpful in identifying risks (e.g., previously unknown dependencies between module development schedules). Output For each risk, the statement of risk is captured along with the associated context A list containing all statements of risk
- Pulled from RIDM handbook – is fairly generic mission objective hierarchy Have some affordability objectives to keep affordable – meet performance objectives This is how to determine what performance criteria are – or looking at goals objectives for particular mission and making sure they are in alignment and coming up with those performance measures
- Input Individuals have uncertainties and issues about the project and project progress that may or may not be risks . In group activities, individuals may collaborate to identify uncertainties and issues. The project data is supporting information that consists of items such as the schedule, budget, plans, work breakdown structure, etc. that may provide information helpful in identifying risks (e.g., previously unknown dependencies between module development schedules). Output For each risk, the statement of risk is captured along with the associated context A list containing all statements of risk
- Input Individuals have uncertainties and issues about the project and project progress that may or may not be risks . In group activities, individuals may collaborate to identify uncertainties and issues. The project data is supporting information that consists of items such as the schedule, budget, plans, work breakdown structure, etc. that may provide information helpful in identifying risks (e.g., previously unknown dependencies between module development schedules). Output For each risk, the statement of risk is captured along with the associated context A list containing all statements of risk
- Input Individuals have uncertainties and issues about the project and project progress that may or may not be risks . In group activities, individuals may collaborate to identify uncertainties and issues. The project data is supporting information that consists of items such as the schedule, budget, plans, work breakdown structure, etc. that may provide information helpful in identifying risks (e.g., previously unknown dependencies between module development schedules). Output For each risk, the statement of risk is captured along with the associated context A list containing all statements of risk
- The condition-consequence format provides a more complete picture of the risk, which is critical during mitigation planning . It can be read as follows: given the <condition> there is a possibility that <consequence> will occur The condition component focuses on what is currently causing concern. This is something that is true or widely perceived to be true . This component provides information that is useful when determining how to mitigate a risk. The consequence component focuses on the intermediate and long-term impact of the risk . Understanding the depth and breadth of the impact is useful in determining how much time, resources, and effort should be allocated to the mitigation effort. A well-formed risk statement usually has only one condition, but may have one or more consequences. Use this example if needed : We have multiple customers and an unclear procedure for identifying and resolving customer (science) requirement conflicts; we may get conflicts that go undetected until the design phase and that could delay implementation while we try resolving science requirements conflicts. Statement is written – given that, possibility, consequence – want to really stick to events that are possible
- Ask the students if the statements on the slides are good or bad risk statements. Have them explain their answers. Use the following as a discussion guideline. 1. “Object oriented development”—BAD What is the problem with OOD? What is the impact? 2. “The staff ...”—BETTER RESTATEMENT OF #1 - But not in correct form! Now you know that the staff needs training and time to train. State the problem in the correct format - condition and consequence Read slides briefly
- FROM IDENTIFY Input for each risk, the statement of risk and associated context a list containing all statements of risk Output for each risk, values for impact, probability, timeframe, class, and rank added to the risk information risks organized into groups based on some common basis a master list of risks containing all risks and the priority ranking of the Top N risks If you already have risks classified into groups, you may want to classify any new risks first to see if they fit into already-established groups, which may or may not have mitigation efforts underway before you evaluate. As you get more information you may need to re-evaluate, reclassify, or reprioritize. For the case study we will first look at how to evaluate a set of risks, then we’ll look at how we can group the risks into sets. We may decide that some need to be mitigated as a set. Based on the evaluation we’ll select the most important risks to the project and prioritize them
- FROM ANALYZE Input Before planning, for each risk we have statement of risk and supporting context values for impact, probability, timeframe, class, and rank the master list of all risks including the priority ranking of the top N all risks organized by class Constraints available resources for mitigation targets and limits set by the project (e.g., do not slip the schedule, use no more than 5% of team’s budget for risk mitigation) Output for each risk, updated information to include the planning approach taken (research, accept, watch, mitigate) a description of what action is to be taken to deal with the risk
- FROM THE ACTION PLANNING STEP Input Before tracking, for each risk we have statement of risk and supporting context; values for impact, probability, timeframe, class, and rank; planning approach (research, accept, watch or mitigate) Before tracking for each risk we have an action plan that consists of one of the following: research plan, acceptance rationale, tracking requirements, or mitigation plan (action list or task plan) the current values for the “watched” and “mitigate” risk plans and measures Constraints—limits resources available for mitigation Supporting information—project information such as schedule and budget variances, critical path changes, and project/performance indicators can be used as triggers, thresholds, and risk- or plan-specific measures where appropriate. Outputs a variety of status reports highlighting the current values of the risk indicators and the status of action plans updated information for each risk, including current status data for the risk (e.g., measure, indicator, and trigger values)
- FROM TRACK (previous activity) Input In track, we have a variety of status reports highlighting the current values of the risk indicators and the status of action plans. Before control, the risk information for each risk comprises the statement of risk, supporting context, impact, probability, timeframe, class, rank, plan approach, and status data (e.g., measure, indicator, and trigger values). Supporting information Project information, such as schedule and budget variations, critical path changes, and project/performance indicators can be used to support decision making where appropriate. This data can be considered when project personnel make control decisions. Output a decision that determines the next action for the risk or set of risks (replan, close the risk, invoke a contingency plan, continue tracking and executing the current plan) updated information for each risk or set of risks, including the control decision
- Monitoring the quality of plan execution Are the plans being executed correctly? Are the results what was expected? Significant changes in risks changes in impact, probability, or timeframe
- takes place throughout crm cycle that we’re always coming up with informaiton we need to document
- talk about going fwd – RM process