1 Risk Management
Using standard risk management practices will ease the adoption of the process into the team’s
standard project management process. These standard risk management practices were developed
by the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). The SEI Risk
Management Paradigm is far more comprehensive than is necessary for this project and is scaled
down to fit this project’s requirements. With experience, these practices can be further tailored to
meet the needs of future projects as well.
The following sections will define risk, describe the reasons why this project will be performing
risk management, and define the risk management process for this project.
1.1.1 Definition of Risk
The Pandora team will use the SEI’s definition for risk: the possibility of suffering loss.
1.1.2 Risk Management
For the Pandora project, the purpose of risk management is to prevent risks from becoming
problems. Once risks are manifested as problems, they are much more difficult to resolve due to
lack of time or resources and their impact can be much more harmful.
Another reason why the Pandora project will be performing risk management is because it is a
key process area at Level 3 of the Capability Maturity Model Integrated (CMMI). While
Integrity Applications Incorporated is not a Level 3 organization, implementing risk management
practices will provide benefits even at our Level 1 organization.
1.2 Risk Management Process
The following section will describe the Pandora project’s risk management process, which is
derived from the SEI Risk Management Paradigm.
The Pandora project’s risk management process is derived from the SEI Risk Management
Paradigm (See Figure 1). This paradigm identifies continuous activities that are performed
through the life cycle of a project to manage risks. These activities have been tailored and are
sufficient for our project.
Figure 1: SEI Risk Management Paradigm (Source:
The following sections will elaborate on these activities in more detail.
The first step in identifying risks is creating the “Picture of Success,” the team’s unified
conception of what would make the project successful. From there, the team can identify risks
that would prohibit achieving the “Picture of Success.”
The primary technique used to identify risks is checklists. In general, checklists are a simple and
fast way to identify risks. For the Pandora project, the checklist that we will use to identify risks
is the Taxonomy-Based Questionnaire (TBQ) in Appendix B of the Taxonomy-Based Risk
Identification. The TBQ will be used to identify risks as part of a miniature Software Risk
Evaluation (SRE). The SRE will identify the initial risks in our project.
As the team progresses through the life cycle of the project, we will refer back to TBQ to identify
additional risks. Appropriate situations in which to identify additional risks would be after the
completion of life cycle phases.
After the risks have been identified using the TBQ, they must be analyzed so that they can
provide information for decision making. The primary technique for analyzing the identified
risks is to refine them as SEI Risk Statements. An SEI risk statement consists of six parts:
source, condition, consequence, probability, impact, and timeframe. Once the risks are formed as
risk statements, they can be prioritized.
Our risk prioritization process is composed of three steps:
1. The risk manager evaluates each risk’s probability of unsatisfactory outcome and loss
caused by unsatisfactory outcome (on a scale of 0 to 10). The product of each risk’s
probability and loss produces an exposure value.
2. The risks are ranked by their final exposure values.
3. The prioritized risks are presented to the team and each risk’s probability and loss values
are debated among the team until a consensus is reached, which produces new risk
This method of risk prioritization is simple enough for the team to accomplish quickly and
produces a set of risks and prioritizations that everyone on the team can agree on. The SRE will
also include the analysis of the project’s risks and produces a set of prioritized risks in which
everyone on the team can agree.
After the completion of the SRE, the team will develop a plan to address the prioritized list of
risks. This plan will include actions for each individual risk. The possible actions for risks are
acceptance, research, avoidance, and mitigation.
1. Acceptance: The team decides that the risk does not warrant more attention. The team
understands that the risk may become a problem and is prepared to take that risk.
2. Research: The team decides that the risk requires further study so that it can be better
understood. Once the risk is better understood, the team can plan the appropriate action.
3. Avoidance: The team decides that changing the software product or the development
process will avoid the risk.
4. Mitigation: The team decides that the exposure to the risk can be mitigated by decreasing
the risk’s probability or impact.
The action for each of the risks will be described in Risk Action Plans. These plans detail who is
responsible for the carrying out the plan, what deliverables are to be produced, and when the
milestones are to be completed. The Risk Action Plan template is available in Appendix X. The
Risk Action template is derived from Exhibit 7 of Barry Boehm’s “Software Risk Management:
Principles and Practices.”
The risk tracking technique that the team believes to be the most beneficial is scheduled reviews
of the top ten risks. In these reviews, the team discusses the progress of the actions for each risk
and reevaluates each risk’s priority. The risk management reviews will be conducted at the
following times during the project:
Monthly, beginning one month after the project development cycle begins through the end
of the project, or
At the completion of each major development phase
At the periodic risk reviews, status for each of the risk actions will be reported. This status will
allow the team to make informed decisions regarding the risks. The team may decide to
1. Close: The action plan has resolved the risk, and the risk does not require further
2. Continue Tracking: The action plan for the risk is effective but has not been completed.
The risk requires further tracking.
3. Re-plan: The current action plan for the risk is not effective and a new action plan is
SRE Method Description
Software Risk Management
Taxonomy-Based Risk Identification
Software Risk Management: Principles and Practices