Software Product Lines
Framework Home
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
Launching and Institutionalizing
Market Analysis
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section


This practice area is about how business gets done; it is the engine that makes the organization run. Without it, the organization is mostly just a collection of staffed units, poised and willing to do the right thing but unsure of precisely what that is. Any organization in the business of developing products operates under the aegis of its organizational and/or management strategies and policies, business processes, and work plans. Operations puts all of these items together into a coherent unified corpus of policies and practices. The vehicle for documenting these policies and practices is an operational concept [ANSI 1992a]. The operational concept

Aspects Peculiar to Product Lines

With product lines, this practice area spells out how the organizational structure populates and nurtures the core asset base and how it uses the core asset base to build products. In the figure which shows the product line's essential activities, operations tells how the wheels are set in motion, how the right information flows along the arrows, and how management orchestrates the entire business.

Operations breathes life into the organizational structure that was put into place to carry out product line activities. The "Structuring the Organization" practice area positions people in the right work units and assigns them broad responsibilities. However, without a clear definition of the operational concepts for building and running the product line, those people will flounder or, at best, perform inefficiently. To borrow an assembly line analogy, structuring the organization is like telling automobile workers, "Stand right here, and here, and here. When parts come along, put them together so that an automobile comes out at the end." That's not enough instruction. Operations, on the other hand, tells the workers how the pieces fit together and in what order, what to do when the right pieces aren't in place or don't fit together, how to report pieces of poor quality, how to make suggestions for improvement, how to interact with workers standing at stations near theirs, and what they are and are not allowed to do (for example, "Don't bend the pieces to make them fit together!"). Both structure and operations are necessary for the assembly line to roll out quality products.

The product line approach is not a case of "one size fits all." Operations spells out how the approach is implemented in organization-specific terms.

Operations describes how and which organizational units

Operations also describes the interconnections among those carrying out the essential activities of core asset development, product development, and management. These interconnections would include communication mechanisms, decision and conflict resolution processes, a document map, and a supporting Web site or wiki for the product line.

The best way to document the operational concept is to develop a formal product line concept of operations (CONOPS). An organization develops this document (which is, itself, a core asset) to describe its product line approach in organization-specific terms. The CONOPS documents the decisions that define the approach and the organizational structure needed to put it into operation.

The more conventional purpose of a CONOPS is to represent the user's operational view for a system under development. This view is stated in terms of how a system will operate in its intended environment. The CONOPS for a product line serves much the same purpose but for the product line organization. The CONOPS documents the organization's decisions about its product line operations–that is, how the members of the organization work together to accomplish core asset development and product development and manage and orchestrate the product line effort. All product line personnel use the CONOPS as the guide to how to carry out any product line action or communication. In particular, managers use the CONOPS to determine who is affected by a decision and who needs to be informed about specific decisions. Technical members of the organization use the CONOPS to determine who to contact for decisions.

Someone, usually the product line manager or a Product Line Steering Group, needs to own the operational concept, make sure it is well documented, effectively communicated, followed in everyday business, and improved as necessary based on measurement and feedback from individuals within the organization and customers of the product line.

Application to Core Asset Development

For core asset development, operations defines what plans, processes, strategies, policies, and constraints the core asset developers will carry out to do their jobs and how those items will be managed. Therefore, the operational concept for core asset development documents the organization's decisions regarding

Application to Product Development

For product development, operations defines what plans, processes, strategies, policies, and constraints the product developers will follow to do their jobs and how those items will be managed. Therefore, the operational concept for product development documents the organization's decisions regarding

Finally, the production strategy for products, described in "Core Asset Development," is reflected in the operational concept.

Example Practices

Creating a CONOPS: The stakeholders in the product line organization need to participate in the creation of the CONOPS in order to ensure that the operating concept is realistic and to mitigate the risks associated with failure to buy into the product line approach. Holding a workshop for the formulation, or at least the review, of the CONOPS is one way to involve stakeholders in its definition.

Managing the operations: A product line manager, or an equivalent organizational unit that performs the role of product line manager, orchestrates the product line effort. Suggested managerial practices for the product line manager include

Developing scenarios: Scenarios can help those developing a product line CONOPS gain an understanding of product line operations. You can create scenarios for the following tasks:

An organization can cast these scenarios as a series of "A Day in the Life of . . ." vignettes. Because they are focused and lack extraneous information, these vignettes make product line activities come alive for individual or small groups of role players. The role players themselves could be asked to draft the vignettes, thereby testing their understanding and encouraging more enthusiasm and buy-in than scenarios developed by management would.

Practice Risks

An inadequate or inappropriate operational concept will result in the product line staff working at cross-purposes and in conflict with each other. Productivity (and morale) will drop. Also, (depending on the nature of the problem) core assets might not be used in the way they were intended, products might not be turned out as planned, and the product line might stagnate and die. An inadequate operational concept can result from the

Further Reading

[ANSI 1992a]
The American National Standards Institute (ANSI) provides a standard for preparing operational concept documents.

[Cohen 1999a]
Cohen applies the idea of using a standard to product lines and introduces a generic product line CONOPS that can be suitably tailored and adapted by an organization to meet its specific needs and circumstances. Cohen's report includes guidelines and scenarios to help an organization that has proposed a product line, provides a nearly complete example of a CONOPS for a product line approach, and details the class of information to be contained in each section of a CONOPS.

[IEEE 1998b] IEEE describes the format and contents of a CONOPS.

[McGregor 2005a]
As part of the SEI Pedagogical Product Line, McGregor provides a sample product line CONOPS for a hypothetical company. This document gives a useful outline for a CONOPS and example contents.

Next Section Table of Contents Previous Section