MIS 495 -- Dr. Reithel
Chapter 6

Kinds of Software Risks


Risk Identification

Risk Identification is a systematic attempt to specify threats to the project plan. By identifying the known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. There are two types of risks: Generic Risks are a potential threat to every software project, and Product-Specific Risks can only be identified by those with a clear understanding of the technology, people, and environment that is specific to the project at hand.

One method for identifying risks is to create a risk item checklist which can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: product size, business impact, customer characteristics, process definition, development environment, technology to be built, staff size and experience.


Risk Categories

Product Size Risks-- It is said that 'project risk is directly proportional to product size'. The following is a risk item checklist identifying generic risks associated with product size. The information is then compared to past experience, and if a large percentage deviation occurs or if numbers are similar, but past results were considerably less than satisfactory, risk is high.

Business Impact Risks-- Below is a checklist which identifies generic risks associated with business impact. Each response must be compared to past experience, and if a large percentage deviation occurs or if numbers are similar, but past results were considerably less than satisfactory, risk is high.

Customer Related Risks-- It is important to note that: customers have different needs, customers have different personalities, customers also have varied associations with their suppliers, and customers are often contradictory. The following checklist identifies generic risks associated with different customers. If the answer to any of these questions is 'no', further investigation should be undertaken to assess risk potential.

Process Risks-- If a majority of the following questions are answered 'no', software process is weak and risk is high.

Process Issues

Technical Issues

Technology Risk-- It is very difficult to foresee technology risks, much less plan for them. If the answer to any of the following questions associated with technology to be built is 'yes', further investigation should be undertaken to assess risk potential.

Development Environment Risk-- supports the project team, the process, and the product. If a majority of the following questions are answered 'no', the software development environment is weak and risk is high.

Risks Associated with Staff Size and Experience-- If the answer to any of the following questions is 'no', further investigation should be undertaken to assess risk potential.


Risk Projection-- also called risk estimation, attempts to rate each risk in two ways--the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. There are four risk projection activities: (1) Establish a scale that reflects the perceived likelihood of a risk; (2) Delineate the consequences of the risk; (3) Estimate the impact of the risk on the project and product; (4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.


Risk Assessment-- involves the further examination of the accuracy of the estimates that were made during risk projection. Risk Assessment attempts to prioritize the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur.

Steps in risk assessment:

1. Define the risk referent levels (performance, cost, support, and schedule) for the project

2. Attempt to develop a relationship between each [ri, li, xi] and each of the referent levels

3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.

4. Try to predict how compound combinations of risks will affect a referent level.


RMMM Plan-- The risk management steps can be organized into a separate Risk Mitigation, Monitoring, and Management Plan (RMMM). The RMMM Plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall Project Plan. For an outline of the RMMM Plan, see the Pressman textbook, page 149.


Suggested Links for Further Readings
Extensive set of pointers for decision/risk analysis
Paper on risk and analysis (plus pointers to a number of risk bibliographies)
DOE Risk Management Quarterly
WWW references relevant to software risk analysis from Roger S. Pressman, Associates

Last Modified: Wednesday, 13-Jan-99 9:10:00 CDT
Copyright © 1999 University of Mississippi. All rights reserved.

Comments: reithel@bus.olemiss.edu