Case Study: Building and Communicating a Business Case for a DoD Product Line

2   Building the Business Case

The product line approach must maintain the current high standards of system performance, while reducing the acquisition cycle. However, the conversion to a product line approach takes time, so its benefits may not be apparent, or available, immediately. Given this understanding and the SPO’s desire to achieve goals quickly, the business case team examined the current acquisition approach and alternative product line strategies. At the same time, the business case team worked with other teams already looking at product line scope and goals.

A business case operates under a set of assumptions. To develop these assumptions, the team determined the scope of the product line, analyzed possible future products, and reviewed organizational goals.

The product line scope covers a set of services (or features) that address product line requirements, the systems themselves, and interfaces to other systems that must be supported. In this instance, the SPO determined that it will field three systems (Systems A, B, and C) in the product line over the next five years. In addition, the SPO will acquire two variants of System B, namely B1 and B2.

Table 1 describes the product line scope by summarizing the systems and their respective capabilities. Even though the product line scope only reflects a high-level estimate, it is sufficient for building the business case.

Table 1: Future Product Line Products

The SPO established three goals for its product line approach:

1. Develop a core software asset base. It must address interfaces and features in terms of requirements, architecture, and components. It must also include a production plan to generate actual product line systems.
2. Develop an efficient system integration capability. The current approach requires too much rework in order to integrate new interfaces or features.
3. Develop a product line architecture that enables the SPO to add or change functionality with minimal impact to current user interfaces.

The SPO also developed lower-level objectives to measure the product line goals and to set time tables. For example, within one year, there must be a sufficiently rich asset base to construct a working sub-system prototype.

Based on these assumptions, the business case team then identified potential development scenarios (assets and products) and alternative product line strategies [Bergey 01]. These efforts helped assure higher management that all options were being considered and that a single strategic reuse decision would not be forced on them. These efforts also gave management insight into any proposed changes in terms of customer impact, costs, benefits, and time for implementation. The business case team ranked the alternative product line strategies by potential risks, benefits, and investment required.

Table 2 lists the alternative product line strategies.

The organization analyzed the cost categories for funding four systems over the next five years. The costs were expressed as either start-up or steady state. Start-up costs included planning and analysis, as well as infrastructure and core asset development. Steady-state costs included product development, sustainment, and evolution costs.

Figure 3 shows the complete breakdown of costs from product line initiation to implementation.

Based on the initial scope of the product line, the business case team estimated and compared likely costs of each alternative product line strategy. Figure 4 shows cumulative cost estimates for four successive projects, with and without product line scenarios. Weiss describes the assumptions, methods, and rationale behind the estimation process [Weiss 99]. 

Without core assets, the expense of producing each successive project accumulates based on the cost of development from scratch, or with minimal reuse. The following conclusions can be drawn for the DoD product line shown in Figure 4.

• There is an initial cost to develop assets and move to a product line approach. It included the cost of training, incentives, and tool development or procurement, as well as the actual cost to develop assets. Start-up costs were estimated at $23 million based on

  • historical data on hours/source lines of code
  • using lines of code delivered in legacy systems to predict size of asset base
  • development of first target system included in start-up
  • 10% investment in process improvement added to other development costs
    

• With each successive project, cumulative asset costs increase due to improvements in the assets or due to the effort in developing new assets. These are considered sustainment costs. The total sustainment cost was developed by adding 5% to the baseline cost for each successive application of the assets.<
  

The business case team estimated cumulative costs of a product line approach at $36 million. This figure included startup and asset development and sustainment costs for all four projects. It did not consider the net present value of the up-front investment.

• asset baseline costs: $23M (includes costs for training)
• asset sustainment costs for developing 4 systems: $4M (5% of baseline cost per system)
• product development costs: $3M per system after initial system (for a total of $9M)

By comparison, the cost of developing the four systems independently was estimated at $38 million. This figure was based on the total lines of code produced or modified times cost per line for new versions of the legacy systems.

These figures showed that the business case for a product line approach could not be made on cost savings alone. The relatively low costs for new versions of Systems B1, B2, and C cancel out the much higher cost of System A. A cost-driven business case would require another new version of System A to prove the value of the product line approach.

As an alternative, the business case team considered phasing in product line assets, rather than incurring the total asset development cost up-front. This would lower start-up cost, but increase asset sustainment and further asset production costs. The phase-in approach was considered too risky. There was insufficient assurance that the asset base would grow to meet the demand.

Development and sustainment costs represent obvious ways to measure the worth of the product line approach. However, there are others. Once new versions of the legacy systems are fielded, each must be separately maintained. Over the next five years, systems B2 and C will add interfaces not present in earlier releases of Systems A and B1. Maintenance of A and B1 must include these interfaces.

Under the current development method, the SPO needed to contract with multiple organizations to deploy interfaces across each platform. Under the product line approach, common interfaces would be developed from the start. Therefore, the business case team compared long-term maintenance costs to make its case and achieve the SPO’s goal of an efficient system integration capability. The team found the following:

• Maintenance for the four systems developed under the current method will cost $38 million.
• Under the product line approach, the cost of maintenance will build by $13 million per system over the same period.
• By the end of the four-year maintenance cycle, the product line approach will save the SPO $25 million.

In short, the maintenance argument would justify the initial product line investment, if all systems are maintained for four years after initial deployment.