10.29 Risk Identification List

---

The process 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. The 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 project deliverables

• The developmental model, formality, manageability, measurability, quality, and traceability of the processes used to satisfy 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 include the following:

• Number each risk using sequential numbers or other identifiers.

• Identify the SEP 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.

It is the Project Manager’s responsibility to ensure the Core Team appointed Risk Officer will use the risk identification list throughout the life cycle phases to ensure that all risks are properly documented.

10.29.1 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 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 to assign numerical scores to risk probability (1 = low, 2 = moderate, 3 = high) and severity of impact (same rating system). A risk score would be the product of the two scores. Management attention would then be focused on those risks with a score of 9, followed by 6, and so on.

10.29.2 Risk Action Plan

Review the risk items with high rankings from the risk assessment 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 effects of the risk event. Or, you can take no action and accept responsibility if the risk event does occur.

With the transfer approach, the objective is to reduce risk by transferring it to another entity that can better handle 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 can avoid the possible consequence of scope creep or indecisive, protracted, and uncertain scope objectives.

Identify and describe in detail the actions that will be taken to transfer or mitigate risks that are prioritized as high in the risk assessment. 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. These 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 risk management plan will need to be monitored and updated throughout the SEP life cycle phases.

---