RISK MANAGEMENT PLAN RISK MANAGEMENT PLAN

Overview The Risk Management Plan identifies the risks that can be defined at this stage of the life cycle, evaluates them, and outlines mitigation actions. This Plan will be periodically updated and expanded throughout the life cycle as the project increases in complexity and risks become more defined. 1 1.1 INTRODUCTION 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: 1.3 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

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 projects approach to risk management. Include the elements of identification, analysis, planning, tracking, control, and communications. Discuss the projects risk mitigation strategies in general and detail specific strategies that have significant impact across the project (e.g., parallel development, prototyping).

RISK MANAGEMENT PLAN

2 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 trace ability 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 he 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 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.

RISK MANAGEMENT PLAN

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 (l=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 RISK ACTION PLAN Review the risk items with high rankings from Section 3 and determine if the significant risks will he 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 ease 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 TORFP 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 he used to direct all risk mitigation activities. The RM plan will need to be monitored and updated throughout the life-cycle phases.