Table of Contents | Appendix C-4 | Appendix C-6
1.0 INTRODUCTION
1.1 Purpose
In this section, present a clear, concise statement of the purpose of the Risk Management (RM) plan. Include the name and code name of the project, the name(s) of the associated system(s), and the identity of the organization that is responsible for writing and maintaining the RM plan.
1.2 Background
This section briefly describes the history of the project and the environment in which the project will operate. (This information may be included through reference to other project documents.) Include the following information:
• Identification
of other systems with which the subject system interfaces
• Contractor support
for development and maintenance
• System architecture,
operating system, and application languages
• Development methodology
and tools used for the project
1.3 Scope
This section presents a definitive statement of the scope of the RM planning contained in this document, including the limits and constraints of the RM plan.
1.4 Policy
Include in this section policy decisions that affect how RM is conducted. This section also lists documents that are referenced to support the RM process. Include any project or standards documents that are referenced in the body of the plan or that have been used in the development of the document.
1.5 Approach
In this section, describe the project's approach to risk management. Include the elements of identification, analysis, planning, tracking, control, and communications. Discuss the project's risk mitigation strategies in general and detail specific strategies that have significant impact across the project (e.g., parallel development, prototyping).
2.0 RISK IDENTIFICATION LIST
The tracking of risks in a risk identification list is a critical facet of successful system development management. The risk identification list is used from the beginning of the project and is a major source of input for the risk assessment activity. Following are examples of categories that may be a source of risk for a system development:
• The complexity,
difficulty, feasibility, novelty, verifiability, and volatility of the system
requirements
• The correctness,
integrity, maintainability, performance, reliability, security, testability,
and
usability of the SDLC
deliverables
• The developmental
model, formality, manageability, measurability, quality, and traceability
of the processes used
to satisfy the customer requirements
• The communication,
cooperation, domain knowledge, experience, technical knowledge,
and training of the personnel
associated with technical and support work on the project
• The budget, external
constraints, politics, resources, and schedule of the external system
environment
• The capacity, documentation,
familiarity, robustness, tool support, and usability of the
methods, tools, and supporting
equipment that will be used in the system development
Once the risks have been identified, document them in this section as the risk identification list. Steps for developing the risk identification list are the following:
• Number each risk
using sequential numbers or other identifiers.
• Identify the SDLC
document in which the risk is applicable. For instance, if you are
working on the CM plan
and discover a CM risk, identify the CM plan as the related
document.
• Describe the risk
in enough detail that a third party who is unfamiliar with the project can
understand the content
and nature of the risk.
Use the risk identification list throughout the life-cycle phases to ensure that all risks are properly documented.
3.0 RISK ASSESSMENT
The project management plan and the risk identification list are inputs to the risk assessment. Categorize the risks as internal or external risks. Internal risks are those that you can control. External risks are events over which you have no direct control. Examples of internal risks are project assumptions that may be invalid and organizational risks. Examples of external risks are Government regulations and supplier performance.
Evaluate the identified risks in terms of probability and impact. For each risk item, determine the probability that this will occur and the resulting impact if it does occur.
Use an evaluation tool to score each risk. For example, a simplistic model could be:
Assign numerical scores to risk probability (1=low, 2=moderate, 3=high) and severity of impact (1=low, 2=moderate, 3=high). A risk score would be the product of the two scores. Management attention would be then be focused on those risks with a score of 9, followed by 6, etc.
4.0 RISK ACTION PLAN
Review the risk items with high rankings from Section 3 and determine if the significant risks will be accepted, transferred, or mitigated. With the acceptance approach, no effort is made to avoid the risk item. This approach is usually employed because the risk items are the result of external factors over which you have no direct control. Two types of action are usually taken under the acceptance approach: contingency planning and no action. You can plan contingencies in case the risk does occur. Thus, the project team has a backup plan to minimize the affects of the risk event. Or you can take no action and accept responsibility if the risk event does indeed occur. With the transfer approach, the objective is to reduce risk by transferring it to another entity that can better bear it. Two methods of transferring risk are the use of insurance and the alignment of responsibility and authority. With the mitigation approach, emphasis is on actually avoiding, preventing, or reducing the risk. Some risks can be avoided by reducing the number of requirements or defining them more completely. For example, careful definition of the scope of a project in a SOW can avoid the possible consequence of "scope creep," or indecisive, protracted, and uncertain scope objectives.
In this section, identify and describe in detail the actions that will be taken to transfer or mitigate risks that are prioritized as high in Section 3. These actions should ultimately result in the reduction of project risk and should directly affect the project plan and the metrics used for the project. Activities for reducing the effects of risk will require effort, resources, and time just like other project activities. The actions need to be incorporated into the budget, schedule, and other project plan components. Update the project plan components to ensure the planning and execution of risk action activities. Also, refer to contingency plan documents for any contingency plans that have been identified with the risk acceptance approach. Risk action plans will be used to direct all risk mitigation activities. The RM plan will need to be monitored and updated throughout the life-cycle phases.
Risk Management Outline
1.0 INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 Policy
1.5 Approach
2.0 RISK IDENTIFICATION LIST
3.0 RISK ASSESSMENT
4.0 RISK ACTION PLAN