Divisions, R&D groups, and even project groups are typically responsibility centers and financial measures are used to evaluate their performance and allocate rewards and corporate resources. Where reuse crosses responsibility center boundaries, the costs of reuse reflect badly on the producer responsibility center if there is no mechanism to reallocate some of the consumer's benefit to the producer. In such cases, even if reuse is mandated by upper management and allowances are made to support production of reusable components, reuse goals tend to be subverted. Because production of reusable work products does not directly contribute to current product development, it is hard for project managers to resist raiding reuse producer resources under their control whenever product development projects come under pressure. While the cost of lost opportunities for the overall organization may far exceed any lost opportunity cost to the subgroup housing the production for reuse, it is the latter cost that is both most apparent to product managers and the basis for their evaluation. Some possible resolutions to this incentive problem are outlined below.
Producer Group as a Separate Cost Center
One way to circumvent the need to redistribute reuse benefits, is to
separate component producers and support personnel from project
teams, and make the producer and support groups cost centers. This
approach may still encounter problems if the producer cost center is
housed in a divisional profit center when reuse of the components
crosses divisional boundaries. This is because the division that incurs
all of the reuse investment does not receive all of the benefit. If this
is the case, the cost center should be placed at a higher level in the
organization.
Barter
One approach to evening out the reuse investment burden is to
allocate the development of components to members of a
``consortium'' of development projects. This barter system has some
appeal because the exchange obviates the need to establish prices or to
restructure the organization. However, as the pressure to get products
out rises, engineers tend to get shifted from reuse production/support
activities to more directly product-oriented activities.
Transfer Prices
Transfer pricing is one of the most frequently used mechanisms for
providing supplying responsibility centers with market-like efficiency
incentives. Where there is an external market price, that is the most
efficient transfer price to use. In the context of domain-specific reuse,
however, it is likely that in many cases components will be regarded as
proprietary and essential to the organization's competitive advantage,
so that no external market will exist. There are a number of other
possible approaches to setting the transfer price. One alternative is to
set the total transfer price equal to the producer's cost, and to charge
consumers some portion thereof. Even this approach is not
straightforward in the reuse context, since future reuse instances are
uncertain. Bollinger and Pfleeger [#!BP89!#] identify a number of
possibilities for amortizing the producer cost, including flat rate
amortization, biased flat rate amortization, and accelerated
amortization. Another alternative is to allow the managers involved to
bargain over the components to be delivered, and the transfer price to
be paid for them.
Incentive to Utilize Reuse Components
Product teams are responsible for the development of products best
suited to their target market segment, and high levels of reuse are
generally attained only at the expense of some degree of compromise on
individual optimization of features and performance. The functionality
that is considered common to a group of products is frequently a
decision variable that is subject to tradeoffs between better suiting
individual customer segments, and extending the commonality and
consequent economies of scope in development and maintenance. As
a result of the tension between individual product optimization and
product family benefit from reuse, the estimated reuse benefits and
the progress toward attaining the expected benefits should be shared
with the product teams so that they can make informed tradeoff
decisions. Fortunately, however, this tension is somewhat ameliorated
in many markets where customers are coming to value greater
consistency in product lines because this allows them to share their
investment in training, documentation, peripherals and the like among
related products. This enhances the software development
organization's opportunity to broaden the scope of common
functionality and retain the loyalty of customers to boot.