Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Funding
Launching and Institutionalizing
Market Analysis
Operations
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Training
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

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:

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

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]:

  1. 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
  2. estimating the likely costs and potential risks of all alternatives
  3. estimating the likely benefits contrasted with the current business practice
  4. developing a proposal for proceeding
  5. 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:

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:

Cost Basis for Business Case Assessment

Cost Basis for Business Case Assessment1

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:

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

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:

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]

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.

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

Further Reading

[Baldwin 2002a]
Baldwin and Clark describe how net options value applies decisions regarding software modularity.

[Boehm 2004a]
Boehm presents the COPLIMO.

[Clements 2002c, p. 226]
In the sidebar "It Takes Two," Clements and Northrop make a close examination of the payoff point for software product lines.

[Cohen 2003a]
Cohen discusses when software product lines pay off, which is at the heart of any business case.

[Ganesan 2006a]
Researchers from the Fraunhofer Institute and Hitachi have shown how to use SIMPLE to calculate reliable ROI predictions in the face of uncertain input values and a core asset base that becomes harder to use as the number of products increases over time.

[Humphrey 2000a]
Watts Humphrey's article provides an example of how to make a business case for process improvement. It assumes that management is thinking strategically and will consider investments that may take a few years to pay off.

[Reifer 1997a]
Reifer provides an excellent set of guidelines for developing a business case to support a reuse effort. Topics include scoping the market, developing the business case, and preparing financial data. This book also includes a sample business case and the steps used to prepare it.

[SEI 2007h]
This Web site provides more information about SIMPLE.

[Weiss 1999a, pp. 45-49]
Weiss and Lai present a short but useful section on building a product line business case in their book Software Product-Line Engineering.

Next Section Table of Contents Previous Section

 

1 In this figure, cost is synonymous with effort.