Last Modified: N/A
Owner: David Jones/Zeus Project Manager
|Section 1. Introduction||3|
|1.1 Assumptions, Constraints, and Policies||3|
|1.2 Related Documents and Standards||3|
|Section 2. Continuous Risk Management Overview||3|
|2.1 Risk Management Process and Data Flow||4|
|2.1.1 Identifying Risks||5|
|2.1.2 Analyzing Risks||5|
|2.1.3 Planning Risks||5|
|2.1.4 Tracking Risks||6|
|2.1.5 Controlling Risks||6|
|2.1.6 Communicating and Documenting Risks||6|
|Section 3. Zeus Risk Management Assignments and Communications Flow||6|
|3.1 Zeus Project Organization||6|
|Section 4. Risk Classification||10|
|Section 5. Zeus Risk Reporting||13|
|Section 6. Zeus Resources||13|
|Section 7. Zeus Risk Management Implementation||13|
|7.1.1 Sponsorship Roles and Responsibilities||13|
|7.1.2 Reporting Requirements||14|
|7.1.3 Sponsorship Changes||14|
|7.2 Roles and Responsibilities||14|
|7.2.1 Infrastructure Roles to be Filled||14|
|7.2.2 Project Personnel Roles||15|
|7.3 Schedule of Activities||16|
|7.3.1 Detailed Transition Schedule Milestones||16|
|22.214.171.124 Basic RM Practice Phase||16|
|126.96.36.199 Improvement Phase||17|
|7.4 Allocated Budget and other Required Resources||18|
|7.5 Evaluation Measures and Completion Criteria||18|
|7.6 Risks and Mitigation Strategies for this Implementation Effort||18|
|7.7 Establish Risk Baseline Method||19|
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.
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.
1.1 Assumptions, Constraints, and Policies
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.
1.2 Related Documents and Standards
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.
2.0 Continuous Risk Management Overview
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:
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.
2.1 Risk Management Process and Data Flow
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.
2.1.2 Analyzing Risks
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.]
2.1.3 Planning Risks
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.
2.1.4 Tracking Risks
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.
2.1.5 Controlling Risks
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.
2.1.6 Communicating and Documenting 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.
3.0 Zeus Risk Management Assignments and Communications Flow
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
Table 1. summarizes the responsibilities of all project personnel performing CRM.
Scientists, Testers, IPT Leads, Instrument Manager, Project Manager,
Universities, Contractors, and Customers
|IPT Leads & Systems Assurance Manager||
|Zeus Project Manager & Instrument Manager||
Table 2. provides the criteria for communicating and documenting risk information.
|Communication Path||Risk to be Communicated/Documented|
|From Individuals/IPT to IPT Leads & SAM||
|From IPT Leads & SAM to Instrument Manager & Project Manager||
|Project Manager to Senior Management||
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 (>70% chance of occurrence)
Significant (40% - 70% chance of occurrence)
Low (20 % - 39% chance of occurrence)
Negligible (< 20% chance of occurrence)
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.
Figure 4. Risk Classification Chart
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.
5.0 Zeus Risk Reporting
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:
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:
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.
6.0 Zeus Resources
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  categories:
7.0 Zeus Risk Management Implementation
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.
7.1.1 Sponsorship Roles and Responsibilities
The sponsors shall provide continual, visible support for this effort at all levels of the organization. This shall include the following:
7.1.2 Reporting Requirements
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.
7.1.3 Sponsorship changes
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.
7.2 Roles and Responsibilities [date updated]
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.
7.2.1 Infrastructure Roles to be Filled
These roles need to be filled in order to support the transition of RM into the Zeus Project.
7.2.2 Project Personnel Roles
These are the roles and responsibilities of the Zeus project personnel.
7.3 Schedule of Activities
7.3.1 Detailed Transition Schedule Milestones [date updated]
The initial milestones for developing a risk management plan are
Basic RM Practice Phase
The basic risk management practice to be installed first includes the following:
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:
188.8.131.52 Improvement Phase
The following will be implemented during the improvement cycle.
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.
7.4 Allocated Budget and other Required Resources [date updated]
Funding is provided at the following levels:
7.5 Evaluation Measures and Completion Criteria [date updated]
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
7.6 Risks and Mitigation Strategies for this Implementation Effort [date updated]
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.
7.7 Establish Risk Baseline Method [date updated]
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:
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: