A Framework for Software Product Line Practice, Version 5.0

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

Core Principle

open communications: An effective risk management process must encourage the free flow of information at and between all project levels. The process should enable formal, informal, and impromptu communication.

Sustaining Principles

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

integrated management: When risk management is treated as a "bolt-on" or side activity, team members become frustrated, because managing risk is seen as interfering with their "real work." Teams performing risk management must integrate risk identification, risk analysis, and risk planning tracking and control into normal product line management activities and forums. As depicted in the following figure, risk management is integral to project management.

Risk and Project Management
teamwork: The success of any software development project hinges on good teamwork. Team Risk Management (see figure below) brings together groups with diverse and sometimes conflicting objectives and allows them to discuss risks that cross project boundaries, figure out which risks are most important to mitigate, and pool resources to lower the risk exposure facing all parties.
continuous process: The risks to an organization change constantly. The key to instituting a continuous process is to maintain the surveillance of risks as they change and to constantly identify new risks. Warren Keuffel warns against complacency:

A software development project's environment is constantly changing, as a result of competitive pressures, organizational strategy and personnel changes, and technical challenges. Too frequently, a risk management plan, like a system architecture design, is prepared at the beginning of the project and then shelved. To be valuable, risk management needs to be revisited as frequently as schedule and technical issues [Keuffel 1999a].

Defining Principles

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

forward-looking view: Everyone is focused on the same tomorrow. Inevitably, when dealing with multiple, interrelated projects that focus on the same success point, conflicts will arise. The organizational management will need to keep all parties focused on the same success point.
global perspective: Everyone has the same definition of success. From an organizational point of view, it may mean lower operations and maintenance costs over a 20-year period. It's organizational management's responsibility to articulate the business goals clearly and define success from a global perspective.
shared product vision: Everyone sees the final capability as the same thing. The entire group of related developers, technical managers, and organizational managers must have a clear vision of where the organization is headed.

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

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.