Project Zeus Risk Management Plan at NASA

Baselined: 5/7/1998
Last Modified: N/A
Owner: David Jones/Zeus Project Manager

Purpose:  This plan documents the practice of Risk Management (RM) as tailored to the Zeus Project. It is applied to Zeus as a means to anticipate, mitigate and control risks and to focus project resources where they are needed to ensure success of the project. This plan is prepared in response to the requirements/guidelines of NPG 7120.5A, NASA Program and Project Management Processes and Requirements.

1.0 Introduction

This plan provides the structure within which the Zeus shuttle mission intends to identify, manage, mitigate, track, and control risks to achieve mission success under a fixed budget and schedule. This is a continuous evaluation process led by the Zeus Project Manager (PM) and selected project individuals and/or teams to evaluate and proactively plan, address, and update all associated risks. This plan will be updated on ________ and reviewed every 6 months to reflect changes and improvements to the risk management process.

This plan addresses the methods and tools used in the RM process (Sections 2-6, Zeus RM Plan), and addresses installing the practice on the Zeus project (Section 7, Zeus RM Implementation). The Risk Management Implementation Section will guide the actual RM transition and installation process. It directs the flow of activities associated with the initial risk management practice defined in this plan. It is recognized that this plan calls for a new practice to be put into place on a project that is already in progress. It is expected that changes and improvements will be necessary over the course of time as RM is adopted and used by Zeus. Any corrections should be forwarded to the plan owner. Change recommendations should be submitted on the Change Document Request Form 1246.

The Zeus Project Management Plan directs the activities of the overall project. The Risk Management Plan is subordinate to and an integral part of the Project Management Plan.

The NPG 7120.5A, NASA Program and Project Management Processes and Requirements, is the controlling requirements/guideline used in preparation of this plan.

This section provides an overview of the CRM process and its relation to the Zeus Project Management, including primary activities, process steps, terms, and definitions. Details of the CRM process along with actions, tasks, and tools specific to the Zeus Project, are provided in subsequent sections of this plan.

There are six primary activities of the CRM process:

• Risk Identification: continuous efforts to capture, acknowledge, and document risks as they are found.
• Risk Analysis: an evaluation of all identified risks to estimate the probability of occurrence, severity of impact, timeframe of expected occurrence or when mitigation actions are needed, classification into sets of related risks, and priority ranking.
• Risk Planning: establishes actions, plans, and approaches for addressing risks and assigns responsibilities and schedules for completion. Metrics for determining the risk status are also defined during this step.
• Risk Tracking: an activity to capture, compile, and report risk attributes and metrics which determine whether or not risks are being mitigated effectively and risk mitigation plans are being performed correctly.
• Risk Controlling: an activity that utilizes the status and tracking information to make a decision about a risk or risk mitigation effort. A risk may be closed or watched, a mitigation action may be re-planned, or a contingency plan may be invoked. Decisions on the appropriate resources needed are also determined during this activity.
• Risk Communicating and Documenting: an overt action to communicate and document the risk at all steps of the CRM process. This can be in the form of an action item log, risk information sheet, risk database, mitigation plan, status report, tracking log, and/or meeting decision.

CRM is carried out during day to day activities of Zeus Project personnel, as well as during key meetings. For Zeus only the top 20% risks shall have any resources expended for mitigation. However, all other risks shall be watched or accepted. Watched risks shall have their attributes examined and reported on a monthly basis. Any risks that are identified but ignored are considered accepted. It is also understood that not all risks to a project are identified, and it is the intent of CRM to provide the means to handle identified risks.

Figure 1. Illustrates the CRM process flow for the Zeus project. The diagram depicts the functional relationships of the identification, planning, analyzing, tracking, and controlling activities and overlays the reporting and communication activities. This section provides a description of the detailed process steps.

2.1.1 Identifying Risks

A baseline set of risks shall be identified and entered as risk statements in the [Risk Information Sheet, Risk Form, Risk Database]. Risk statements shall be written clearly and concisely, citing only one risk condition, and one or more consequences of that condition. All other relevant information shall be captured as Context describing the circumstances, contributing factors, and related issues. Good context provides the what, how, when, where, and why of the risk condition. Each risk shall be identified by number (for configuration control) and shall have a responsible person(s) assigned as owner. The person's name shall be entered in the [Risk Information Sheet, Risk Form, Risk Database].

Zeus personnel shall use a short Taxonomy-Based Questionnaire (TBQ), team Brainstorming, and individual efforts to identify risks. All project personnel are responsible for identifying new risks. New risks identified during project related meetings shall be captured and added to the [Risk Information Sheet, Risk Form, Risk Database] within two working days of the meeting. It is the responsibility of the meeting leader to make sure this is accomplished.

Each risk shall be evaluated using a Tri-Level Attribute Evaluation method to determine impact, probability of occurrence, and timeframe. Each risk shall be examined to determine its relationship to other risks identified. Initially, the identifier of the risk shall provide an estimate of these attributes. The Integrated Product Team (IPT) Leads, the IPT members, and the Systems Assurance Manager (SAM) shall be responsible for further analyses and prioritization of the risks. The criteria for analyzing risks are established in Section 4.0 Risk Classification. Risks that relate directly with one another may be put into a risk set using the Affinity Grouping method and can be analyzed as a group.

The IPT, IPT Leads, and SAM using the Multi-voting method shall prioritize the risks. Only the Top 20% of all risks identified within an IPT shall be elevated to the Project Manager for further prioritization and control decisions. The Project Manager and Instrument Manager(s) are responsible for reprioritizing risks from all IPTs to determine the Top 20% risks for the Zeus Project. Only these Top 20% risks shall receive mitigation resources [Note: the Top 20% risks will change throughout the project life cycle, as new risks appear, other risks are closed, and risk status changes.]

As newly identified risks are brought to a team lead or manager's attention through weekly team meetings and database reports, they shall determine whether to keep the risk, delegate responsibility, or transfer the risk responsibility up the project organization chain. The Project Manager, if necessary, may transfer a risk(s) to external organizations if that organization is best suited to handle the risk.

All Top 20% risks shall be assigned to a specific Zeus team member for responsibility. Responsibility for a risk means that the person must answer for the status and mitigation of the risk. This person shall also assign risk mitigation actions to other Zeus team members, as required.

Risk planning requires a decision to perform further research (creating a research plan), accept the risk (document acceptance rationale in the database and close the risk), watch the risk attributes and status (define tracking requirements, document in the database, and assign a "watch" action), or mitigate the risk (create a mitigation task plan, assign action items, and monitor the activities and risk). See Appendix A for a standard plan template. Note that only the Top 20% risks shall have any resources expended toward planning and mitigation.

Mitigation activities shall be by an action item list or through Zeus mitigation task plans. Task plans shall be written for any effort that requires re-allocation of project resources. The Project Manager shall determine when to use a Mitigation Plan.

Risk information and metrics defined during planning shall be captured, tracked and analyzed for trends. The person responsible for the risk shall provide routine trend and status reports on research and/or mitigation activities to the Project Manager during the weekly Zeus Project meetings. Watched risks shall be reported on during the monthly Zeus Project meetings. Spreadsheet Risk Tracking shall be used to report summary status and a Stoplight Status Report shall be used by the PM to report progress to senior management at the monthly reviews.

Decisions shall be made by the PM during the weekly and monthly meetings to close risks, continue to research, mitigate or watch risks, re-plan or re-focus actions or activities, or invoke contingency plans. This is also the time when the PM authorizes and allocates resources toward risks.

Weekly project and IPT meetings shall include status of risks. Monthly project meetings shall include status of risks and decisions for controlling risks and risk management activities. The baseline set of risks shall be reviewed and re-established on a project milestone basis. All risk information shall be documented in the [Risk Information Sheet, Risk Form, Risk Database] and is accessible by all Zeus project personnel. Only the person assigned responsibility for the risk shall have the authority to update the risk information. Risk Spreadsheets and Stoplight Status Charts can only be printed and presented by the PM, IPT Leads, or designated assistants.

This section provides the project personnel functional roles, responsibilities, and communication within the CRM process. CRM is carried out during the day-to-day activities of project personnel as well as during key project meetings.

3.1 Zeus Project Organization

Figure 2 Depicts the organization as defined in the Zeus Project Management Plan. It is repeated here for convenience. The diagram illustrates the structure of the project team along with the organizational role of each team member.

Figure 3 Depicts the responsibilities of all project personnel as individuals, IPT leads, instrument managers, and Project Manager for managing risk within the Zeus Project. The diagram identifies the personnel responsible for performing each specific CRM task. A dotted line splitting any boxes shown in Figure 3. represents a shared responsibility for activities within the boxes

Figure 3

Table 1. summarizes the responsibilities of all project personnel performing CRM.

Table 2. provides the criteria for communicating and documenting risk information.

Table 2

4.0 Risk Classification

Risks shall be analyzed using the Impact, Likelihood, and Timeframe classifications defined below. Impact classifications are based on Zeus requirements, mission success criteria, resources, and cost and schedule constraints. Likelihood classifications are intended to provide an order of magnitude estimate based on available quantitative data and qualitative experience.

High

• Schedule Slip - Slip in delivery of Zeus to the Shuttle, slip in delivery of major system or subsystem beyond 6 months of milestone schedule
• Cost Overrun - >10% increase to Zeus budget allocation
• Technical - Loss of mission, critical function, or major science objective
• Political - ? Bad press for NASA, high publicity issues, withering support by NASA HQ or Congress

Significant

• Schedule Slip - > 4 month <6 month delay of deliverables from milestone schedules
• Cost Overrun - >5% but <10% increase to budgeted $
• Technical - Inability to meet power, weight, size, and/or performance requirements, major science objectives not fully met
• Political - Sr. Management or PMC concerns about mission success or development progress

Low

• Schedule Slip - >1 month <4 month delay of deliverables from milestone schedules
• Cost Overrun - <5% increase to budgeted $, impact to contingency $
• Technical - Loss of design margins, some wanted or desired science objectives are not met

Negligible

• Schedule Slip - <1 month delay of deliverables from milestone schedule
• Cost Overrun - minor impact to contingency $
• Technical - small impact to design margins, some desired technical performance not completely met

High (>70% chance of occurrence)

• Occurrence is very likely and may not be controlled by following existing processes, procedures, and plans.

Significant (40% - 70% chance of occurrence)

• Occurrence is likely and may not be entirely controlled by following existing processes, procedures, and plans.

Low (20 % - 39% chance of occurrence)

• Occurrence is unlikely and may not be entirely controlled by following existing processes, procedures, and plans.

Negligible (< 20% chance of occurrence)

• Occurrence is very unlikely and is generally controlled by following existing processes, procedures, and plans.

Timeframe Classification

Near - Action or mitigation needs to take place within the next 4 months

Mid - Action or mitigation needs to take place between 4 months and 8 months

Far - Action or mitigation needs to take place beyond 8 months

Once risk items are entered and classified in the [Risk Information Sheet, Risk Form, Risk Database], the risk will be assigned an exposure grade (Red/Yellow/Green) based on the following combinations of the impact/likelihood.

Items classified as Green are acceptable without further mitigation and shall be routinely tracked for change in status or closed.

Items classified as Yellow may require mitigation. For these items, alternative dispositions will be identified and trade-offs conducted to determine the mitigation required. Future decision milestones will be identified to enable effective tracking of those risks for which immediate action is deemed not necessary.

Items classified as Red are considered primary risk drivers. For these items, mitigation options will be developed. Red risks will be assessed for impact to budget reserves, and will be tracked to closure.

Timeframe is used in conjunction with the Risk Classification Chart to determine priorities, establish when risks need to have actions taken, and how long risks may need to be watched or tracked before they no longer are a concern or can be closed.

This section describes how the risk information will be documented, retained, controlled and utilized.

Maps of the risk management activities against the project milestones shall be developed. This includes established baselines, major reviews of risk status, and routing activities. The following milestones shall be used:

• Weekly project and IPT meetings shall include risk status
• Monthly project meetings shall include risk status using Stoplight Charts
• The status of each IPT Top 20% risks shall be summarized and reported to the Zeus Project Manager on a monthly basis.
• The baseline set of risks shall be reviewed and re-established at significant project milestones (e.g. PDR, CDR, RRR, and FRR).

All risk information shall be documented in the [Risk Information Sheet, Risk Form, Risk Database]. The following reports, forms, spreadsheets, and templates shall be developed and used during the execution of the Zeus Project RM process:

• Risk Implementation Plan
• [Risk Information Sheet, Risk Form, Risk Database]
• Spreadsheet Risk Tracking Reports
• Stoplight Status Charts
• Tracking Metrics and Trend Analysis Charts

Once a risk has been assigned to an IPT member, that person will be responsible for updating the risk information. The updating of risk information shall be performed using the [Risk Information Sheet, Risk Form, Risk Database]. The designated IPT member shall also be responsible for documenting the lessons learned before closing the risk.

This section identifies the resources required for the RM activities.

The Zeus Project resources (cost, staff, equipment, software) for the activities of risk management shall be identified. The resources for the management of risks can be broken down into [2] categories:

• Overhead costs associated with the setting up and establishing the risk management process: [1%] of the project budget.
• Risk Mitigation and Control costs: resources associated with executing mitigation tasks and actions, resources allocated to planning, research and reporting.

Purpose: This section documents how the practice of Risk Management (RM) will be designed and installed into the Zeus project. It specifies the process for putting the defined Zeus RM practice in place.

Sponsorship for this effort is being supplied by David Jones, as project manager for Zeus and Bill Smith, as program manager.

The sponsors shall provide continual, visible support for this effort at all levels of the organization. This shall include the following:

• Smith’s report of status at the quarterly Management Reviews
• All sponsors’ written endorsement and encouragement of this effort to all Zeus project personnel
• David Jones attendance at first kick-off meeting with Zeus personnel and periodic attendance at Zeus meetings
• Monthly status meetings held with the sponsors and change agent, Mike Jackson.
• Sponsors shall allocate budget to this effort as specified in Section 7.4
• Any further supportive announcements or activities as recommended by Mike Jackson.

The Zeus Project Manager shall make monthly progress reports on the success/difficulties of implementing risk management (see Section 7.6, Risks and Mitigation Strategies for this Implementation Effort). Requests for assistance from OSSMA in the form of training, process definition and improvement, etc. should be made on an as-needed basis. Roll-up of all project data into the [risk database or risk spreadsheet] is required on a quarterly basis.

In the event of personnel changes in the sponsors, this implementation plan must be reevaluated and re-approved. Summary reports of progress to date may be required from the project manager.

This section identifies the roles and associated responsibilities for this transition effort. Note that one person may fulfill multiple roles. Sponsors were identified in the previous section.

These roles need to be filled in order to support the transition of RM into the Zeus Project.

• Champion: Someone from within the project, preferably from the managerial level, to provide motivation and leadership. This person will be responsible for encouraging and reinforcing the proper management of risks and open communication of risks as part of his/her routine activities, and assisting in periodic evaluation of this transition effort.
• Assigned to: Nick Faldo/John Doe.
• Change agent: Expected to be provided from outside the project/program. This person will be responsible for coaching project personnel in the accomplishment of risk management activities. Estimated time requirements are 5 hours per week, on average. Will also train project personnel in the tailored risk management practice and assist the champion and program manager in locating tool training (as needed). This person should have training and leadership skills.
• Assigned to: Mike Jackson
• Facilitation team: Require two from outside the project and two from inside the project. Facilitation skills are needed or training must be provided. At least two members of this team should be experienced facilitators. Facilitators will be called upon to help the project whenever facilitation is required to handle issues or carry out specific methods or procedures that require a facilitator. This team will also assist in the establishment of the risk baseline. Estimated time commitment: Baseline establishment – two person weeks each; routine assistance – one hour/week each (on average) but expect a higher peak in early phases.
• Assigned to: N. Faldo, John Doe, Mike Jackson, and TBD

These are the roles and responsibilities of the Zeus project personnel.

• Take RM training: When training in tailored risk management practice for Zeus is made available, all project personnel are expected to take the training. Schedule allowances will be made by the project manager to accommodate near-term deadlines.
• Conduct risk management activities: Project personnel are expected to carry out the risk management activities that are defined in this plan, Sections 1 – 6.
• Facilitation team members (see Section 7.2.1): Two project personnel will be assigned to this team. Work allocations will be adjusted by management to accommodate duties.
• The initial entry of baseline risk information into the database shall be performed by RM Workshop attendees.
• It is expected that all project personnel will participate in the performance of risk management activities. Data entry for the database shall be carried out by anyone identifying a new risk or whoever is responsible for the risk.
• M. Jackson will serve as a general source of risk management expertise during this period. The facilitation team members will continue to provide facilitation on an as needed basis.

7.3 Schedule of Activities

The initial milestones for developing a risk management plan are

• Document draft Zeus RM plan (the tailored practice for Zeus):   5/7/98
• Final Zeus RM plan: 6/30/98

Basic RM Practice Phase

The basic risk management practice to be installed first includes the following:

• All risk management activities at all levels of the Zeus project organization
• Database installed, tested, and all forms and templates to support the methods and tools incorporated

The methods and tools to be used include everything but the mitigation status report and stoplight status report, which shall be held for later.

The detailed milestones for installing the basic practice are as follows:

• Prototype risk database from SR & QA is installed and tested: _______: (date).
• Tailored risk management training is developed by Mike Jackson and facilitation team; (date).
• All project personnel are trained on risk database and tailored risk management process: (date).
• All top baseline risk areas have completed mitigation plans; plans are in place and in progress: (date).
• Individual access to database for risk identification is available and is being used or risk database administrator is in place: (date).
• Weekly status meetings include risk as discussion topic using spreadsheet: (date)
• All risk information is being maintained in the risk database and risk information sheets are used as individual risk reports: (date).
• New risks are being prioritized and action plans are being built: (date).
• Progress Evaluation Points: (date, date).

The following will be implemented during the improvement cycle.

• Monthly status meetings are using Stoplight Status Reports to include Top 20% risk status to Zeus Project Manager.
• Mitigation Status Report is used for one of the top risks (provided its use is justified) by (date).
• Ability exists when printing risk spreadsheets to filter out risks not assigned to anyone in a specific work group.
• New trending report is added to show average time required to close a Top 20% risk; average time Top 20% risk spends on watch list before final closing; average time to build mitigation plan; distribution of risks to responsible person: (date).
• Zeus viable procedure is tested for calculating actual mitigation costs against potential loss due to the risk: (date).

Progress evaluation points: 10/30/98, 11/30/98, 12/30/98, 1/30/99, 2/28/99, 3/30/98.

Based on evaluation, M. Jackson and David Jones present findings to other sponsors on (date –TBD). Decision on whether or not to use risk management.

Funding is provided at the following levels:

• SR & QA: $4,500 for tools and training
• Zeus: 1% of the project budget for project personnel to install RM e.g. database administrator, data entry, Risk Baselining, status report generation, metrics development.

This risk management transition effort will be considered a success if the following outcomes have been met:

1.   An effective risk management practice is in place in the Zeus Project (document any major problems averted through management of risk in lessons learned part of risk database – collect for evaluation points as part of judging effectiveness of practice).

Measures to be used to evaluate the first outcome are

• The number and severity of problems discovered late in the development lifecycle has decrease by at least 80% compared to (typical or previous) NASA projects

• 80% of project personnel and all managers find risk management has improved their ability to manage their tasks and make the right decisions

• Majority of project personnel do not find the practice to be unduly burdensome or inefficient

• The estimated savings due to problems that were avoided is approximately equivalent to or greater than the resources invested in risk management by the Zeus project.

The following are the risks that the sponsors recognize as associated with this effort. Contingency or mitigation actions are also described.

1.  Too resource intensive: Resources used to perform risk management will be estimated and tracked. If resource usage exceeds 5% of personnel time on average with no visible benefit (in terms of significant problems avoided or reduced) by the first evaluation point, then the sponsors will revisit their decision to use risk management on this project.

2.  Ineffective basic risk management practice: If the tailored risk management practice designed for the Zeus project needs improvements or changes to more than 50% of it after two months of use, then the sponsors will revisit their decision and determine if a second attempt at tailoring the process is needed or if it is now too late to complete this effort with Zeus.

3.  Unmotivated project personnel: The project personnel may find this too burdensome and not see the long-term benefits. Mitigation: Will brief the entire project early on to introduce the concept of risk management and demonstrate the sponsorship this effort has. Adjust project schedule, if needed, to allow for start-up time. Need to make sure people do not think more work is being piled on with no extra time to accomplish this. Sponsors/project manager need to stay alert to this issue.

4.  SR & QA database may not be useful. If it is not, the implementation schedule in this plan will slip by at least three weeks while we build an appropriate risk database. Testing on the SR & QA database will begin as soon as possible, using their equipment while waiting for the database to be installed on Zeus equipment. This should provide an answer on the database’s effectiveness a week sooner.

M. Jackson has already been trained in conducting workshops for establishing a baseline set of risks and has trained the other members of Zeus’s facilitation team. The methods to be used include the following, taken form the Software Engineering Institute’s Continuous Risk Management Guidebook and workshops:

• SEI Risk taxonomy-based interviews to be conducted with peer groups selected by Mike Jackson, David Jones and Team Brainstorming.
• Tri-level attribute evaluation
• Classification by root cause of risk using the WBS and also Affinity Grouping
• Prioritization using multi-voting
• Planning the top three or four risk areas using problem-solving planning using the CRM Workshop results

The Facilitation team will be led by Nick Faldo and will turn over all results to David Jones, who will also report a summary of the results to Bill Smith.

Lessons learned from this baselining process will be used during the tailoring step to help tailor a more suitable process for these types of projects. Lessons learned will be documented by John Doe and will be supplied to the sponsors.

Copyright © 1999
Software Assurance Technology Center
This page was last updated on:
05/12/99