A Framework for Software Product Line Practice, Version 5.0

Technical Planning

Planning is one of the fundamental functions of management at any level. It provides the basis for the other management functions, particularly tracking and controlling. This practice area is concerned with the planning of projects. By project, we mean an undertaking typically requiring concerted effort that is focused on developing or maintaining a specific product or products. Typically, a project has its own funding, accounting, and delivery schedule. In a product line context, a project might be responsible for developing specific core assets or for developing a specific product from the core assets. A companion practice area is "Organizational Planning," which focuses on the strategic planning that transcends projects.

It is useful to distinguish between the process by which plans are created (the planning process) and the product of that process (the plans). Most planning processes are very similar regardless of the organizational level at which the plan is applied. They usually differ in the personnel involved and the scope of the planned effort. Generally, all planning processes should include

establishing the plan and its contents
establishing estimates of the resources required to carry out the plan
having those who will be bound by the plan review it for feasibility
establishing commitments to the plan

The planning process needs to be iterative and ongoing–after all, plans change. Plans should be updated and revised as needed during their lifespan.

Different types of plans address different purposes. Examples of project-oriented technical management plans include project plans, software development plans, quality assurance plans, configuration management plans, test plans, and technical risk management plans.

Although the contents of each plan should be tailored to fit its particular use, plans typically contain the following:

goals: A goal is a statement of a desired state that will be achieved by the successful execution of the plan.
strategies: A strategy is a description of a way to achieve plan goals.
objectives: An objective describes a significant, measurable, time-related intermediate state that will be achieved as the plan is executed.
a set of activities to perform: An activity is an assignable, discrete step that helps achieve the specified objectives.
resources allocated: The plan should include an assessment of the resources that the planned activities are allowed to consume (chief among which is time).

Other potential plan contents include responsibilities and commitments, work breakdown structures, resource and schedule estimates, risks, progress measures, relationships, and traceability to other plans.

The most usable plans have a particular focus. Planning a complex task often requires a set of interrelated plans that might have these relationships:

temporal relationships: Some plans might cover a time period that precedes or follows that of other plans.
hierarchical relationships: Some plans contain subordinate details.
relationships involving critical dependencies: Some plans depend on the execution of other plans.
relationships based on a supporting infrastructure: Some plans depend on the existence of an organizational function–for example, a quality assurance or process group.

Aspects Peculiar to Product Lines

There is nothing fundamentally different about a planning process for a product line. However, certain types of technical plans are unique to product lines:

core asset development and maintenance work plans: These plans describe not only how core assets will be created initially but also how the core asset base will grow and evolve.
production plans: These plans describe how products will be developed from a set of core assets (as described in "Core Asset Development") and include the process to be followed, as well as project details such as the bill of materials and schedule estimates. A product production plan lays out the production process for an individual product; the product line production plan is a core asset that applies to the entire product line and from which individual product production plans are derived. In practice, a good deal of the production plan and product production plans are common. Project details such as the bill of materials and schedules are product specific and therefore differ.

Project plans for product lines have a richer set of dependencies than those for single systems. They also have external dependencies among different groups and other plans, possibly at the organizational level, with relation to the core assets. Examples of project plans that may have dependencies include configuration management plans, funding plans, software integration plans, testing plans, and risk management plans.

Application to Core Asset Development

A product line effort requires work plans for core asset development and maintenance. These plans correspond to standard project plans, except that the "projects" in this case cover the development and maintenance of core assets (or subsets of the core assets). In addition to the generic plan contents identified earlier, these plans should also answer the following questions:

What is the set of core assets?
How will core assets be created initially?
How will core assets be tested (or, in the case of the architecture, evaluated)?
How will the core asset base be expanded and maintained, and how will components be certified for incorporation?
How will core asset development and maintenance be funded? The answer to this question should specify the identification of funding sources and a funding profile over time that addresses initial creation as well as sustainment. Because potential funders and stakeholders cut across one or more organizations, planning for core asset funding is likely to occur at the organizational level. In this case, project and organizational planning work in close concert. Project planning might determine funding needs. How to satisfy these needs could be planned at the organizational level.
How will the configuration of and changes to the core assets be controlled?
What tools will support the core asset project?
What measurements will be used to monitor the core asset development and core asset health?

Whether you opt for a separate plan for each core asset or an overall "master" plan for the entire core asset effort depends on your context and culture. Don't overlook the fact that the plans themselves (or parts of the plans) make reusable core assets. Ideally, reusable plans should be tailorable in the same fashion as other core assets–that is, they have defined points of commonality and variability. Cost, effort, and schedule estimates may be particularly useful candidates for reuse, as are work breakdown structures, goals, strategies, and objectives.

In addition to the work plans for core assets, there is the production plan, which is, itself, a primary core asset. To develop a production plan, you need to understand who will be building the products–that is, the plan's audience. Production planning involves a combination of process definition and technical planning activities. The objective is to formulate a production strategy, production method, production process, and production project details that satisfy the organization's goals for the software product line.

Production plans can range from a detailed process model to a much more informal guidebook. The degree of specificity required in the production plan depends on the background of the intended product builders, the structure of the organization, the culture of the organization, and the concept of operations (CONOPS) for the product line. It helps to have at least a preliminary definition of the product line organization before developing the production plan.

The production plan should describe how specific tools are to be applied in order to use, tailor, and evolve the core assets. The production plan should also incorporate any metrics defined to measure organizational improvement as a result of the product line (or other process improvement) practices and the plan for collecting the data to feed those metrics. The production plan, like other core assets, should have variation points that permit tailoring to accommodate the needs of each product.

Application to Product Development

Each product development effort needs a plan to describe how the specific product will be produced using the core assets. That plan–the product production plan–is an instantiation of the production plan for the product line based on its variation points. The product production plan spells out the production process by including the attached processes for each core asset in that product. It helps the product developers use the core assets effectively to develop products.

A product production plan should answer the following questions:
What processes must be followed in order to use and adapt the core assets for use in each product?
How will any necessary tailoring of the core assets be accomplished? That is, how are the built-in variation mechanisms to be exercised?
How will any product-unique development be accomplished to supplement the core assets?
How will products be tested?
How may these plans interact with core asset development/maintenance plans? Production plans and core asset development and maintenance plans might have the following types of mutual dependencies:
- What core assets must be available to support particular product development needs? When must they be available?
- Are any product development projects providing assets to the core asset base? When are those assets needed? What must product development teams do in order to add assets to the core asset base?

In practice, a product production plan might only be derived conceptually–that is, the production process might be so easy or general that you don't have to literally make a concrete instance of it for each product. You can "mentally" derive it. Or it might be implicit due to automated derivation. That said, there are some things specific to each product that will be derived from the project details part of the production plan, such as the bill of materials, schedule, and so forth.

Example Practices

Production Planning Workshop: Chastek and McGregor developed a workshop for developing a product line production plan. It includes a guided session to determine the production goals, breakout discussions to define key development scenarios, a group work session to formulate the production strategy and prioritize the development scenarios, breakout groups to test the formulated strategy, development of a production method, and a discussion of the implications of that method for core asset design. For more information on production plans, see the work of these authors [Chastek 2004a, Chastek 2002b, Chastek 2002c].

Practice Risks

Poor-quality technical plans can fail to plot the needed tasks and fail to provide adequate resources for product line efforts. The result is a lack of confidence in the planners, missed deadlines, and poor quality due to desperate shortcuts. In particular, plans can suffer from the following:

a lack of product line support: If the additional coordination and commitments required for product line planning are not accomplished effectively, the result will likely be a poorly coordinated effort in which product line benefits are lost.
shelfware plans: If plans are not updated as changes occur, the plans become useless and the process becomes unmanageable.
inappropriate plans: If plans are too aggressive, too detailed, or too abstract, they will not be followed. They must be realistic to the organization and the goals, provide sufficient direction, and offer some flexibility. Some characteristics of a good planning process based on improvement planning are described in the "Organizational Planning" practice area. These characteristics are equally applicable to technical planning.
lack of stakeholder involvement: Product line plans typically have more stakeholders than typical project plans. Unless all the appropriate stakeholders (or at least a representative set of them) are involved in the creation of product line plans, the plans may not be viable for all concerned.