These are a number of definitions and uses for the term risk, but there is no universally accepted definition.
Risk is the potential for realization of unwanted negative consequences of an event.
Rowe, An Anatomy of Risk [Rowe 88]
Risk is the measure of the probability and severity of adverse effects.
Lowrance, Of Acceptable Risk [Lowrance 76]
Risk is the possibility of suffering loss.
Webster, Third New International Dictionary [Webster's 81]
Risk is the probability that a project will experience undesirable consequences.
NASA-NPG: 7120.5A [SEI 92].
This course uses the Webster Dictionary's definition of risk - "Risk is the possibility of suffering loss."
What all definitions have in common is agreement that risk has two characteristics:
Therefore, risk involves the likelihood that an undesirable event will occur, and the severity of the consequences of the event, should it occur. Risk management can:
In a development project, the loss describes the impact to the project. This could be in the form of diminished quality of the end product, increased costs, delayed completion, or failure.
Figure Risk Definition
The Figure Risk Definition illustrate that risk always involves the likelihood that an undesired event will occur and to consider the severity of the consequence in the event it should occur.
Risk = Probability (Likelihood) * Impact (Severity)
Risk management deals with fundamentals of project management. Project managers make decisions. Risk management provides information to the decision makers (project managers) before a problem occurs so that actions can be taken to avoid the potential problem. Therefore Risk Management must be an integral part of a program and not a separate activity.
Continuous risk management can identify potential problems early and deal with them when it is easier and cheaper to do so. Continuous risk management can focus on the project's objectives and consciously look for things that may affect quality throughout the production process. It allows the early identification of potential problems (the proactive approach) and provide input into management decisions regarding resource allocation. It involves personnel at all levels of the project; focus their attention on a shared product vision, and provide a mechanism for achieving it. Continuous risk management encourages overall teamwork. "Risks will find you, it's your job to deal with them."
The answer to "Why Do Risk Management?"
Continuous risk management is software and systems engineering practice with processes, methods, and tools for managing risks in a project. It provides a disciplined environment for proactive decision making to:
Many projects and project managers do a risk assessment at the beginning of a project; they identify a few risks and develop a risk management plan. Then the risk management plan goes into a binder and is put on a shelf and is never looked at again. Risk management is not something a project manager does only once on a project. There is no "risk management season." The risks at the beginning of a project are not necessarily the same risks you have in the middle or near the end. Continuous Risk Management can be applied to hardware, software, and systems. Some of the tools and techniques for each discipline may change and have different names but the techniques remains similar.
Roger L Van Scoy developed the SEI risk management paradigm in 1992 [Van Scoy 92, p.9]. The paradigm illustrates a set of functions that are identified as continuous activities throughout the life cycle of a project.
Figure Risk Management Paradigm
The risk management paradigm, shown in Figure Risk Management Paradigm, is Roger L Van Scoy view of a repeatable process for software risk management. The paradigm is a model of how the different elements of software risk management interact and a framework for describing how software risk management can be implemented. The paradigm has a circular form to highlight its continuous nature. The arrows signify the logical flow of information between the elements of the paradigm. Communication is the core. It is the means by which all the information flows.
Van Scoy summarized the elements in his paradigm as:
Identify - locate risks before they become problems and adversely affect the program.
Analyze - turn the raw risk data into decision-making information.
Plan - turn the risk information into decisions and actions (both present and future).
Track - monitor the status of risks and actions taken against risks.
Control - correct for deviations from the planned risk actions.
Communicate - provide the feedback on the active risk activities, current risks, and emerging risks among the paradigm elements and within the program.
The Continuous Risk Management paradigm illustrates a set of functions that are identified as continuous activities throughout the life cycle of a project. The paradigm is a conceptual or abstract view of risk management. NASA has adopted this paradigm in NPG 7120.5A. You can find these documents by becoming a member of Software Engineering Information Repository
For each element in the paradigm, this course will provide guidance on specific implementation techniques. These techniques will come from existing practice of the NASA NPG 7120.5A and have been developed specifically to support the continuous risk paradigm.
Risk identification is the first element in the risk management paradigm. Before risks can be managed, they must be identified. Risk identification aims to find the major risks before they adversely affect a program. The risk team uses techniques to discover risks by exploiting and communicating the risk knowledge of the program team. The risk team search for and locate risks before they become problems. Therefore, the purpose of Identification is to locate risks before they become problems and to incorporate this information into the project management process. Anyone in a project can identify risks to the project. Each individual has particular knowledge about the project.
A risk is an event that has not happened. A problem on the other hand is a risk that has occurred and now must be treated as a problem. The risk therefore no longer exists because it has now become a problem. A good example is the Titanic. The risk is that the Titanic might hit an Iceberg; the consequence is that it might sink. When it did hit the iceberg this became a problem.
Risk analysis is the next element in the risk management paradigm. Risk analysis is the conversion of risk data into risk management information. Each risk must be understood sufficiently to allow a manager to make decisions. Risk analysis sifts the known risks, and places the information in the hands of the decision maker. Analysis provides the information that allows managers to work on the right risks. The purpose of Analyze is to convert risk data into useable information for determining priorities and making decisions.
Risk planning is needed after a risk is identified and analyzed. This element includes developing actions to address individual risks, prioritizing risk actions, and orchestrating the total risk management plan. An individual risk action plan could take many forms, for example:
The key to risk planning is to translate risk information into planning decisions and mitigating actions (both present and future), and implement those actions
The purpose of Plan is:
Risk tracking is required to ensure effective action plan implementation. This means that the risk team must devise the risk metrics and triggering events needed to ensure that the planned risk actions are working. Tracking is the watchdog function of the risk action plan.
The purpose of Track is to collect accurate, timely, and relevant risk information and to present it in a clear and easily understood manner appropriate to the personal or group who receives the status report. Tracking is done by the person(s) responsible for monitoring "watched" or "mitigated" risks. Project personnel use the status report information, generated during tracking, in the control function of the paradigm to make decisions about managing risks.
Risk control is the next element in Van Scoy's paradigm. Once the risk metrics and the triggering events have been chosen, there is nothing unique about risk management. Rather, risk management melds into program management and relies on program management processes to control the risk action plans, correct for variations from the plans, respond to triggering events, and improve the risk management process. In fact, if risk management is not integrated with day-to-day program management, it will soon be relegated to an ineffective background activity.
The purpose of Control is to make informed, timely, and effective decisions regarding risks and their mitigation plans. Control must also correct for deviations from the risk mitigation plans and decide on future actions.
Risk communication is at the center of Van Scoy's paradigm because, without effective communication, no risk management approach is viable. Communication is critical because it facilitates interaction among the elements of the paradigm. But there are higher-level communications to consider as well. Risks must be communicated to the appropriate organizational levels so the risks can be analyzed and managed effectively. This includes levels within the development organization, within the customer organization, and most especially, across that threshold between the developer and the customer.
The inner circle of the paradigm has evolved into Communicate & Document in order to provide information and feedback to the project on the risk activities, current risks, and emerging risks.
The purpose of Communicate is for project personnel to
Communication and Documentation are present in all the other paradigm functions and are essential for managing risks. Communication of risk information is often difficult because the concept of risk deals with probability and negative consequences
Ronald P. Higuera and David P Gulch presented these continuous risk management functions in the "Proceedings of the Eleventh Annual Pacific Northwest Software Quality Conference in 1993 [Higuera 93]. As each risk is identified it will nominally go through these functions sequentially but the activity occurs continuously, concurrently, and iteratively. The risk identified, is tracked in parallel while new risks are identified and analyzed (concurrently). Once a mitigation plan for one risk is developed, this risk may yield another risk (iteratively). Higuera later published this methodology in 1994 [Higuera 93]. Select this link and read their paper.
Throughout the project life cycle, risk components evolve:
Click on Figure Risk Management Data Flow
Figure Risk Management Data Flow is a data flow of the risk management paradigm. During the course each module will go through this data flow in detail. The elliptical figures represent the functions in the paradigm. Emphasis in Figure Risk Management Data Flow is to show the process of how each elliptical function flows into the next. The following is a brief overview of each function.
Risk management appears in all of these current and future standards and policy. The common message across them is that projects should perform risk management, but these standards and policies do not prescribe how to do risk management.
Program Manager's often don't have the resources needed during a project. Risk Management is one way to save money in the long run.
The following is a list of standards:
Continuous Risk Management is just that, continuous. It starts at the beginning of the project's development and continues in both the hardware and software development process. It continues through to system integration and testing. At any point in the system development cycle, a risk can be identified. The risk process shown in Figure Risk Process is followed to mitigate and eventually the risk is closed.
Click on Figure Risk Process
The Risk Management Plan documents the risk management practice (processes, methods, and tools) to be used for a specific project. A Risk Management Plan document is a subset of other documents in the Project Management Plan Document (e.g., Configuration Management Plan, Quality Assurance Plan, Testing Plan, etc.). It tells the project personnel how they are supposed to manage, track, and document the risks. Content may vary, but the following list address the minimal set of information needed in a Risk Management Plan.
Project Management Plan
There are two templates for you to use as the Risk Management Plan and the Risk Implementation Plan following this set of notes.
Continuous Risk Management is not a job for only the manager or a designated technical lead (e.g., risk manager). Applying Continuous Risk Management is not a job that is assigned to an individual. It takes all members (system engineers, software engineers, code developers, computer engineers, and testers) associated with the project, to successfully implement Continuous Risk Management and manage the risks. Although everyone is involved, it does not mean that every person carries out every task. As with any improvement or transition effort, there are tasks and activities that are best suited to different parts of the organization and individuals in the project.
Learning Continuous Risk Management is similar to incorporating any new habit into your daily life. For example when you first learn to drive, it is hard to remember every step involved:
Eventually these tasks are done automatically, every time you drive a car.
Continuous Risk Management must be learned the same way, it eventually will become part of your routine, everyday activity. This is consistent with the cognitive model of learning: moving from unconscious ignorance through conscious ignorance and conscious knowledge to unconscious knowledge.
[Higuera 93] Higuera, Ronald P. & gulch, David P "Risk Management and Quality in Software Development." Proceedings of the Eleventh Annual Pacific Northwest Software Quality Conference. Portland, Oregon, October 18-20 1993. Portland, Oregon: Pacific Northwest Software Quality Conference, 1993.
[Kirkpatrick 92] Kirkpatrick, Robert J.; Walker, Julie A.; & Firth, Robert. "Software Development Risk Management: An SEI Appraisal." Software Engineering Institute Technical Review 1992 (CMU/SEI-9 REV). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1992.
[Kloman 90] Kloman, H.F. "Risk Management Agonists" Risk Analysis 10,2 (1990): 201-205.
[Lowrance 76] Lowrance, William W. Of Acceptable Risk. Los Altos, Ca.: William Kaufmann, 1976.
[Rowe 88] Rowe, William D. An Anatomy of Risk. Malabar, Fla.: Robert E. Krieger, 1988.
[SEI 92] Software Engineering Institute. "The SEI Approach to Managing Software Technical Risks." Bridge (October 1992): 19-21.
[Van Scoy 92] Van Scoy, Roger L. Software Development Risk: Opportunity, Not Problem. (CMU/SEI-92-TR-30, ADA 256743). Pittsburgh, Pa.: Carnegie Mellon University, Software Engineering Institute, 1992.
[Webster's 81] Webster's Third New International Dictionary. Springfield, MA: Merriam-Webster, 1981.
� January 1, 2006 James C. Helm, PhD., P.E.