At the conclusion of the Introduction, the student will be able to:
Teaching students the continuous risk management implementation is important to
show them how Continuous Risk Management (CRM) will: assist the project management and team members to
establish and use consistent documentation; instantiate and store each
identified risk; associate for each risk a mitigation or task plan; and visually
presents each risk with the capability to be tracked, watched or mitigated
throughout the project’s iterative life cycle.
The
Continuous Risk Management (CRM) paradigm was derived from the Carnegie Mellon
Software Engineering Institute (SEI) and is defined in their CRM Guidebook (Dorofee,
96). CRM 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 risk management process is similar.
Maintaining a corporate risk database allows reuse of successful risk
resolution strategies and a knowledge base of lessons learned. (Hall 97)
Roger L. Van Scoy developed the Carnegie Mellon Software Engineering Institute
(SEI) risk management paradigm in 1992 (Van Scoy 92, p.9).
The paradigm illustrated in Figure 1 is a set of functions that are
identified as continuous activities throughout the life cycle of a project.
The paradigm serves as a model indicating how the different elements of
risk management interact and also as a framework for describing how 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 center of the paradigm. It is
the means by which all information flows.
Van Scoy summarized the elements in his paradigm as:
1.
Identify
- locate risks before they become problems and adversely affect the program.
2.
Analyze
- turn the raw risk data into decision-making information.
3.
Plan
- turn the risk information into decisions and actions (both present and
future).
4.
Track
- monitor the status of risks and actions taken against risks.
5.
Control
- correct for deviations from the planned risk actions.
6.
Communicate
– provide feedback on the active risk activities, current risks, and emerging
risks among the paradigm elements and within the program.
The documentation was added to the paradigm by (Dorofee 96).
The Continuous Risk Management paradigm illustrates a set of functions that are
identified as continuous and iterative 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 guideline NPG 7120.5A (NASA 2003).
Risk identify is the first element in the risk management paradigm.
The goal of risk identify is to locate the risks to be managed
before they can adversely affect a program and to incorporate this information
into the project management process (Rosenau 92).
The risk team uses techniques to discover risks by exploiting the
collective knowledge of the program team.
Since each member of the program team has a particular knowledge about
the project, anyone involved can be useful in identifying risks
Risk analysis is the second element in the risk management paradigm.
The purpose of risk analysis is to convert risk data into useable risk
management information for determining priorities and making decisions.
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 (Air Force 88).
Risk planning is the third element in the risk management paradigm. This element includes developing actions to address individual risks, prioritizing risk actions, and orchestrating a risk action plan for each risk. An individual risk action plan could take many forms, for example:
• Mitigate the
impact of the risk by developing a contingency plan (with a triggering event)
should the risk occur.
• Avoid a risk by
changing the product design.
• Accept the risk
and take no further action, thus accepting the consequence if the risk occurs.
• 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 implementing
those actions. “Attempts to plan for
the elimination of all risks are almost always futile efforts” (Charette 89).
Risk tracking is the fourth element in the risk management paradigm.
The purpose of risk tracking is to collect accurate, timely, and relevant
risk information and to present it in a clear and easily understood manner
appropriate to the personnel or group who receives the status report (Dorofee
96). 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.
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 fifth element in the 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 (Hall 97, Ch. 18).
Risk communication is at the center of Van Scoy’s risk management paradigm
because, without effective communication, no risk management approach is viable
(Van Scoy 92). Communication is
critical because it facilitates interaction among the elements of the paradigm.
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.
Communication is present in all paradigm functions and is essential for managing
risks. Communication of risk
information is often difficult because the concept of risk deals with
probability and negative consequences.
The
risk information sheet records the information gathered during each of the
paradigms function. Figure 2 is an
example format used for a risk information sheet.
The contents in the fields of the risk information sheet are the values
input during the CRM process. A
mitigation or task plan format is also developed for each risk that is mitigated
and tracked. The mitigation or task
plan is also stored in the database and tracked by the associated risk ID.
|
RISK ID |
Risk Information Sheet |
Date Identified:
|
|||
|
Priority |
Risk Statement
|
||||
|
Probability |
|||||
|
Impact |
|||||
|
Timeframe |
Originator |
Classification |
Assigned to:
|
||
|
Context
|
|||||
|
Approach:
Research / Accept / Watch / Mitigate
|
|||||
|
Contingency Plan and Trigger
|
|||||
|
Status
Date_________
|
|||||
|
Lessons Learned
|
|||||
|
Approval
|
Closing Date |
Closing Rationale |
|||
During IDENTIFY the following fields are completed by the project team members:
During ANALYZE the following fields would be completed:
During PLAN the following fields would be completed:
During TRACK the following fields would be completed:
During CONTROL the following fields would be completed:
During continuous COMMUNICATE & DOCUMENTION the following documents
would be selected, initialized, maintained, and tracked: