4.2 Expanding scope

The second phase is concerned with expanding the scope of the product family in terms functionality that is in the product family domain. R&D teams have grown accustomed to the additional dependencies and learned to trust other teams to an extent. After the initial rather ad-hoc, but efficient, adoption phase, now more structure is needed to institutionalize the product family approach.

The second adoption phase ends at the point when no obvious extensions to the shared components can be identified by the R&D organization. At that point, the challenge shifts to increasing the “maturity” [Bosch 02] of the product family artefacts as a means to decrease the product derivation cost.

4.2.1 Decision dimensions

In this section, we discuss, for each decision dimension, the preferred alternative as well as the situations in which an organization should deviate from it.

Feature selection: existing, but evolving, components

Assuming the product family components for new, common features have already been developed in the first phase, the next step is to address the components that currently have product-specific implementations, but share common features. In particular, the components that experience a high chance rate in response to new requirements, that preferably are orthogonal to the product portfolio, are of interest. Obviously, if opportunities exist for the development of shared components for new, common features, these should be pursued as well.

Architecture harmonisation: iterative product architecture harmonisation

With the increasing number of shared components, the cost of integrating these components in the product architecture often starts to become a concern. This calls for the design of a product family architecture that captures the commonality and variability of the products in the product family scope. The product teams use this architecture as a reference and aim to iteratively harmonize the product architecture with the product family architecture.