Content
1. Introduction
2. Completed Plan Risk Information Sheet
5. Mitigation Planning Worksheet Example
Introduction
In module 8 the risk
information sheet after plan is given. For Risk ID 7 an example of the
associated task plan is presented with its format. Then the mitigation sheet
for risk ID 7 both before and after the team has mitigated the risk is given.
The method, tools, and problem solving are presented in tabular form.
Completed Plan Risk Information Sheet
A completed risk information sheet for Plan is given in Figure Completed Plan Risk Information Sheet.
|
ID 11 |
Risk Information
Sheet After Plan
|
Identified: _9/_1/_02_ |
||||||
|
Priority Probability Impact |
7 M M |
Statement It has recently been decided that the Infrared sensors will be developed in-house and how they will communicate and how sensor data will be processed will be based on assumptions until the detailed design is baselined; the accuracy and completeness of those assumptions will determine the magnitude of change in the IR-SIP Instrument Controller CI and Infrared Sensing Unit CI interface requirements - it could be minor or catastrophic. |
||||||
|
Timeframe |
N |
Originator J. Helm |
Class Requirements |
Assigned To: A. Henry |
||||
|
Context The AA program is in the Systems Preliminary Design Phase and the IR-SIP project software is in the Software Specification Phase.
|
||||||||
|
Approach: Research / Accept / Watch / Mitigate [Mitigation goal/success measures: Reduce the probability and impact of incorrect interface assumptions to a minimum: estimated low probability and low impact. Ideally, completion of prototype tests will show that assumptions we got from EasySensor were correct and there is no impact at all.]
2.
Mitigation Strategy (cont.)
|
||||||||
|
Contingency Plan and Ttrigger Trigger: If the 2/12/02 or 2/28/02 dates cannot be met, put the contingency plan in place. Contingency Plan: Elevate this as one of the top 10 project risks and request that project reserves be used to pay for additional contract support to get the two sets of requirements firmed up (i.e., configuration and data transfer). If additional contract resources are not available, slip the schedule for completion of the prototypes to be done by March 20, and request that project reserves be used to pay for additional resources to be added to the software design and implementation to make up the schedule slip. |
||||||||
|
Status |
Status Date |
|||||||
|
|
|
|||||||
|
|
|
|||||||
|
|
|
|||||||
|
|
|
|||||||
|
|
|
|||||||
|
Approval __________________________ |
Closing Date __/__/__ |
Closing Rationale |
||||||
|
|
|
|
|
|
|
|
|
|
Figure Completed Plan Risk Information Sheet
Task Plan Example
In this section you will look at a particular risk ID 7, the associated task plan, the mitigation sheet before and after the mitigation action. Each of these artifacts would be developed and sustained in the risk team database during the products life cycle.
Risk ID 7 is: "Science requirements have substantial TBDs; late completion of TBDs likely, with reduction in adequate testing time, possible science application software failure, incorrect science data being captured, hardware damage if incorrect safety limits were provided, extensive rework and substantial cost overruns, mission failure if problems not found before system is in operation."
The Task Plan is a complex
type of mitigation plan that should be similar to a project's standard task
plan. It is used for complex risks or sets of risks or complex, expensive
mitigation plans that require extensive details relevant to scheduling,
budgets, actions, contingency plans, task interrelationships and dependencies.
Case Study Task Plan
The following is an example of a Task Plan for risk ID 7.
Task Plan
Responsible Person: A. Henry (for approval); C. Lopez (for recommendations and implementation)R. C. Everette
Last Updated: 1/28/02
Origination date: 1/14/02
Risk Statement
Risk # 7
Science requirements have substantial TBDs; late completion of TBDs likely, with reduction in adequate testing time, possible science application software failure, incorrect science data being captured, hardware damage if incorrect safety limits were provided, extensive rework and substantial cost overruns, mission failure if problems not found before system is in operation.
Classification: Requirements
Related risks: None
Identified causes
Inadequate scheduling to allow
for requirements definition
Inadequate civil service and
contractor personnel resource planning
All of the science
requirements are still not available
Mitigation goals/success measures/criteria
The goal of this task plan is to
Complete the science requirements and submit the change for implementation WITHOUT slipping the overall development completion date. It is preferable to not use overtime or additional resources.
Chosen Strategies
The selected strategies to address the key causes and to reach the mitigation goal are
To analyze, research, and
complete the TBD science requirements, and to submit change requests
To reprioritize the baselined
requirements and reorder the builds to minimize impact of TBD's
Specific actions
The following work breakdown structure (WBS) describes the actions thatwhich will be performed as part of the mitigation plan and identifies who is responsible for completing them. This information will also be reflected in a Gantt chart.
1.0
Reprioritize the baselined requirements and reorganize the builds to implement
the high priority requirements first. The likelihood of their changing will be
factored into the prioritization process.
(J. HenryR. C. Everette)
1.1 Identify
requirements with high probability of change. (C. Lopez)
(J. Johnstone)
1.2 Identify critical path dependencies among requirements and software modules. (C. Lopez)
1.3 Build a prioritized list of requirements. (C. Lopez)
1.4 Reorganize the contents and schedule of builds to meet the new priorities. (C. Lopez)
1.5 Distribute the changes in build content and schedule to all personnel, and tell the customers that no changes to a specific build will be accepted once implementation of that build has begun (except for corrections to requirements errors that would cause mission failure). (A. Henry)
2.0 Estimate the impact to
the schedule for builds and requirements based on the projected completion of
the TBD requirements. Verify (as muchbest as possible) that the new schedule
accounts for the anticipated changes.
(C. Lopez)
3.0 Complete the
requirements document for TBD Requirements 38-42 and submit a change request.
(A. Henry/NASA)
3.1 Estimate the intermediate completion milestones.
3.2 Report progress weekly.
3.3 Complete peer review requirements.
3.4 Submit change requests upon the completion of the requirements.
4.0 Complete the
requirements document for TBD Requirement 73 and submit a change request.
(A. Henry/NASA)
4.1 Estimate the intermediate completion milestones.
4.2 Report progress weekly.
4.3 Complete peer review requirements.
4.4 Submit a change request upon the completion of the requirements.
5.0 Complete the
requirements document for TBD Requirement 104 and submit a change request.
(Mary Bell/NASA)
5.1 Estimate the intermediate completion milestones.
5.2 Report progress weekly.
5.3 Complete peer review requirements.
5.4 Submit a change request upon the completion of the requirements.
6.0 Complete the
requirements document for TBD Requirements 143-149 and submit a change request.
(Joe Kid/University InternUVA)
6.1 Estimate the intermediate completion milestones.
6.2 Report progress weekly.
6.3 Complete peer review requirements.
6.4 Submit change requests upon the completion of the requirements.
7.0 Set up a tracking mechanism for change requests and help C. Lopez determine the magnitude of the problem created by change requests. Weekly reports will be provided to C. Lopez. The reports will include the impact to the schedule and the resources required to implement each submitted change. (A. Henry)
7.1 Design a weekly status report.
7.2 Set up automated metrics collection and reporting.
Risk tracking indicators
TBD requirements completion:
Indicator: Actual completion dates compared to planned completion dates
Trigger: a projected 10% schedule slip in the completion of any requirements document is cause for review.
Trigger: a projected 25% schedule slip in the completion of any requirements document will trigger contingency plan A.
Change request magnitude
Indicator: the cumulative schedule impact due to the changes (based on submitted change requests)
Indicator: the cumulative resource requirements required to implement the changes (based on submitted change requests)
Trigger: if either the cumulative schedule impact indicator or the cumulative resource requirements indicator exceeds their projections by 20%, it will trigger contingency plan B.
Budget
Planning/oversight:
A/C. Lopez: 5 days
Completing TBD requirements:
3 team persons: 14 weeks, no cost
1 university intern: 7 weeks, $10,000
Reprioritizing:
C. Lopez: 7 days
2 team members: 1 day each to review
Tracking costs:
1 team person: 3 days to set up automated system;
C. Lopez &
A. Henry: 2 days each to determine tracking measures, triggers, report format,
and intermediate triggers. (Cost to produce weekly reports is negligible)
Totals:
Person service time: 18-person weeks
University Intern cost: $10,000.
Expected return: The number of errors is projected to decrease by approximately 75%. The amount of resources assigned to late requirements changes should decrease accordingly by 75%. For this project, the total estimated savings is 50% of the total planned budget. The probability for mission failure due to this risk will be eliminated.
Schedule (Gantt chart)
|
Action |
Start Date |
End Date |
|
1 |
February 15, 2002 |
March 15, 2002 |
|
2 |
February 15, 2002 |
March 15, 2002 |
|
3 |
March 1, 2002 |
May 7, 2002 |
|
4 |
March 1, 2002 |
March 15, 2002 |
|
5 |
May 24, 2002 |
July 15, 2002 |
|
6 |
June 1, 2002 |
July 21, 2002 |
|
7 |
February 15, 2002 |
July 21, 2002 |
Contingency strategies, actions, and triggers
Contingency Plan A:
Trigger: Aa projected 25% schedule slip in the completion of any requirements document
Strategy/actions: Aauthorize contractor overtime to assist civil service (a maximum of 10 person weeks in contractor time is allowed). Approval by A. Henry is required.
Contingency Plan B:
Trigger: When either the cumulative schedule impact indicator or the cumulative resource requirements indicator exceeds its projections by 20%
Strategy/actions: Drop the lower-level science requirements to compensate make up for the estimated development time required to complete the higher-priority requirements.
End of Case Study
Mitigation Planning Worksheet Example
This following is an example of a Mitigation Planning Worksheet it is NOT the Risk Information Sheet. The manager, A. Henry has begun to document the goals of her mitigation activity for risks ID 7 assigned to her.
|
Mitigation Planning Worksheet |
|||
|
Risk ID 7 |
Responsibility: A. Henry |
||
|
Risk statement Science requirements have substantial TBDs; late completion of TBDs likely, with reduction in adequate testing time, possible science application software failure, incorrect science data being captured, hardware damage if incorrect safety limits were provided, extensive rework and substantial cost overruns, mission failure if problems not found before system is in operation. |
|||
|
Mitigation goals and constraints (in observable terms) Science requirements must be completed and all related change requests submitted for implementation. No slipping of the overall development completion date is allowed. Preferable to not use overtime or additional resources but if necessary to keep completion date, do so. |
|||
|
Additional data (e.g., root causes, impacted elements) |
|||
|
Related risks |
|||
|
Alternative strategies/actions |
Estimated costs |
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
Related mitigation plans |
|||
|
Strategy evaluation criteria |
|||
|
Chosen strategy/actions |
Success measures |
||
|
|
|
||
|
|
|
||
|
|
|
||
|
Contingency strategy |
Contingency trigger |
||
|
|
|
||
|
|
|
||
|
|
|
|
|
The mitigation planning worksheet has been completed by A. Henry and is given the following table. She has assigned alternative strategies, actions, and estimated costs.
|
Mitigation Planning Worksheet |
|||
|
Risk ID 7 |
Responsibility JResponsibility A. Henry |
||
|
Risk statement Science requirements have substantial TBDs; late completion of TBDs likely, with reduction in adequate testing time, possible science application software failure, incorrect science data being captured, hardware damage if incorrect safety limits were provided, extensive rework and substantial cost overruns, mission failure if problems not found before system is in operation. |
|||
|
Mitigation goals and constraints (in observable terms) Science requirements must be completed and all related change requests submitted for implementation. No slipping of the overall development completion date is allowed. Preferable to not use overtime or additional resources but if necessary to keep completion date, do so. |
|||
|
Additional data (e.g., root causes, impacted elements) Root causes - incomplete definition of requirements in early phases and inadequate scheduling to allow completion; poorly planned use of personnel (civil service and contractor); insufficient funding for contractor personnel and not enough civil servants to make up for it; science requirements not available in early phases. |
|||
|
Related risks None |
|||
|
Alternative strategies/actions |
Estimated costs |
||
|
Initiate an extra contractor task to analyze, complete, research, and complete the TBD requirements |
$70,000 |
||
|
Analyze, research, and complete TBD science requirements and submit change requests ASAP - use civil service and contractor |
$10,000 |
||
|
Authorize contractor overtime until all requirements are complete |
$105,000 |
||
|
Wait and see how bad it gets - slip schedule then if need to (AA satellite completion is probably going to be late as well) |
Worst case: $3 -8 million |
||
|
Reprioritize baselined requirements and reorder builds to minimize impact of TBDs |
1 person week (civil service) |
||
|
Related mitigation plans None |
|||
|
Strategy evaluation criteria Minimal contractor cost, no completion date slippage |
|||
|
Chosen strategy/actions |
Success measures |
||
|
Analyze, research, and complete TBD science requirements and submit change requests ASAP - use civil service and contractor |
All TBD requirements completed by July with no overtime required |
||
|
Reprioritize baselined requirements and reorder builds to minimize impact of TBDs |
Build order is not impacted by change requests from TBD requirements |
||
|
Track progress and use contingency if necessary |
Management is not surprised by failure of mitigation plan |
||
|
Contingency strategy |
Contingency trigger |
||
|
Authorize contractor overtime to assist civil service. Up to 10 person weeks in contractor time allowed. Approval by Henry required. |
Weekly status reveals that TBD requirements are not going to be documented and closed by the due dates |
||
|
Drop lower level science requirements to make up for estimated development time required to complete higher priority requirements. |
Insufficient time in schedule to complete all requirements (as calculated by projected impact of schedule and resource hits from change requests and current progress on implementation) |
||
|
|
|
|
|
The task plan and the
mitigation plan have given you two example and format templates that you can
use and follow for risk planning. Next more methods and tools are given.
Method and Tools
The methods and tools for
plan are repeated in this module and given in the following table.
|
PLAN Tools |
|
|
Methods & Tools |
Definition |
|
Action item lists document risk mitigation actions. They describe an action or list a series of actions to take to mitigate the risk. Even though they do not contain enough detail to support complex risk mitigation strategies, it is sufficient for simple mitigation plans. A good supporting tool to use with an action item list to document causes of risk, alternative actions, and related information is the Planning Worksheet |
|
|
Baseline planning method develops mitigation plans or strategies across sets of related risks. These sets are identified during Baseline Identification and Analysis. Baseline planning is performed effectively through a series of group planning and follow-on integration sessions to deal with the sets of risks. Risks dealt here are those for which a task plan is required for mitigation, not sets of risks which can be accepted or watched at the time. |
|
|
A planning decision flowchart is a tool to aid in risk planning (as a checklist). It also gives a detailed view of the progressive decisions that are made during risk planning. |
|
|
A planning worksheet is a simple tool used to document risk information on alternative mitigation actions and strategies. Individuals or groups use it as they develop mitigation plans as they become available. Once decision has been made on which mitigation strategies to take, the chosen strategy can then be moved to another form, such as an Action Item List. |
|
|
A risk information sheet is a means of capturing information about a risk. Risk information sheets are used to document new risks as they are identified. They are also used to modify information as risks are managed. It is a form that can be submitted to the appropriate person or included in a database with other project risks. In the absence of a database, this becomes a primary means of documenting and retaining information about a risk. |
|
Problem-Solving Planning
Problem solving is another
plan tool with its own set of methods and tools. These methods and tools are
given in the following table.
|
PLAN Tools |
|
|
Problem-Solving Planning |
|
|
Methods and Tools |
Definition |
|
Affinity grouping organizes large numbers of data (risks) into groupings of related items and ties similar groups together. The outcome forms a structure of related items. |
|
|
Brainstorming is a group process wherein individuals quickly generate ideas on a particular problem. Participants verbally identify ideas as they think of them, providing opportunities for others to build upon or spring off each other's ideas. The technique is an excellent way of bringing out the creative thinking from a group. The emphasis is on the quantity of ideas, not the quality. Criticism or evaluation of ideas is not performed at this time. |
|
|
Cause and effect analysis is a process for graphically representing the relationships between a risk (effect) and the possible factors that can cause it. The analysis start out with the risk and participants identify and verify the factors, which are causing the risk or set of risks, or even the other factors. |
|
|
Cost-benefit analysis is a method to compare total cost and benefits estimates of a risk mitigation strategy. The precise cost of benefits is not calculated but the ratio on benefits to costs to decide or to support a decision on alternative strategies, picking the strategy with the highest ratio, while falling within the overall cost constraints. |
|
|
A Gantt chart is a management tool to graphically represent schedule, project activities, activity durations (start and end date), the responsible persons, as well as assumptions, contingency plans (if assumptions are not met) and triggers for the actions. |
|
|
Goal-question-measure (GQM) is a method for stating goals and deriving from them questions that could directly be used to generate measures. The questions help quantify the goals from which a measure for the mitigation goal is identified. From these measures, project personnel identify indicators to track risks and mitigation plans. Indicators can be one or a combination of the measures identified. GQM is adapted from the method for collecting valid software engineering data by Basili and Weiss to help risk mitigation planners determine the indicators to track the progress and changes in status of a mitigation strategy. |
|
|
Interrelationship digraph is a method to identify relationships among a set of items. Items that have a cause or effect associated on another item are linked together (and given weight) for the purpose of identifying the items most affected or items affecting other items the most, giving emphasis on those items for risk mitigation planning. Items involved in risk management could be risks being mitigated, risk strategies, project activities or resources. |
|
|
List reduction is the simplest method to reduce a large number of project risks items into a manageable number. It involves clarifying project options to group members to make the right decisions. Without the shared understanding of the items, the process may take longer to finish. |
|
|
Multivoting is a general voting method used to select the most important items from a list. Selecting the number of votes to be used depends on the number of items on the list. In risk management, each participant is given a number of votes to choose the top risks in the list according to them. A general rule of thumb is to allow participant votes equal to one-third the number of items on the list. For a large number of items, a series of votes is used to reduce the list to a workable number. |
|
Plan Key Points
In module 8 you were given the risk information sheet after plan, an example of a risk with the associated task plan, the mitigation sheet before and after the risk was mitigated. The method, tools, and problem solving were also given.
The risk team should mitigate, prevent or reduce what they believe to be unacceptable risks. In this way the team can take risks knowingly and with the understanding of what the project will possibly gain or lose.
The risk team can't mitigate all risks. There will always be some risks associated with the project. The key is to know what the project and the project team members are potentially going to encounter.
The risk team should watch risks they choose not to mitigate but don't accept. The team must be on the vigil for significant changes or triggers, and then decide if they need to do something about the risk.
Risks that are not assigned to someone to manage tend to get lost and become problems without warning.
Use task plans sparingly - they are rarely needed for any risks other than those of high complexity or those that impact project plans and schedules.