3.3.3 Component unit

When a first release of a shared component, or a set of components, is available, it frequently becomes necessary to create an explicit component unit that has responsibility for the component(s). In the case of a virtual component team, the team may even be converted into a unit.

Advantages. The responsibilities in the organization are clearly delineated and the places where trade-offs need to be made align with the boundaries in the R&D organization.

Disadvantages. The main disadvantage is that a component team has a clear risk of focussing more on its own goals than on the goals of the product teams, especially in the time dimension. There is a tendency in component teams to build a “perfect” component, rather than satisfying the immediate needs of the product teams.

3.4 Funding

In all commercial organizations, the final metric is “the bottom line”, i.e. the financial consequences of decisions. Adopting product families is no different in this respect. As the profit and loss responsibility in many organizations even exists at product team level, the development and evolution of shared components requires a suitable funding model. Below, we discuss three models for funding product family initiatives that are used in the software industry.

3.4.1 “Barter”

In organizations that use this model, the effort that is invested is not quantified in terms of effort or value. Instead, different product teams agree to develop shared components and to provide the components to the other product teams. Negotiations are based on a form of equal sharing of the development and evolution effort and on trust concerning the ability and willingness of the other teams to deliver their contributions in time and according to specifications.

Advantages. The main advantages are that this model requires no changes to the budget or the organization, lacks any bureaucratic overhead and can be initiated easily by a few enthusiastic people at the right places in the R&D organization.

Disadvantages. The hand-shake deals that are associated with this model require a high level of trust in the organization. One product team may run into delays in an ongoing project, causing delays in the delivery of shared components. Unforeseen events may easily put pressure on the agreements causing the initiative to fail.