A Framework for Software Product Line Practice, Version 5.0

Building a Business Case

A business case is a tool that helps you make business decisions by predicting how they will affect your organization. Initially, the decision will be a go/no-go for pursuing a new business opportunity or approach. After initiation, the business case is reviewed to assess the accuracy of initial estimates and then updated to examine new or alternative angles on the opportunity. As an important communications vehicle, the business case identifies the goals and measures for tracking the move to the new business or approach. It includes the methods and rationale used for quantifying the benefits and costs and lists the critical success factors and contingencies that must be managed in order for the predicted results to appear [Schmidt 2003a]. By documenting the expected costs, benefits, and risks, the business case serves as a repository of the business and marketing data. In this role, management uses the business case to determine possible courses of action.

A business case addresses the following key questions that an organization faces when planning major changes in how it does business:

What specific changes must occur?
What are the benefits of making the change?
What are the costs and risks?
How do we measure success?

An effective business case must convince management that the investment is financially sound, is realistic for the organization, is aligned with other business strategies, and has a clear course of action for putting the change into effect. Business case results are often summarized using several well-defined financial metrics such as net cash flow, discounted cash flow, internal rate of return, and payback period [Schmidt 2003a]. Business cases may also be made based on opportunities that result from taking a certain course of action, for example, opening up new markets. Net options value is one such approach that may be incorporated into a business case. It has been applied specifically in making decisions regarding software modularity [Baldwin 2002a].

The need for a change is often precipitated by a market analysis that tells an organization what it needs to do in order to stay competitive in a particular mission or market area. That analysis begins the process of defining the change. The business case then determines the best approach for meeting those needs. A business case may consider multiple alternatives or look at one proposed solution. In either case, it compares how business is currently handled to how business will have to be handled in the future if the company pursues a potential business opportunity.

The business case documents how closely aligned the opportunity is with established business goals for such things as

reduced time to market
reduced cost
higher productivity
improved quality
increased customer base or bigger market share
ease of upgrades

It reinforces the motivation for making the change by offering a broad, quantifiable assessment of the opportunity. The goal of a business case is to provide management with a sufficient understanding of the approach and adequate data to determine if the projected return on investment (ROI) is sufficient to justify the proposed venture.

The business case should be maintained as a separate document. There is no standard template for a business case, but it should address the following tasks [Humphrey 2000a]:

deciding what to do: list any assumptions (market conditions, organizational goals, and so on), develop alternative approaches, and then either choose one or decide to build a comparison
estimating the likely costs and potential risks of all alternatives
estimating the likely benefits contrasted with the current business practice
developing a proposal for proceeding
closing the deal: how to make final adjustments and proceed to execution

Aspects Peculiar to Product Lines

A business case in a product line context can serve one of two purposes. The first is to justify the effort to adopt the product line approach for building systems. The second is to decide whether or not to include a particular product as a member of a product line.

A software product line effort represents an investment in resources and technology. Any organization that adopts a product line approach should have sound business reasons, backed up by data and experience, for doing so. Specific time-to-market improvement, product quality goals, cost targets for product development and delivery, new market growth, and product risk reduction are factors that are often included in the business case. The business case should identify the customers for the products that will be part of the product line, as well as the costs and benefits to those customers and the organization producing the products. Also, it should be directly supportive of higher organizational and/or corporate goals and vision. The business case should be agreed on, documented, communicated to the entire organization, and then validated by market analysis and organizational experience and expertise. The business case includes the product line goals that will, in turn, drive the data to be collected and the measures to be tracked.

Business case practices for product lines differ only in the nature of the changes being considered and analyzed. The organization is making an economic case built on the current costs of doing business versus a product line approach. Here, the initial go/no-go decision answers the question: "Do we build the set of products we're considering as a product line or not?" As part of the business case analysis, the organization determines how many products are likely to be built in the product line over a certain time, who the customers will be, and whether a product line approach compares favorably with other business opportunities [Reifer 1997a].

The business case reflects the facts and assumptions from the examination of relevant domains, the product line scope, and the market analysis, and it answers the following ancillary questions:

Do we have the right capability and resources to launch a product line?
Can we leverage our domain understanding to provide a unique opportunity and create market demand for our product line?
What are the financial and business consequences of adopting a product line approach?

The business case may determine that product lines are not a viable approach. For example, if the market for future products is small or won't support more than a very few product variants, there is little incentive to invest in a product line for those products. Predicting future products may be difficult if the market is unstable, so the business case may also propose alternative production methods for a product line approach. For example, investment in software generator technology may be recommended if a large number of very similar products are likely, or in manual software composition if the market forecast is for smaller numbers of products. Identifying alternative product line approaches for the business case helps assure management that all the options have been considered and that a single strategic reuse decision is not being forced on them. The business case may also propose a business model, such as fielding an architecture and components that system developers from other organizations will use for their products. In any of these product line situations, management will still expect the business case to define the change being proposed, how it differs from current practice, why it's better, its financial consequences, and how management will know whether the goals are being met.

Based on the initial scope of the product line, you can estimate and compare the likely costs and potential risks of each alternative approach. The following figure is an example of the cumulative cost estimates for three successive projects, both with and without taking a product line approach. The cumulative cost of the three projects without taking the product line approach is shown by the columns. The sloping lines show the cost with the product line approach, as follows:

There is an initial start-up cost (shown in the figure as 30 units of effort) for moving to a product line approach. In addition to costs for developing core assets, the business case must indicate the cost of adopting processes for product lines, including the costs of training, incentives, and tool development or procurement. In the figure, this cost is shown as accruing even before the launch of the first project.
With each successive project, core assets must be maintained and enhanced, and new core assets added. Thus, the cumulative cost for developing core assets increases over time (as shown by the lower line in the figure).
In the figure, the "Production Cost with Assets" line represents the cumulative effort of developing all three projects shown. Project cost includes the start-up cost, the cost of enhancing the core asset base for that project, and the cost of project-specific development.

Cost Basis for Business Case Assessment¹

The figure shows that, in this example, the third project represents the payoff point for the product line approach, because the cumulative cost of the third project without the product line approach exceeds the cumulative cost of the third project with the product line approach.

If cost reduction is a key business driver and the cumulative cost of production with core assets is greater than the cost without core assets at some desired break-even point, the organization will likely make a no-go decision. The figure represents only the cumulative production costs, however. If other factors, such as the time to market, market share, or market agility, are drivers and those goals can be met through the product line approach, the organization may forgo an early break-even point on costs in favor of the other factors.

Organizations also estimate anticipated benefits based on market and historical data. These benefits may include factors such as productivity increase, defect reduction, time to market, or reduced costs of integration. The business case may propose alternative approaches and prioritize them on the basis of relative cost versus benefits and risks. In making specific recommendations, the analysis included in the business case looks at the approaches in terms of meeting or exceeding criteria established by the organization.

Application to Core Asset Development

First of all, the business case for the entire product line is, itself, a valuable core asset that should be documented, maintained, and periodically revisited to make sure that the organization's goals are still being adequately served. Because it will inform the product line's scope (see the "Scoping" practice area), the business case must be available and current. Second, the business case for an individual product can be reused with some variation when the next product decision has to be made.

Beyond being a core asset in its own right, the business case for the product line is used to justify the effort to build other core assets. The development of the initial business case occurs during an early cycle of product line activity, dedicated to making the initial go/no-go decision. If the business case proposals are accepted and product line development gets underway, the business case supports core asset development, as a living document designed to reflect changing market conditions and the coordinated product line response and to measure the achievement of desired results. In this later cycle, the organization may develop a business case to determine whether to extend the product line scope, add new components, pursue new customers, or address other new opportunities related to the product line.

Application to Product Development

As products in the product line are developed, the role of the business case evolves within the organization to become a more tactical document. It supports the decision about whether to develop a proposed product as a member of the product line. In this case, the same questions apply, suitably modified:

Do we have the right capability and resources to build this product as a member of our product line?
Can we leverage our domain understanding to provide a unique opportunity and create market demand for this product?
What are the financial and business consequences of including this product in our product line?

Strategic considerations may apply. For example, a strong business case may be made for a product that, by itself, will not be profitable but will give the organization a toehold in a new application area.

In addition, the business case supports decisions to direct or redirect resources during the product development and evolution phases for

further requirements analysis to extend the core asset base
core asset refinement in response to product development
new architectural aspects/development
product development in new areas
continuing analysis of market conditions

To support the development of cost data, the business case must consider the financial and other business consequences of the chosen production method. There will be several ways for an organization to produce products. Factored into the business case are the cost, benefit, and risk consequences of the selected production method. Another business case decision considers users of core assets who will be producing the products. The organization developing the business case may be funding core assets for internal development or multiple external development organizations. These approaches may also lead to alternative considerations in the business case.

Example Practices

"Business case lite:" Sometimes circumstances make a business case extremely straightforward. In the case of CelsiusTech, the simultaneous awarding of two massive contracts (each of which was for a system beyond anything the company had ever attempted) precipitated a business case roughly as follows: "If we don't build these two systems based on a common set of core assets, our company will cease to exist" [Brownsword 1996a]. The implicit go/no-go decision resulting from this business case does not require much sophisticated analysis to resolve.

The CelsiusTech case is extreme but authentic (and not uncommon). There are less extreme cases that result in simple business cases as well. The FAST product line engineering method [Weiss 1999a] got its start not through the building of entire systems but rather through the building of different versions of highly changeable, relatively small subsystems restricted to a single domain (electronic message switching). The business case for a small number of small products is simplified, because the risk and required early investment are also small. In the case of FAST, the early costs included the overhead of the commonality and variability analysis plus the cost of designing a generator language and producing the corresponding generators–all of which were easily measured in person-days.

Estimating the likely costs and benefits: For each alternative, the organization makes reasonable estimates of costs that may be accrued at different times:

initial costs: These occur when the product line's core assets are developed and the initial products are fielded.
incremental costs: These occur whenever the product line is extended with new core assets. The extensions include improvements within the existing scope or an extension of the scope itself.
product development costs: These are associated with using core assets to develop products.
annual costs: These are upgrades made and annual maintenance costs incurred to fix defects. These costs may accrue for products or core assets.

The U.S. Federal Aviation Administration, Reifer, and Schmidt provide a variety of techniques for making cost estimates including [FAA 1995a, Reifer 1997a, Schmidt 2003a]

best practices
analogy or historical information
expert opinion
prototypes or pilots
parametric cost estimating, such as the Constructive Cost Model (COCOMO)–a well-known empirical cost estimation model

The organization must use the cost and risks of the current way of doing business to assess the benefits it hopes to realize through use of the product line approach. Benefits should be forecast for the short term as well as the long term, and these factors should be contrasted with "as-is" data.

The developers of the business case should resolve which of these (or other) goals are the primary drivers for deciding whether to launch a product line. Then, they should set ways to measure performance against these goals and identify indicators of success. Armed with the goals to be achieved, measures for tracking goals, and the timetable for achieving goals, you can make a reasonable business case. See the "Measurement and Tracking" practice area for more details.

Economic modeling: A business case for a software product line is likely to include an argument that the software product line will bring about economic advantages to the developing organization. An economic model can be used to support that claim. After specific costs and benefits have been identified, they can be estimated and aggregated to form an economic justification of the product line. This model can be used to calculate the potential return on investment from use of the product line strategy or to answer many what-if questions regarding various decisions about the product line.

The Structured Intuitive Model for Product Line Economics (SIMPLE) is an economic models specifically geared for software product lines [Clements 2005a] . It consists of four cost functions and a benefit function.

C_org() is a function that, given the relevant parameters, returns the cost to an organization of adopting the product line approach for its products. Such costs can include reorganization, process improvement, training, and any other necessary organizational remedies.
C_cab() is a function that, given the relevant parameters, returns the development cost to develop a core asset base suited to satisfy a particular scope.
C_unique() is a function that, given the relevant parameters, returns the development cost to develop unique software that is not based on a product line core asset base.
C_reuse() is a function that, given the relevant parameters, returns the development cost to reuse core assets in a core asset base. C_reuseincludes the cost of locating a core asset, checking it out of the repository, tailoring it for use in the intended application, and performing the extra integration tests associated with reusing core assets.
B_{ben_j}(t) is a function that–given a specific benefit, ben_j, of the product line stratgey–returns the value of that benefit. A benefit function is defined for each benefit of interest and parameterized by the time period of interest, since the benefits may vary over time. A basic expression representing the costs and benefits of building a software product line is:

where n is the number of products in the product line and nbrBenefits is the number of separately computed benefit functions. However, SIMPLE's cost snd benefit functions can be combined in a variety of ways to model the costs and benefits of specific software product line decision alternatives.

Clements, McGregor, and Cohen provide several scenarios that describe typical product line decision points. They also provide the economic model that can be used to support the decisions in each scenario [Clements 2005a].

SIMPLE does not define specific implementations of the functions. Instead, it only specifies their meaning. leaving the modelers free to provide implementations that take advantage of the data and local knowledge they have about each cost or benefit. The implementations may be based on legacy data or estimation formulas.

Economic modeling can also be used during make/buy/mine/commission analysis. The basic functions can be defined in terms that allow the comparison of long-term cost savings among different development choices. Economic modeling is also useful in conjunction with the "Scoping" and "Market Analysis" practice areas.

COPLIMO: The Constructive Product Line Investment Model is based largely on the COCOMO for software cost estimation [Boehm 2004a]. The developers of the COPLIMO studied several product line and reuse efforts in order to establish key parameters that could predict costs. The model includes two components: a cost model for product line development and an annualized post-development, life-cycle extension. While not a business case method, the COPLIMO can be used as a model for gathering financial information that forms the core of a business case. One other noteworthy feature of COPLIMO is its treatment of post-development or sustainment activities that examines such qualities as ease of maintenance, variation mechanisms, and portability.

Practice Risks

An inadequate business case (or the lack of any business case at all) can set up a product line organization for failure, by inaccurately predicting the outcome of either a product line effort or an individual product launched from within a product line. If the prediction is too optimistic, the organization's investment will not be returned; if it is too pessimistic, the organization will shy away from what might have been a good opportunity. Failure to produce a business case will leave an organization without any way to judge whether the effort was successful. An inadequate business case can result from

insufficient data: It is usually necessary to set cost expectations early and then refine the cost information as the effort progresses. An organization needs time to overcome the "sticker shock" that is usually associated with product line adoption. If sufficient cost information is not developed early, the adoption will likely be on hold while the cost/benefit information is scrutinized and validated. That may cause a loss of momentum or possibly even the disbanding of the project.
unreliable historical data: Most cost development methods rely on good historical data, either from within the organization or from industry. The reliability of the data is essential to justify the approach proposed in the business case. The business case must be able to compare past, current, and projected costs, time to market, market share, and competitor information in order to make the case. While it may be possible to estimate prior results, those estimates will tend to weaken the argument.
approaches that fail to work across organizational boundaries: The business case must be specific to the organization's goals and mission. However, because product line approaches are new and cover a wide range of organizational, technical, and managerial issues, the business case must draw on cross-functional resources from across the organization. That activity will require careful planning and intergroup coordination to meet critical milestones, including budget timetables and personnel availability.
uncertain market conditions: How much will the transition cost? Who will use the core assets? How many products will be needed per year? How long will the product line last? The organization must consider a number of cost factors when developing the business case. While there may be a good basis for estimating the costs of software development, the costs of intangibles such as changing the process from single-system to product line orientation will be difficult to predict and measure. The ability to predict "core asset value" (the overall benefits of core assets to product development) includes making correct assumptions about how product developers will use the core assets. If fewer products than expected make use of the core assets, the overall cost per use will increase and affect the positive ROI and time it takes to reach the break-even point. Management is unlikely to provide continued support without achieving these important goals.
management indecision: The group developing the business case must understand the audience. This audience must include those who can make the final go/no-go decision for proceeding on the proposals contained in the business case. If the business case is presented to the wrong audience, there will be no decision. A business case that does not address the needs of the decision makers results in a no-go decision. Effective communication requires an understanding of the decision makers' value system in terms of the time to market or other financial considerations for commercial organizations. Also, the developers of the business case must determine up front whether the audience wants a range of choices from which to make a selection or a specific decision/policy package on which to base the go/no-go decision. If a decision to adopt the product line approach has been made already, decision makers are more likely to want a set of alternatives from which to choose a specific approach.
a shift in organizational goals and needs: If the goals and needs of the organization have shifted during the preparation of the business case, the results may not be useful or meaningful. If information is presented incorrectly, the business case will have no impact. As a result, there will be either a no-go decision or no decision at all, although facts may justify the business case as presented.