A Framework for Software Product Line Practice, Version 5.0

Launching and Institutionalizing

This practice area is about organizational change.

Change projects are undertaken to help organizations prepare themselves to adopt a new technology or a new way of doing business. These projects are highly dependent on the context of the organization; an invariant sequence of steps to execute the project is inappropriate. Successful change projects take into account not only the specific technology involved but also the human aspects of change.

Organizational change involves an assessment of the current state, an articulation of the desired state, and an assessment of the gulf between the two. After that, solution strategies for bridging the gulf can be crafted, tried out, and then scaled up. Lessons learned along the way can help refine your understanding of the current state, the desired state, or the intended solutions.

Aspects Peculiar to Product Lines

The change being launched and institutionalized is of course the software product line approach. This practice area is relevant whether an organization is starting a product line effort for the first time or trying to expand and/or improve the ongoing product line effort. Launching and institutionalizing a product line is somewhat different in that it is a practice area about applying the other practice areas, as appropriate to the needs and capabilities of an organization.

Launching and institutionalizing a product line differs in the particulars from other change projects because product line adoption involves technology and business change. Launching a product line is about the judicious and timely adoption of product line practices. By factoring in a characterization of your individual situation, the part of the product line effort you want to accomplish, the groupings of practice areas that meet your individual needs, and a dynamic view of how the practice areas in that grouping interact to help you accomplish your goals, you can bring the practice areas to bear on your situation most effectively.

The end game of product line adoption is to have an operational product line. A product line adoption plan must be created to describe how product line practices will be appropriately rolled out across the organization. Depending on the starting point of the organization, this plan¹ may provide for the definition of processes, the initiation of practices, the selection and implementation of pilots, or the engineering of a product line. If the intention is that the entire organization will eventually adopt a product line approach, the plan should address the entire organization. For example, suppose that a chosen pilot project involves only one part of the organization that eventually will make the transition. After all, that is one of the benefits of a pilot project: it does not involve the entire organization, so missteps and early mistakes are confined to a small effort. What, then, do the other parts of the organization do while the pilot is underway? If they do nothing, it's business as usual for them, and in more than one organization we've seen, that has spelled trouble. Those people may feel left out and disenfranchised, and their support for the transition to product lines may suffer as a result. But an adoption plan that applies to the organization (a project, business unit, or corporation) as a whole may be the solution. Even if a group is not participating actively in the pilot project, its members can serve as reviewers, receive training, practice building a business case or scope definition, or be assigned process improvement activities to shore up their capabilities for when they will join the product line. A product line adoption plan–the result of the launching effort–is the master plan showing how all parts of the organization adopt product line capabilities, perhaps in a highly staged manner.

Institutionalizing product lines requires that the organization consistently use product line practices to achieve its business goals. Product lines become community practice. To do that, an organization must

have
- a core asset base
- supportive processes and organizational structures
develop products from that asset base in a way that achieves business goals
prepare itself to institutionalize product line practices

Application to Core Asset Development

Launching a product line will, of course, kick off the core asset development effort, but more is required to ensure the proper organizational context for core asset development. Such activities as funding, training, and structuring the organization will likely be part of launching. In fact, a product line adoption plan may be one of the first core assets that an embryonic product line effort will develop.

Institutionalizing a product line involves improving the processes that are associated with building, maintaining, and evolving the core assets and making those processes part of standard organizational practice.

Application to Product Development

Launching a product line often involves choosing a pilot project or two with which to demonstrate the product line activities. (For information about choosing pilot projects, see the "Example Practices" section below.) These pilot projects should, if possible, yield marketable products, which will enhance the fidelity of the demonstration and subject the core assets used in their construction to real-life constraints. Institutionalizing a product line means making the development of products routine and predictable while still meeting the organization's product line goals. The achievement of this steady state is a signal that product line practice has, in fact, been institutionalized.

Example Practices

Launching and institutionalizing a software product line is a matter of orchestrating the activities of all the applicable practice areas over time. Your organization's specific launching strategy will be unique. However, many organizations have had success following the SEI Adoption Factory pattern in conjunction with a technology change model, such as the SEI Initiating, Diagnosing, Establishing, Acting, Learning (IDEAL) model. (This pattern and model are both described below.) Beyond that, the specific practices discussed below will suggest some additional approaches for bringing your organization up to product line speed.

Use the Adoption Factory pattern: Product line practice patterns deal with applying practice areas in a way that is most relevant to the organization's situation [Clements 2002c, Ch. 7]. Finding (or inventing) the appropriate patterns is, in many ways, the essence of launching and institutionalizing a software product line. The Adoption Factory pattern can serve as a generic roadmap for product line adoption [Northrop 2004a].

The phases and focus areas view of the Adoption Factory pattern in the following figure illustrates the dynamic structure of the pattern as three columns, corresponding to the temporal phases of product line adoption, and three rows, corresponding to the focus areas for certain patterns and practice areas. The three temporal phases are

1. Establish Context: which involves paving the way for product line adoption
2. Establish Production Capability: which involves developing the core asset base and the production infrastructure and managing those efforts at the project and cross-project levels
3. Operate Product Line: which involves using the core asset base to efficiently build products and monitor and improve the product line operation

The three focus areas are

4. Product: which involves those activities for defining and developing products and their common assets
5. Process: which involves the underlying processes and production infrastructure necessary to adopt a product line approach
6. Organization: which involves the management practices and activities necessary to adopt a product line approach and operate a software product line

Within each of the nine cells created by the intersection of a phase and focus area are the intuitively named subpatterns² [Clements 2002c, Ch. 7] that make up the Adoption Factory pattern.

Adoption Factory Pattern Annotated with Adoption Phases and Focus Areas

Other useful views include the practice area view, which shows the constituent practice areas associated with the subpatterns, the roles view, which describes the principal roles involved in each of the nine cells, and the outputs view, which describes the key artifacts produced.

Use the IDEAL model: In the technology change domain of process improvement, the IDEAL model has enjoyed wide success [McFeeley 1996a]. With some generalizations, the IDEAL model is also appropriate for the launching of a product line. As shown in the next figure, the IDEAL model is iterative, allowing the reevaluation of the changing organizational context as the technology change project proceeds. This iteration also makes the model applicable to launching a product line effort from different levels of product line sophistication and to improving or institutionalizing the product line effort. This iterative cycle may be executed as many times as necessary to achieve the desired organizational state.

The model consists of five phases, each providing a basis for the next phase, with the final phase feeding back to the beginning. The five phases are Initiating, Diagnosing, Establishing, Acting, and Learning:

An organization typically enters the Initiating phase as a result of some stimulus that intends to change the current way of doing business. In response to this stimulus, the appropriate sponsorship is established, and the appropriate resources are allocated.
In the Diagnosing phase, the organization performs a diagnostic activity to baseline the current practices and probe for improvement opportunities.
In the Establishing phase, the recommendations of the diagnostic activity are prioritized, change implementation teams are established, and plans are developed for conducting the activities.
In the Acting phase, the planned activities are carried out.
The end of a cycle is represented by the Learning phase. During it, the organization collects lessons learned that can then be applied to subsequent rounds of the technology change cycle.

The IDEAL Model for Technology Change

Recognize that a given IDEAL iteration cycle may emphasize or de-emphasize a particular phase depending on the iterations that have gone before. For example, it is typical for more attention to be needed for the Initiating phase of early cycles than of later cycles. Specific details might be best determined by evaluating the risks associated with each phase, much as in the Spiral development model [Boehm 1988a].³

Use the Adoption Factory pattern and the IDEAL model together: As noted, the Adoption Factory pattern lays out the change that needs to occur when moving to a product line approach, but it lacks change management mechanisms and guidance about how to perform incremental adoption. On the other hand, the IDEAL model is a general model for guiding change but lacks product-line-specific guidance. These two models may be used effectively together when informed by contextual information about an organization (e.g., cultural aspects, degree of process discipline, and other particular strengths and weaknesses of the organization).

Below, we describe some ways in which the Adoption Factory pattern can be used within the phase sequencing of the IDEAL model. Note that not all these activities would necessarily occur in a single IDEAL cycle.

Initiating phase-forming commitment: Once a product line opportunity has been identified and substantiated (perhaps with early forms of a business case or market analysis, a scaled-down use of the What to Build subpattern in the Adoption Factory pattern), promote management and staff awareness of the opportunity, obtain staffing and resource commitments, and set product line objectives so as to meet specific business needs. The Adoption Factory pattern can serve as a common product line adoption vocabulary. The various views can be used to educate people on the overall approach, roles, and work products.
Diagnosing phase–assessing product line conditions: In an early IDEAL cycle, evaluate the business and technical viability of a candidate product line opportunity (based on the "Scoping," "Building a Business Case," "Market Analysis," "Funding," "Organizational Risk Management," and "Technology Forecasting" practice areas). In a later IDEAL cycle, an organization could also use all the practice areas to determine areas for diagnosing organizational product line practices; this is the basis of the SEI Product Line Technical Probe (PLTP)⁴ [Clements 2002c, Ch. 8]. The SEI uses the Adoption Factory pattern to organize the PLTP results that will serve as a gauge for how far along the organization is in its adoption effort.
Establishing phase–planning product line adoption: Based on the results of the diagnosis, develop near-term and longer term goals and build an action plan to achieve them. The Adoption Factory pattern phases provide a guide for what might be reasonable goals; the practice area view provides specific technical targets. As a risk-reduction method (particularly in an early IDEAL cycle), this plan could include pilot projects to prove concepts and demonstrate their application within the organization. Such a plan will identify and schedule any actions (with the associated resources) that are needed to improve the organizational capabilities for undertaking a product line approach. In general, the performance of this practice should adhere to the principles of the "Technical Planning," "Organizational Planning," "Technical Risk Management," and "Organizational Risk Management" practice areas.
Acting phase–monitoring direction and performance: Using the identified goals and reporting requirements from the plan created in the Establishing phase, monitor and evaluate the plan's outcomes and identify any needed revisions in your approach to accommodate changes in your objectives or opportunities for improvement. Activities in the acting phase should adhere to the principles set forth in the "Technical Planning" and "Organizational Planning" practice areas and be based on the results of data collection and metrics activities (see the "Measurement and Tracking" practice area).
Learning phase–tuning and improvement: Risk management, planning, and measurement activities guided by the Adoption Factory pattern will identify any places where the product line effort is not yet a good fit with the organization's own special context. In this phase, the processes and organizational structures are modified to reflect lessons learned and take advantage of potential optimizations. Note that weaknesses or lightweight implementations in earlier Adoption Factory pattern phases that will need to be strengthened before the next IDEAL cycle.
Subsequent execution of the IDEAL cycles–promoting institutionalization: Continue executing IDEAL cycles until all the practice areas in the Adoption Factory pattern are implemented with sufficient quality and rigor. Execute additional IDEAL cycles as appropriate to keep the product line up-to-date and responsive to changing conditions.

Use pilot projects: Pilot projects can be an important means of reducing risk and learning more about the organizational and technical issues associated with the product line effort. A successful pilot project can also be an effective means of building advocacy. A pilot should be viewed as a controlled experiment to test specific ideas or concerns.

Some criteria to consider when selecting a pilot include its

scope: The pilot should be scoped such that it can be executed in a relatively short time frame with relatively limited resources.
importance and visibility: The organization should care whether the pilot is successful. In other words, a success in the "backwater" of the organization is unlikely to generate any enthusiasm. On the other hand, the pilot should not be so important–for example, on a critical path–such that failure has a significant adverse impact on the organization.
probability of success: Especially for initial pilots, the effort should have a reasonable chance to succeed. If an organization already has success with product lines, more risky pilots might be chosen to test specific concepts.
choice of participants: Unless the pilot is aimed specifically at testing organizational resistance, the participants in the pilot should be advocates (or at least be open-minded).

Use proactive, reactive, and incremental approaches: As noted in "All Three Together," organizations may choose to take a proactive, reactive, or incremental approach to product line adoption. As discussed, each approach has its advantages and disadvantages.

Use lightweight approaches at first: When initiating a product line effort, some organizations report success with using lightweight organizational structures and lightweight processes to support them. These lightweight approaches facilitate smoother transitions to product lines that can be changed quickly and nimbly as the organization learns what does and does not work for its particular situation. It is worth noting that this approach is a form of piloting. Clements and Krueger debate the advantages and disadvantages of lightweight and other approaches [Clements 2002b].

Use product line diagnostics: Before an organization can launch and institutionalize a product line capability successfully, it needs to know its blind spots. If it is lacking necessary expertise in one of the practice areas (especially one that tends to manifest itself early in the product line life cycle, such as scoping or requirements engineering), it is unlikely to make a successful (let alone smooth) transition to sound product line practice. However, by recognizing potential trouble spots early, you can focus judiciously on resources and shore up any areas of weakness that, if left untreated, would undermine the product line effort.

One instrument to help an organization identify problem areas is the SEI Product Line Technical Probe (PLTP) [Clements 2002c, Ch. 8]. This diagnostic identifies an organization's strengths and challenges in each of the product line practice areas. These results provide the grist for an adoption or launching plan, the first part of which will be to rectify any deficiencies in critical skill areas. Other product line diagnostics include the SEI Product Line Quick Look (PLQL), the Bosch Product Line Potential Analysis [Fritsch 2004a] and the European Union Information Technology for European Advancement (ITEA) Business, Architecture, Process, Organization (BAPO) evaluation [van der Linden 2004a].

Develop product line goals, objectives, and strategies: Technology change should be initiated not for its own sake but to support specific organizational goals. Thus, an early step in the technology change project is to establish an appropriate set of goals, which are validated by a supporting rationale. A set of objectives should also be determined to provide high-level, measurable indicators of progress toward the goals. Given a set of goals and supporting objectives, a number of different strategies are typically appropriate to the achievement of those goals. Presumably, one of those strategies is to initiate (or expand) a product line effort. Another strategy might be to build (or further mature) a software process infrastructure to provide a foundation for the product line effort. An internal workshop is an excellent vehicle for articulating and capturing the goals, objectives, and strategies that will serve as the foundation for building an adoption plan. As product line adoption proceeds, the organization should revisit those items and update them as necessary.

Use process improvement as a basis for launching and institutionalizing: Process discipline provides a foundation for product line practice. As indicated by the "Process Discipline" practice area's placement in the Establishing Context phase of the Adoption Factory pattern, it is likely to be in your organization's best interests to initiate a process improvement effort early in, if not prior to, your software product line adoption.

Many organizations use SEI Capability Maturity Model Integration (CMMI) for Development with Integrated Product and Process Development (IPPD) as the basis for their process improvement efforts [SEI 2006a]. While some of the process areas on the CMMI models provide a basis, there is always something extra required to transform a single-system-oriented process to an appropriate corresponding product line practice.

CMMI is certainly not the only model for process improvement; many organizations have adopted a Six Sigma approach [Brassard 2001a]. Originally developed in the 1980s by Motorola to address electronics manufacturing quality, Six Sigma has evolved into a philosophy, an improvement framework supported by a set of improvement tools, and a structured approach for business improvement. The philosophy of Six Sigma is to improve customer satisfaction by reducing and eliminating defects, resulting in greater profits. The Define-Measure-Analyze-Improve-Control (DMAIC) Framework is a means to improve existing processes and products.

With its "Plan, Do, Check, Act" roots, DMAIC has been described as a "weakness-based," tactical approach to getting to the bottom of a problem through quantitative means.

Practice Risks

The risks of launching a product line relate to misapplying the product line approach by either failing to institute beneficial practices or instituting practices that are not appropriate to the particular organizational situation. A poor launching and institutionalizing strategy will result in failure of the product line to meet its goals, very likely because the staff will fail to accept it as a way of doing business. Such a failure can result from

lack of an identifiable champion: Any institutional change requires a strong champion who can effectively communicate the vision, console the troops when things go badly, make sure that the organization is following the new ideas, remind everyone why the organization has decided to embrace the change, and never, ever let enthusiasm wane. A software product line needs such a champion who has the management authority (or has the ear of management authority) to keep the organization on track. An organization lacking an effective champion will have a much more difficult time adopting the product line approach.
approach mismatch: If the products being developed do not have sufficient commonality to warrant a product line approach, any launching effort will fail. Software product lines should help your organization meet specific business goals. In other words, a product line approach to software is a means to achieve an end, not the end itself.
inadequate management commitment: If management has not been convinced of the viability of a product line approach for their situation, the funding, staffing, and other resources may be inadequate for a successful adoption. Mitigation involves developing additional evidence of the opportunity (perhaps through additional market analyses or narrowly focused pilot efforts) that is aimed at addressing specific concerns. Additionally, efforts may focus on developing the commitment at high organizational levels at which there may be more strategic perspectives on the business situation and future needs.
insufficient staff commitment: If the technical staff has not been convinced of the viability of a product line approach, they will be likely to torpedo the effort. A major aspect of any product line launch should focus on educating the staff and achieving their buy-in. Involving technical staff in the definition of plans and processes is one mitigation step.
insufficient bounding: If the planned effort requires too much effort over too long a period of time, the attainable benefits may not be realized soon enough to justify the investment. Mitigation might involve limiting the product line scope to create high-payoff core assets or limiting the market focus to address critical or selected work products so that this effort can concentrate on delivering valuable benefits within the needed time frame.
inappropriate application: If an organization does not have a clear product line charter or has one that is different than its stated charter, it will probably build products that are too divergent from the planned product line focus to benefit as anticipated from the product line approach. Mitigation involves ensuring that knowledgeable and experienced management, engineering, and marketing staff are involved over an adequate, but not excessive, period of time in resolving the true product line charter to be pursued. The organization should try to ensure that the needed diversity among future products, which must often be avoided with conventional development approaches, is accommodated properly.
premature standardization: If institutionalization occurs too quickly, the organization may institute inappropriate standards and terminate innovation prematurely.
missed or delayed standardization opportunities: On the other hand, if standardization opportunities are missed or delayed, there may be redundant or unnecessarily divergent efforts and less than optimally effective practices.
insufficient tailoring: If standardized practices are tailored insufficiently or inappropriately, the organization will probably adhere to suboptimal practices or unsupported deviations from the preferred practices.
failure to evolve the approach: If the approach to software product lines is not improved continuously over time, practices will probably become ineffective, and unsupported deviations will crop up out of necessity.
ineffective dissemination: If there is an inappropriate level or type of documentation, inadequate training, or ineffective support, the product line launch will most likely not take effect in the planned form or produce the desired outcomes in the required time frame.
lack of an emerging community: A champion is essential to launch a product line effort, but a champion cannot institutionalize product line practices. It takes a community of individuals who are from various parts of the organization and who are committed to the product line approach to ensure institutionalization. If a community is never formed, the product line practices will erode over time.