Table of Contents | Appendix C-4 | Appendix C-6




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).


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
•      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
•      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
•      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.


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.


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.1       Purpose
            1.2       Background
            1.3       Scope
            1.4       Policy
            1.5       Approach




Table of Contents | Appendix C-4 | Appendix C-6