Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Funding
Launching and Institutionalizing
Market Analysis
Operations
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Training
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Organizational Risk Management

Organizational risk management is risk management at the strategic level. Risk management concepts are discussed in the "Technical Risk Management" practice area, which describes the activities that are necessary for project-level risk management. An organizational risk management process relies on the existence of such project-level risk management and provides mechanisms for surfacing and managing risks that transcend, or are shared across, projects.

The seven principles of risk management are shown in the following figure. These principles are divided into one core principle, three sustaining principles, and three defining principles. An effective risk management program exhibits characteristics of all seven principles.

The Seven Principles of Risk Management

The Seven Principles of Risk Management

Core Principle

Sustaining Principles

Three sustaining principles allow an active risk management process to sustain its success in an organization:

Defining Principles

Three defining principles help to ensure success when working in a complex, multi-project environment:

Aspects Peculiar to Product Lines

Product line efforts require a great deal of coordination across project boundaries, which makes well-defined, organizational risk management practices essential. As the organization orchestrates the product line effort, it identifies risks that affect multiple core asset developers and/or product developers.

The core asset and product development teams will manage the risks to their individual projects. (For more information, see the "Technical Risk Management" practice area.) Each project management team will have cost, schedule, and technical objectives that are peculiar to the task they are trying to accomplish. When risks cross multiple projects or affect the organization's successful implementation of a product line approach, the risks should be managed at the organization level.

The multiple viewpoints endemic to product lines will surface in risk management and must be reconciled. For example, core asset developers may define success as meeting delivery dates, whereas product developers may define it as integrating the product and delivering capability to the end user. Both viewpoints are valid; the risk management process needs to "hear" both of them.

Sometimes two stakeholders on the same side of the product fence will have different viewpoints. For example, one military organization decided to use a product line approach to provide situational awareness tools to both embedded weapons systems and command and control systems. One embedded weapons system developer was concerned about weapons system safety and performance in a battle environment. This system developer could not accept immature products or those that weren't rigorously tested by the core asset developers. In the course of managing the project, the developer identified the following risk:

The core asset development team does not test the situational awareness core assets adequately; we may receive immature products with major defects that can impact the operational effectiveness of our weapons system.

A command and control development team wanted increased functionality and was willing to accept early deliveries of "beta" version core assets. The team promised its customers incremental deliveries of new capabilities to support an upcoming operational test and identified the following risk:

The development process used by the core asset development team takes too long to support our time-to-field requirements; we may miss critical delivery commitments.

These two risks, identified by separate product development teams with different project objectives, point to conflicting mitigation approaches. Using a team risk approach, each of these individual risks would be elevated to the product line organization level, and mitigation strategies would be developed to address both concerns. Those tasks are accomplished using a structure wherein personnel from multiple projects work together to share information about risks that may affect the other project(s) or the product line itself [Gallagher 1999a]. The risk at the product line organization level might be

The development process used by the core asset development team is rigid, forcing a "one-size-fits-all" delivery and integration approach; the delivery of core assets to reusers may not support project-level objectives and ultimately fail to meet the user's needs.

The complexity of managing the delivery of core assets to product development teams requires a management structure with mature methods and tools that can arbitrate conflicting needs and develop "win-win" solutions for the entire organization. Organizational risk management practices must provide proactive management methods and tools to help solve the complexities associated with implementing a product line approach.

Application to Core Asset Development

Core asset development teams should actively and continuously identify and manage risks associated with developing core assets for the product line. (For more information, see the "Technical Risk Management" practice area.) When the risks also affect product development teams or other core asset development teams, they should be elevated, using a team risk approach, to the organization level. Core asset development teams need to understand the objectives of the organization's product line approach and work closely with product developers, the developers of other core assets, and product line managers.

Application to Product Development

Product development teams should actively and continuously identify and manage risks on their projects. (For more information, see the "Technical Risk Management" practice area.) When risks cross project boundaries and affect other product development teams or core asset development teams, they should be elevated, using a team risk approach, to the organization level. Product development teams need to understand the objectives of the organization's product line approach and work closely with core asset development teams, other product developers, and product line managers.

Example Practices

The example practices outlined in the "Technical Risk Management" practice area apply here as well. The difference is that the scope of organizational risk management activities transcends individual development projects.

Team Risk Management (TRM): TRM, shown in the following figure, is one cross-organizational approach [Dorofee 1994a]. It was developed originally to allow individual and shared risk management between a government organization and a contractor organization. However, the basic principles are applicable to two projects or organizational structures that have mutual interests and shared risks. Simply stated, two or more projects could install risk management practices following the principles described in this practice area or the example practices described in the "Technical Risk Management" practice area. TRM describes how to establish an overarching risk management process to share risk management activities where appropriate and insure that project-level risks are surfaced at appropriately high levels of management.

Team Risk Management

Team Risk Management

Practice area risks: Risk management activities often gain a headstart by asking probing questions designed to test for the presence of risks that often occur in similar situations. In a product line organization, there are known risks associated with each practice area. Those risks can be used as the basis for probing questions associated with risk identification.

SEI Product Line Technical Probe (PLTP): The PLTP, described as an example practice under the "Launching and Institutionalizing" practice area, is a way surfacing a product line organization's strengths and challenges at an organizational level. When applied during a product line launch, the organizational risk management team should track and manage the uncovered challenges as risks.

Practice Risks

Non-conducive environment: The biggest risk in managing uncertainties is creating an environment in which team members feel that they can't talk about risks. In his book on software disasters, Glass points out that one shared characteristic of failed projects is the inability of project members to communicate potential problems to the decision makers within a project. Seventy-two percent of failed projects had team members who knew of impending doom, while only 19% of the project managers on the same projects shared their insights [Glass 1998a]. Risk management allows team members to discuss potential problems in a structured, non-threatening manner providing insight to decision makers.

The risks highlighted in the "Technical Risk Management" practice area also apply.

Further Reading

[Dorofee 1994a]
Dorofee and colleagues provide an essential resource for starting and running a risk management effort.

[Glass 1998a]
Glass gives compelling case studies of failed software engineering projects that show what risk management could have averted. Glass imparts lessons learned and abstracts common themes and root causes.

Next Section Table of Contents Previous Section