Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Configuration Management
Make/Buy/Mine/Commission Analysis
Measurement and Tracking
Process Discipline
Technical Planning
Technical Risk Management
Tool Support
Organizational Management
Practice Areas
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Technical Risk Management

Risk management is the practice of managing risks within a project, an organization, or a team of organizations. A complete risk management program should provide processes, methods, tools, and an infrastructure of resources and organizational responsibilities to identify and assess the risks (what could go wrong), determine what to do about them, and implement actions to deal with them. We distinguish between the practice areas of technical risk management and organizational risk management based on the scope and extent of the risks they address and the people likely to carry them out. Like other technical management practice areas, technical risk management addresses project-level concerns.

A risk is defined as the possibility of suffering a loss. Therefore, a risk has an associated probability that an event will happen and an associated negative impact or consequence if the risk is realized. Once a risk is realized, it is no longer a risk: it is a problem. A problem is a certainty rather than a possibility.

Having a standard way of stating and communicating a risk provides clarity and consistency. It's a critical component of risk management and serves as a basis for future risk mitigation planning. Risk statements have two parts: a condition and a consequence (see the figure below). The condition should be based on fact and provides the reader with the anomalous condition or circumstance that causes concern. At least one possible consequence should be noted so that future readers of the risk statement will better understand the original concern of the author.

The Risk Statement with Context

The Risk Statement with Context

For example, consider the following risk statement:

The commercial off-the-shelf (COTS) high-speed data link selected by the project team was never envisioned by the vendor to be used in a hardened environment; it may not perform as needed, causing rework and integration slips.

The condition causing concern is the project team's decision to select a component unproven in the product's target environment. Possible consequences are rework and schedule slips. Risk statements that are fact based and actionable allow the project team to start reasoning about the risk constructively. To help in the risk mitigation process, the context under which a risk statement was generated is typically added to the statement. The context is simply additional information regarding the circumstances, events, and interrelationships within the organization that may affect the risk. The context description captures more detail than the basic risk statement; the two of them together help identify the true source of the risk.

Aspects Peculiar to Product Lines

In product lines, risks most often involve more than one product, so the overall consequences are more far-reaching. While standard risk management paradigms can be applied to product lines, the challenge lies in tailoring the program to the organization and to product line issues. A risk management program is implemented most effectively as an integrated part of organizational or project management rather than as a separate activity.

In a product line approach, some sources of risk may be different or have different emphases, which could affect the process of risk identification. If you use a risk method that comes with its own taxonomy of risk areas or directed questioning techniques, be prepared to modify it in order to stimulate thought about the more common product line risks, such as those identified under the "Practice Risks" heading for each practice area.

Finally, as with all projects, the timing of risk management activities is critical. Since many important decisions are made early in the life cycle of a product line, risk management should be performed when the product line effort is launched.

Application to Core Asset Development

Applying risk management to a product line approach is fundamentally the same regardless of whether you are developing core assets or products from core assets. Risks identified during core asset development should be managed with particular care, since problems there have a ripple effect throughout the product line organization.

Application to Product Development

The programs for managing product development risks and core asset risks must be coordinated. Risks identified during product development could involve mitigation strategies that involve core asset development.

Example Practices

Continuous Risk Management: The Continuous Risk Management (CRM) paradigm developed by the SEI is illustrated in the following figure [Dorofee 1996a].

Continuous Risk Management (CRM) Paradigm

Continuous Risk Management (CRM) Paradigm

In this paradigm, risks are first identified and then analyzed to determine their probability of occurrence and impact (risk exposure) on the organization, the interrelationships between individual risk statements, and which related risks (risk areas) are most important to mitigate. Mitigation plans are developed for the most important risk areas. Individual risks, mitigation plans, and the risk process are all tracked to determine the effectiveness of mitigation actions and the risk process. Control decisions (for example, close, replan, continue tracking) are made and documented. The diagram is circular to emphasize that effective risk management should be a continuous process. This is in contrast to a risk management program that might identify risks only once at the start of a project and never revisit them.

Communication is represented as an encompassing activity to emphasize that the flow of information throughout the project or organization is essential to successful risk management.

Installing a Risk Management Program: An approach to installing a risk management program consists of the following steps adapted from the approach described by Dorofee and colleagues [Dorofee 1996a]:

  1. Build the initial awareness and infrastructure.
  2. Establish a risk baseline and mitigation plans.
  3. Develop a risk management plan that is adapted to existing structures and practices.
  4. Install risk management in a pilot project.
  5. Improve and expand the risk management implementation.

These steps, which view risk management from somewhat of a project focus, are described below. As mentioned previously, a product line approach requires an intimate association between core asset developers and product developers. Thus, a more comprehensive approach to risk management–such as team risk management–that crosses organizational boundaries may be desirable. For more information on that approach, see the "Organizational Risk Management" practice area.

Step 1. Build the initial awareness and infrastructure: In this step, management is made aware of risk management benefits and implementation requirements. A management commitment is required before the project can proceed. Initial awareness training, including motivation, is conducted within the organization, and an implementation team is established.

Step 2. Establish a risk baseline and mitigation plans: This step involves examining risks in a comprehensive fashion and creating an initial set of risk mitigation plans. Dorofee and colleagues describe one technique for establishing a risk baseline [Dorofee 1996a]. A key element of this step is risk identification–something that can be done using the SEI Risk Taxonomy-Based Questionnaire (TBQ) supplemented with risks from the practice areas in this framework. Practitioners have used the TBQ successfully to consider possible sources of risk [Williams 1999a]. Other sources of risk are described by Boehm [Boehm 1981a] and Fairley [Fairley 1994a]. After establishing a basic set of risks, you should analyze them in terms of probability, impact, and time frame; this analysis will help you prioritize them. Mitigation plans should be created for the highest priority risks, and the person or team responsible for executing those plans should be identified.

Step 3. Develop a risk management plan that is adapted to existing structures and practices: A risk management plan should detail the processes and organization that will address risks. As mentioned previously, CRM should be integrated into existing practices, so the first step is to analyze the existing structures, functions, and processes by asking

This analysis can help you discover opportunities for inserting the basic risk management practices (that is, identify, analyze, plan, track, and control) or uncover the need to add additional practices or functions. The risk management plan should address how these functions are to be incorporated into standard operations [Loveland-Link 1999a].

Step 4. Install risk management in a pilot project: This is the trial implementation of the risk management plan. The project chosen should be representative of the organization and supported by project management. In addition, it must capture any lessons learned and work collaboratively with the risk implementation team.

Step 5. Improve and expand the risk management implementation: In this step, lessons learned from the pilot project are applied to improve the risk management practices. Implementation is then expanded more widely throughout the organization. Depending on the organization, this expanded use may be instituted in phases. The continued improvement of risk management practices should be ongoing.

Practice Risks

An ineffective risk management program will result in problems that catch management by surprise and can possibly lead to decreased morale, low product quality, missed deadlines, and failure to make progress. Some of the risks associated with the introduction of a risk management program, which include those common to any improvement effort, are as follows [Radice 1994a]:

The biggest risk related to risk management is the failure of the existing organizational culture to encourage and reward risk identification. In such a "risk-averse" organization, people are pressured not to raise risks, either overtly or implicitly. Without broad participation in risk identification and management, a risk management program cannot succeed. The following table shows some barriers that exist in a "risk-averse" organization.

Potential Communication Barriers [Dorofee 1996a]

Potential Barrier


"ready, fire, aim" approach

People provide solutions to a problem before they have assembled and understood the underlying facts associated with the problem and its context.

"don't tell me your problem" attitude

People require a solution before they even discuss an issue: for example, a manager says, "Don't bring me problems; bring me solutions."

"shoot the messenger" attitude

A project member who intends to inform others or is looking for help suffers negative consequences because he or she is communicating unpleasant information.

"liar's poker" approach

Project personnel identify risks but fail to communicate them to others. Instead, they wait until the risks become serious problems that impact project schedules and product quality.


Individuals do not trust each other for a variety of reasons (such as, past history and preconceived biases). This lack of trust can destroy any credibility in the acquired risk data which, by its nature, is subjective and speculative.

hidden agendas

Situations create individual preferences for results: individuals or groups may promote facts or arguments based on their own goals rather than the common good.

"placing blame" approach

Risk information is used to place blame on project personnel.


Further Reading

[Boehm 1989a]
Boehm wrote an IEEE tutorial on software risk management that provides some valuable insights.

[Charette 1989a]
Charette's book is the foundational text on software risk management.

[Williams 1999a]
Williams, Pandelios, and Behrens describe the SEI Software Risk Evaluation (SRE) method.

Next Section Table of Contents Previous Section