Data Flow Notes JC HELM

Content

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:

1. Uncertainty: An event may or may not happen.

2. Loss: An event has unwanted consequences or losses.

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:

1. Identify potential problems and deal with them when it is easier and cheaper to do so - before they are problems and before a crisis exists.

2. Focus on the project's objective and consciously look for things that may affect quality throughout the production process.

3. Allow the early identification of potential problems (the proactive approach) and provide input into management decisions regarding resource allocation.

4. Involve personnel at all levels of the project; focus their attention on a shared product vision, and provide a mechanism for achieving it.

5. Increase the chances of project success.

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)

2. Risk Management and Project Management

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.

3. Why Do Risk Management?

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?"

1. Early identification of potential problems

2. Increase chances of project success

3. Enable more efficient use of resources

4. Promote teamwork by involving personnel at all levels of the project

5. Information for tradeoffs based on priorities and quantified assessment

4. What is Continuous 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:

1. Assess continually what could go wrong (risks)

2. Determine which risks are important to deal with

3. Implement strategies to deal with those risks

4. Assure, measure effectiveness of the implemented strategies

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.

5. Continuous Risk Management Paradigm

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.

6. Components of Continuous Risk Management

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:

1. Mitigate the impact of the risk by developing a contingency plan (with a triggering event) should the risk occur.

2. Avoid a risk by changing the product design.

3. Accept the risk and take no further action, thus accepting the consequence if the risk occurs.

4. Study the risk further to acquire more information and better determine the uncertainty or loss associated with the risk.

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:

Ensure the consequences and sources of the risk are known

Develop effective plans

Plan efficiently (only as much as needed or will not be of benefit)

To produce, over time, the correct set of actions that minimize the risk and impacts (cost and schedule) while maximizing opportunity and value

Plan important risks first

Assign responsibility for tracking and controlling risk

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

1. Understand the project's risks and mitigation alternatives

2. Understand the risk data and make informed choices within the constraints of the project

3. Eliminate barriers to effective communication

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

7. Relationship Among Functions

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:

1. Continuously (risk follow the paradigm until mitigated)

2. Concurrently (risks are tracked in parallel while new risks are identified and analyzed)

3. Iteratively (e.g., the mitigation plan for one risk may yield another risk)

8. Risk Management Data Flow

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.

1. Identify: locate risks before they become problems and to incorporate this information into the project management process.

2. Analysis: convert risk data into decision-making information.

3. Plan: Translate risk information into decisions and mitigating actions (present and future), and implementing those actions.

4. Track: collect accurate, timely, and relevant risk information and to present it in a clear and easily understood manner appropriate to the person/group who receives the status report.

5. Control: make informed, timely, and effective decisions regarding risks and their mitigation plans.

6. Communicate/Document: provide information and feedback to the project on the risk activities, current risks, and emerging risks.

9. Drivers for Continuous Risk Management

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:

1. NASA NPG 7120.5A: NASA Program and Project Management Process and Requirements

2. NASA-SP-6105: NASA Systems Engineering Handbook

3. ISO 9001: Quality systems

4. OMB Circular A-11: Planning, Budget & Acquisition

5. IEEE: P1448 - EIA PN3764 (ISO/IEC 12207): Standard for Information Technology

6. DoD: Military Standard Handbook 338: Electronic & Reliability Design Handbook

7. DoD: Military Standard 499: Engineering Management

10. When should Continuous Risk Management be done?

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.

Figure Risk Process

11. Risk Management Plan

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

1. Introduction: purpose, scope, assumptions, constraints, policies, related documents and standards.

2. Overview of Processes: activities and relationships, process and data flows

3. Organization: responsibilities of project, customer and supplier

4. Process details for each function area

5. Resource and schedule information

There are two templates for you to use as the Risk Management Plan and the Risk Implementation Plan following this set of notes.

12. Who Does Continuous Risk Management?

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:

1. Looking into mirrors

2. Judging distances

3. Using turn signals

4. Handling a skid on ice, etc.

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.

References

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