11-619-lead-image

Relieving Joint Pain: Planning Government Acquisition of Complex Common Systems


To print a PDF copy of this article, click here.

Authors: Anthony C. Wicht and Edward F. Crawley

Commonality, an increasingly popular strategy in developing complex defense projects, leverages sharing or reuse across projects to significantly reduce life-cycle costs. Despite its potential within DoD as a best practice, programs focused on commonality have met with mixed success. This article argues that commonality strategies must be matched with complementary acquisition strategies to improve outcomes. Full, open competition is not the best acquisition strategy if commonality can unlock life-cycle affordability. Metrics and payment structures must consider the commonality goals to be achieved; otherwise, contractor motivations and government goals will be misaligned. The recommendations in this article draw on commonality research conducted on behalf of the National Aeronautics and Space Administration (NASA), which examined 19 DoD, commercial, and NASA case studies.


Commonality, the sharing of parts or processes across different products, has long been popular in commercial industries such as automotives and electronics because it reduces life-cycle costs and improves reliability. Today, commonality is enjoying increasing interest from the defense industry as the emphasis on life-cycle affordability strengthens (Brown & Flowe, 2005). Joint Services programs such as the Joint Strike Fighter (JSF) and Joint Tactical Radio System (JTRS) develop partially common systems that meet the needs of different Services. Other programs such as the National Polar-orbiting Operational Environmental Satellite System (NPOESS) attempt to exploit commonality between the needs of DoD and other agencies. Even within a single Service, commonality is a useful strategy, for example in the adaptation of the M577 command post vehicle from the M113 armored personnel carrier, which simplifies development and decreases logistics costs (Terry, Jackson, Ryley, Jones, & Wormell, 1991). The major benefit from commonality is affordability, which has increased attention on the strategy in recent years as defense budgets have tightened. Commonality will continue to be an important tool for acquisition professionals while cost pressure on defense budgets remains high.

Despite commonality’s promise of increased affordability, the performance of defense acquisition based on commonality has lagged behind comparable commercial projects. NPOESS was canceled, JTRS was fundamentally restructured in 2005, and the threat of Nunn-McCurdy breaches is still a factor in the program stability of the JSF. We hypothesized that the different acquisition environments between commercial and defense commonality projects were partly responsible. Therefore, the objective of the research was to examine current government acquisition practices in commonality, and synthesize a best-practice acquisition strategy for future commonality projects.

Extensive literature on commonality already exists; however, it focuses on the application of commonality platforms to business strategy (Meyer & Lehnerd, 1997; Robertson & Ulrich, 1998) or stops at the identification of technically feasible commonality. (For examples from the DoD context, see the RAND report by Held, Newsome, & Lewis, 2008.) Boas and Rhodes developed management approaches to commonality (Boas & Crawley, 2006; Rhodes, 2010), which built on the more general advice in the platforming literature, but no work on commonality was found that specifically examined acquisition. In the acquisition literature, Scherer’s unsurpassed economic analysis of the effect of acquisition strategy on weapon effectiveness in the DoD informed much of the analysis in the second half of this study (Scherer, 1964). Additionally, handbooks for the acquisition professional emphasize that the acquisition approach must take into account particulars of the acquisition at hand (Defense Acquisition University, 2011; Rendon & Snider, 2008). However, no piece of the acquisition literature delivered specific advice for acquiring common systems.

Objective and Outline

To fill this gap, this article aims to answer four questions:

  • Which principles from the extensive literature on commercial commonality form necessary background knowledge for the defense acquisition professional?
  • Which acquisition approaches represent best practice when formulating an acquisition strategy for a new Joint Services program, or an intra-Service program involving commonality?
  • Which additional contract terms such as payment provisions or intellectual property considerations improve acquisition outcomes in the commonality environment?
  • Are the acquisition regulations flexible enough to permit best-practice commonality acquisition?

At the outset, it is important to note that commonality is not the only approach for improving acquisition outcomes. Other product development philosophies such as flexibility, robustness, interoperability, adaptability, and open architectures are widely discussed in the literature and can improve the performance of acquisitions. Contrasting these alternative approaches is beyond the scope of this article; however, similar analysis to that presented in this article could be used to craft acquisition strategies that complement these development philosophies.

This article will first summarize the research method and sketch the case studies, followed by a presentation of the background concepts on commonality, which distinguish commonality-focused acquisitions from single-product acquisitions. Finally, the article will turn specifically to acquisition approaches, analyzing the alternative ways in which an acquisition could be approached and recommending specific strategies.

Research Method

The research in this article builds on 19 commonality case studies conducted by the MIT Space Systems Architecture Group (Boas, 2008; Hofstetter, 2009; Rhodes, 2010; Cameron, 2011; Wicht, 2011). Of these, 16 cases informed the general commonality principles presented in the first half of this article, and were instrumental in developing the concepts and process maps that identify commonality as a best practice. A further three case studies conducted by the authors were specifically targeted at acquisition and were complemented by 17 short interviews with DoD and NASA personnel involved in the acquisition process. The following paragraphs briefly describe the acquisition case studies; however, full reports on the cases are available in Wicht (2011). The three cases examined in detail were JTRS and two nongovernment launch vehicle manufacturers who requested anonymity.

JTRS was a Joint Services project to produce software-defined radios that were interoperable among the Services. Commonality of software between the radios was intended to deliver development and maintenance savings as well as performance benefits from improved interoperability. The initial architecture for the radios was designed by a working group including government and industry representatives. The detailed design and manufacture of the radio hardware and software were distributed across multiple contractors. Interviews with a range of former DoD personnel and consultants involved with JTRS were undertaken to capture how the acquisition approach affected the realized commonality.

The two commercial launch vehicle manufacturers both produce families of launch vehicles for DoD, NASA, and commercial applications. Both have worked as contractors to DoD or NASA previously. The launch vehicle manufacturers were examined because each had development tasks comparable in complexity to those undertaken by government agencies like DoD and NASA.

Two avenues of investigation were pursued. First, in their position as system integrator, how did the commercial companies structure their acquisitions to develop and maintain the right level of commonality? Second, in their position as a contractor to DoD or NASA, what potential pitfalls did they see in the commonality acquisition strategies proposed?

After conducting the case studies, acquisition approaches uncovered during the short interviews and case studies were qualitatively evaluated against the commonality process map. Acquisition structures were then graded as Good, Moderate, or Poor according to how well the structure itself facilitated the processes that underpin commonality. A second pass through the Good and Moderate approaches was then undertaken to refine contractor payments, incentives, intellectual property, and other provisions to develop acquisition strategies that best implement commonality.

Definitions

To understand the interaction between commonality and acquisition strategy, key commonality definitions and background are presented here. Although no widely agreed-upon definitions for commonality are prevalent throughout the defense acquisition community, an excellent RAND paper contains a DoD lexicon for commonality (Newsome, Lewis, & Held, 2007). The following simple definitions will be used in this article:

Common: having identical elements

Unique: the antithesis of common

Similar: some identical and some unique elements

Family: a set of similar end-items that perform different functions

Variant: any one member of a family

Commonality Concepts

Using these definitions, it is possible to summarize the concepts distilled from the 19 case studies and the product literature, which shape the application of commonality to real-world projects that an acquisition strategy must address.

Concept 1: Commonality is not an end in itself. The first concept is that commonality is not an end in itself. Commonality carries both advantages and disadvantages, and therefore the best project is not necessarily the one with more commonality. The optimum amount of commonality is that amount which best meets the customer’s needs in terms of life-cycle affordability and performance.

Seeing commonality as an enabler rather than an end goal carries two implications for acquisition. First, contractors should not be incentivized to target maximum commonality or fixed percentages of commonality because this misaligns contractor incentives and customer needs. Second, the benefits of commonality should be balanced against the costs of achieving it. The acquisition strategies recommended for commonality are likely to cost more to implement than full and open competition.

Concept 2: Realized commonality is always less than initially planned commonality (“divergence”). Boas demonstrated that the level of realized commonality is always less than the level initially planned. This decrease is called divergence. From Concept 1, it follows that divergence may be positive or negative for the project. Divergence is positive if it occurs to accommodate the emergence of new technologies, learning from the development of earlier variants or changes in the field conditions for the product. Divergence is negative if it stems from mismanagement or attempts to improve the performance of individual variants at the expense of the family.

The implication for acquisition is that the acquisition structures must have controls to limit detrimental divergence, but not penalize beneficial divergence. More generally, foreknowledge of the inevitability of divergence can help manage expectations, prepare more accurate project budgets and schedules, and avoid overreaction to a normal corollary of commonality development.

Concept 3: Commonality projects are offset in time. Boas also showed that complex development projects experience time offsets between the development of variants to lower the peaks in labor and capital demand. Offsets often mean that the first-in-time variant team develops the common systems, with a resultant bias toward the better defined needs of the first-in-time variant.

The implication of offsets for acquisition are twofold. One, the first-in-time project must be incentivized to consider the needs of all later-in-time projects during the first development phase. Two, the requirements for subsequent variants must be well defined when the first variant is undergoing concept studies. This requires earlier funding for the subsequent variants.

Concept 4: Commonality requires up-front cost and delivers benefits later in the product life cycle. Offsets lead to a consistent cost structure for commonality projects. The first-in-time variant bears the burden of developing all common systems before it is operational. This means the first-in-time variant incurs a cost penalty relative to the development cost of the other variants. In a sensible commonality program, the additional cost of commonality is recovered over the life cycle at the family level through lower development costs for subsequent variants and more effective sharing of recurring costs across the family.

The implication for acquisition is that development decisions must be taken based on life-cycle costs, not development costs, and based on family-level cost-benefit analysis, not variant-level cost-benefit analysis. If the first variant is to implement commonality, it must receive extra funding and high-level management support to permit spending on the up-front costs. Without these measures, first-in-time variants have no incentive to implement commonality.

Concept 5: Three commonality strategies exist—Reactive Reuse, Building Block, and Widespread Forward. Three general commonality strategies are observed (Boas, 2008). The simplest, Reactive Reuse, examines previous products for elements that could be used again in the next variant. The original products never planned for reuse, thus avoiding the up-front commonality costs pointed out in Concept 4. However, the Reactive Reuse benefits the project under development because it reduces development cost and risk, making it an attractive strategy. With such ad hoc reuse, substantial affordability improvements are difficult to achieve. When planning occurs during development of the first variant, commonality projects can share more effectively than one-way reuse.

Such thinking leads to Building Block commonality, which occurs when commonality of selected high-value systems is planned. The first variant in time develops a common building block that takes into account the needs of future variants and will be used in those future variants. Building Block commonality is a more sophisticated strategy than Reactive Reuse because it requires a trade between the cost of developing the building block and the life-cycle savings from commonality.

Widespread Forward commonality occurs when commonality becomes embedded into an organization’s engineering culture, and each design decision is examined for its commonality implications. In the 19 case studies examined, Widespread Forward commonality only occurred when one corporation tightly controlled the development process. Widespread Forward commonality is unlikely to be the right strategy for multicontractor government acquisition.
The implication of these three strategies for acquisition is that commonality can operate in three significantly different modes, and an acquisition strategy appropriate for one may not be appropriate for the others.

Synthesizing a Commonality Process Map

After reviewing these principles, commonality is clearly problematic for existing acquisition approaches. For example, how should a contractor be incentivized to develop a common system where directly measuring commonality is not a good reflection of the needs of the customer? How can programs funded year-to-year “invest” in commonality for future cost savings? Does the emphasis on competition in acquisition allow the sort of cooperation between contractors needed to develop common systems?

The first step in designing an effective acquisition strategy is to be clear about the steps required for a commonality acquisition. Figure 1 lists steps that represent a process map for Building Block commonality. The process map was developed by examining the 19 case studies and synthesizing lessons learned in the commonality projects studied into a set of best-practice steps. The process maps are consistent with the analysis of the case studies undertaken by Boas, Hofstetter, Rhodes, and Cameron.

Figure 1. Process Map for Building Block Commonality

Additional explanation of how the process maps fit the observed performance of commonality projects is presented in Wicht (2011). Slightly different process maps for the Reactive Reuse and Widespread Forward strategies were also developed. Space precludes their inclusion here; however, full details are presented in Wicht (2011), along with a full explanation of the elements of the process map and the tools that can be used to undertake the processes.

Figure 1 shows a process that consists of an entry gateway followed by three interactive processes: Identify, Evaluate, and Implement. The entry gateway screens commonality opportunities to allow only those opportunities suitable for Building Block commonality into the process steps. The Identify process takes the engineering environment of the potentially common systems and evaluates the technical feasibility and performance penalty of using common systems in place of unique. The second process, Evaluate, measures the benefits and drawbacks to the common solution under the assumed use case, compares those with the unique solution, and results in a decision to invest in the common building block or to pursue the unique solution instead. The third process is Implement, which manages divergence and requires reexamination of the cost-benefit analysis undertaken in the Evaluate process as the estimated costs and benefits become better known. The management of divergence through the Implement process is ongoing throughout the product life cycle.

Designing Acquisition Strategies for Commonality

Two levels of acquisition strategy are important in designing most commonality acquisitions. The family-level acquisition strategy considers the acquisition strategy applied to the family of products as a whole. It examines which organizations (if any) have responsibility for management, systems engineering, and design trade-offs across the whole family. The variant-level acquisition strategy considers the acquisition strategy at the level of the systems that integrate to produce a variant. It asks, for example, whether a single contractor is responsible for a single system across all variants, or whether each system is separately competed on each variant.

To illustrate these differences, a simplified example from the JTRS case study is presented in Figure 2. The top level (the family-level acquisition strategy) concerns the relationship between the organization or organizations responsible for producing Radio Type 1 and Radio Type 2. Different commonality outcomes could be expected if the same company was responsible for both radios compared to multiple competitors responsible for one type of radio each. The lower level (called variant level) in this example asks questions such as: Should the transmitter be separately competed for each radio? Should it be separately competed by the government and supplied as Government Furnished Equipment (GFE)? Or should both transmitters be awarded to a single company? Again, different commonality outcomes could be expected under these different acquisition structures.

Figure 2. Defense Radio Program

The variants are decomposed into their function because Hofstetter (2009) showed that the first gateway for technically feasible commonality is delivery of a common function. This is common sense: A single company developing the transmitters for two radios is more likely to deliver commonality than a single company developing the transmitter for one and the user interface for another.

The following questions will introduce and explore the best approaches for structuring the acquisition, first at the family level and then at the variant level.

Which Family-level Acquisition Structure Should Be Used?

Figure 3 displays three options for family-level acquisition structures, which were identified through the research, case studies, and interviews described in this section.

  • Single Total System Performance Responsibility (TSPR) Contractor. This approach awards a single contractor the responsibility for development of the whole family, often referred to as TSPR, or a Lead System Integrator (see Flood & Richard [2005] or Loudin [2010]).
  • Multiple Contractors plus Systems Engineering and Technical Assistance (SETA). The government’s systems engineering and integration capabilities are enhanced by awarding a contract for SETA to a separate contractor.
  • Multiple Prime Contractors. This approach is the traditional avenue of acquisition through competition. A contract is separately competed and awarded for each variant.

Figure 3. Government Involvement in Systems Engineering and Integration

Each strategy was analyzed for its effect on commonality by separately considering how well each process step shown in Figure 1 could be undertaken under the particular acquisition strategy. The three case studies and 17 additional interviews yielded extensive information about how each of the acquisition strategies performed in helping to achieve the key commonality processes identified in the process maps. A table was used to score each acquisition strategy at the family and variant levels against the processes required by best-practice commonality for each strategy, as shown in the process maps discussed earlier. Four scores were possible: (a) under this acquisition strategy, the process step was more likely to be achieved; (b) under this acquisition strategy, the process step was less likely to be achieved; (c) under this acquisition strategy, there would be no effect on achieving the process step; or (d) under this acquisition strategy, the likelihood of achieving the process step could increase or decrease, depending on other factors.

Figure 4 presents an example of an analysis for the specific case of an acquisition strategy using a directed subcontractor (basically, selecting a contractor that has built the system in a previous variant without a competitive process). Each of the three commonality strategies (Reactive Reuse, Building Block, and Widespread Forward) head a pair of columns. The left-hand column describes the commonality process steps necessary for best-practice commonality, and the right-hand column contains an assessment of how well that process would be performed with a directed subcontractor acquisition strategy, color coded by the four possible scores. The complete set of tables covering every acquisition strategy is detailed in Wicht (2011). The analysis is coarse, but this level of detail was justified because it revealed enough to draw new conclusions about how acquisition structures for commonality should be conducted.

Figure 4. Evaluation of Directed Contractor (Variant-Level Strategy)

The analysis concluded that effective family-level acquisition structures have three roles in commonality:

  • They provide strong systems engineering to arbitrate performance-affordability trades made by the variants.
  • They provide strong management to resist variant-level improvements in cost or performance if they adversely affects the family.
  • They share information and intellectual property between the variants.

However, the extent to which the acquisition structures achieve this depends on the strength of systems engineering within the government program office and the force of intellectual property provisions within the contract.

Figure 5 shows the results of the family-level analysis in more detail. The first conclusion is that if the government systems engineering capabilities are strong, then any of the strategies are likely to be successful. Factors other than commonality can be allowed to govern the choice of family-level acquisition strategy, and attention should be focused instead on the variant-level acquisition strategy. In this context, “strong” government systems engineering includes the ability to assess commonality benefits and drawbacks across the whole family life cycle; the ability to communicate requirements from interfacing systems across the whole family to the team developing the common system; and the capability to resist unjustified variant-level divergence that is detrimental to family life-cycle cost and performance.

Figure 5. Three Roles of Commonality in Effective Family-Level Acquisition Structures

The conclusions to be drawn from the family-level analysis shown in Figure 5 are fourfold. First, if government systems engineering is weak, then independent systems engineering from a SETA organization is probably preferable to adopting a TSPR approach. Second, if existing (or generated) intellectual property is likely to be involved in the common elements, then the rights to use that intellectual property throughout the family should be included. Third, the applicability of a family-level structure is not affected by the type of commonality that will be implemented. Reactive Reuse, Building Block, and Widespread Forward commonality all require good systems engineering, strong management, and effective information sharing. However, if any are weak, then the more sophisticated commonality approaches should be ruled out. The program should implement Reactive Reuse or discard commonality as the architecting strategy.
The fourth and final conclusion revealed by the analysis was that the family-level acquisition strategies are not strongly coupled with the performance of the variant-level acquisition strategies, which allows the family-level structures and the variant-level structures to be evaluated separately. The variant-level acquisition strategies are examined in the following section.

Which Variant-level Structure Should be Used?

For the variant-level structures, six possibilities were considered (Figure 6).

  • Fully competitive. The system is acquired by allowing all qualified bidders to submit proposals for each system and choosing the best system independently for each variant.
  • Joint venture. A joint venture between two organizations is formed to build two systems, when, in the absence of the joint venture, the organizations would have built one each.
  • Directed contractor. A contractor that has built the system in a previous variant is selected without a competitive process.
  • Long-term supplier. A contractor is chosen competitively as the sole supplier of a particular system across all variants.
  • Build-to-print. Detailed system specifications are provided by the government for contractors to build to on each variant.
  • GFE. A completed system is supplied directly to a contractor by the government.

Figure 6. Choosing a Variant-Level Possibility (Six Possible Scenarios)

Not all of the system acquisition strategy variant-level structures are equally favored within the acquisition community. For example, directed contractors are not preferred when full and open competition is available, but if sufficient justification exists, then a sole-source acquisition could be used:

Agencies acquiring major systems shall… (b) sustain effective competition between alternate systems and sources for as long as is beneficial. (Federal Acquisition Regulation [FAR] Subpart 34.002)

Figure 7 shows the relative support for each system acquisition strategy variant-level structure within the acquisition community, divided into Good, Moderate, and Poor support. The six variant-level structures are then examined for effect on the commonality processes. At this stage, the contract is assumed to simply reflect the natural incentives of its structure, without specific contract terms, which will be investigated in the next section. Figure 8 summarizes the analysis of the variant-level strategies.

Figure 7. Support Within Acquisition Community of Each System Acquisition Strategy Variant – Level Structure

Figure 8. Effect of Contract Structure Alone on Commonality

The first point evidenced from Figure 8 is that the variant-level strategy needs to be matched with the commonality strategy. For example, a directed contractor works well for Reactive Reuse, but poorly for Building Block and Widespread Forward commonality. This in part explains why defense projects struggle to achieve effective commonality: the acquisition strategy most often used for commonality acquisition projects in the defense industry is Fully Competitive, which performs moderately well for Reactive Reuse, and poorly for Building Block and Widespread Forward commonality.

The strategies that work well for Reactive Reuse are the strategies that place the reused system and the system to be developed under one contractor. In an approximate order of preference, and taking into account Figures 7 and 8:

  • A directed contractor is a good strategy because the contractor has the intellectual property and practical know-how to reuse its previous system. There is clear justification for sole-sourcing in this instance, so acquisition regulations are unlikely to be problematic.
  • A joint venture between the contractors who are to develop the two systems works well for reuse; however, this will only be appropriate in circumstances where the joint venture would be natural in the market. Incentivizing the joint venture may create economic responsibilities for the government that outweigh commonality savings.
  • Creating a long-term supplier for a particular system works well to encourage reuse. The disadvantage is that it is difficult to justify under acquisition regulations because the long-term supplier must obtain a contract for the duration of the family development, which for many acquisitions may be a decade or more.

The strategies that work well for developing Building Block commonality are:

  • A Build-to-Print strategy, where the government creates the design for the common building block, which is then competitively manufactured for each variant. This works well when the design is well known at the outset, and when divergence is likely to be low—for example, in low-clockspeed industries.
  • A GFE strategy, where the building block is developed and manufactured by the government (or a separate contractor to the government) and supplied to each variant. This approach is more tolerant of divergence than Build-to-Print because the government can manage divergence that occurs as a result of learning during manufacturing, and could be used on higher technology projects. However, both government and contractors expressed aversion to GFE projects due to programmatic and liability risks.
  • Creating a long-term supplier responsible for the building blocks on an ongoing basis. This relieves the government of responsibility for developing the building block, but raises the same sole-sourcing concerns mentioned in Reactive Reuse.

The poor performance of strategies on Widespread Forward commonality reinforces the observation made in Concept 5 that it is an inappropriate strategy for multicontractor acquisitions. If Widespread Forward were to be used, establishing a long-term contractor for the system across all variants is likely to be the most successful strategy.

Of course, an acquisition strategy is about more than contract structure. Several examples were found in the acquisition case studies of the same subcontractor producing unique designs for different customers with similar needs. The provisions of the contract dealing with issues such as payment structure and intellectual property affect the acquisition result, and were investigated in detail in the case studies and scoping interviews. Figure 9 summarizes the recommended contract additions for those strategies that were graded Medium or Good in Figure 8.

Figure 9. Contracting Additions That Improve Viable Structures

In Reactive Reuse, contracts were improved through the use of fixed-price contracts for development and manufacture. The fixed-price contract incentivizes reductions in the up-front development cost, thereby encouraging reuse. An award fee based on thorough investigation and evaluation of commonality may also help.

Incentive fees may also be considered in Reactive Reuse, especially if there will be benefits to the government through the life cycle from commonality, not just a reduction in up-front cost. Incentive fees should not be tied to fixed levels of commonality, for example, paying a fee based on the percentage of commonality achieved because this discourages an analysis of whether a particular reuse opportunity is net-beneficial. It also raises very practical difficulties in assessing whether any incentive should be paid for two similar parts. Instead, base incentive fees on a transparent life-cycle cost model if one is available. Basing incentive fees on a life-cycle cost model developed and maintained by the contractor should be avoided. The case study that did this had difficulty establishing wide confidence in the model.

An additional consideration for reuse is that the requirements of the contract should be expressed only in terms of minimum acceptable performance (though incentive fees could be offered for improvements) so that trades can be made between performance and affordability. Every instance of reuse examined in our case studies involved this trade. Overconstraining the performance specification will hamper efforts to implement commonality.

Finally, consideration should be given to intellectual property provisions. The contractor should be given relevant access to government-owned intellectual property to increase the range and quality of elements that the contractor may reuse. Consider also obtaining rights to the new intellectual property developed in the design to allow unplanned reuse by subsequent designs.
Building Block commonality benefits from many of the same contract provisions. The required performance should not be overconstrained, and the contractor should be encouraged to trade affordability and performance.

However, the payment basis to the contractor should be different for Reactive Reuse. A cost-plus contract is preferable because it enables the contractor to investigate a wider range of commonality opportunities and develop the best building block, even if it costs more initially. Incentive payments based on the estimated life-cycle cost of the building block can be used to ensure the building block does not become overdesigned. An award fee and close supervision by a government systems engineering team will further reduce the risk of abuse of the cost-plus structure.

The intellectual property in the building block must be obtained by the government, with the right to license it to other parties; otherwise, the government risks price increases by the building block contractor because of the government’s high cost to switch contractors.

Analysis of Acquisition Regulations

During the course of this analysis, the FAR and DoD 5000.2 were closely examined. No major changes were considered necessary to improve commonality projects. The sections that permit sole-sourcing adequately cover the rationale for commonality sole-sourcing, for example FAR 6.302(1)(a)(ii).

However, several trends in defense acquisition impact commonality acquisition. The emphasis on open architectures (Rendon & Snider, 2008, p. 59) is in tension with commonality because it encourages a proliferation of innovative designs rather than the consistent use of a single design. For many programs, open architectures may be the preferred solution, but it is important to recognize that commonality and openness are mutually exclusive strategies. The trend toward greater use of commercial off-the-shelf products is synergistic with commonality because it encourages the same performance-affordability trades (and can be seen as a particularly widespread form of Reactive Reuse). Finally, the trend toward fully funding acquisitions and allowing the Services to retain amounts saved on acquisitions (Carter, 2010, p. 3) is likely to improve commonality outcomes because it encourages projects to “invest” in common building blocks over time.

Recommendations

Five recommendations are set forth as a result of this research:

  1. Defense acquisitions that seek to use commonality to improve affordability must integrate the commonality strategy and the acquisition strategy.
  2. The family-level contract and management structure must be built around a strong systems engineering team, which has the vision and authority to force variants into performance-affordability compromises that achieve value at the family level.
  3. At the variant level, traditional competitive procurement approaches do not work well for commonality, and sole-sourcing, GFE, and Build-to-Print approaches should be considered instead.
  4. The payment structure, incentive and award fees, performance specifications, and intellectual property provisions of the contract must all be considered from a commonality viewpoint for a successful project.
  5. No changes to the FAR are required to implement effective commonality.

Conclusions

Simply transplanting the principle of commonality from commercial product development, without regard to the different approaches used in government acquisition, invites disaster. In particular, the government acquisitions with the most to gain from commonality are those with a mix of contractors are working independently on projects that overlap significantly. Commonality is not implemented over such distributed development frameworks in commercial development, and government acquisition must break new ground. Understanding how to use an acquisition strategy to incentivize sensible commonality between companies is a critical step in allowing commonality to realize its affordability promise.


 To print a PDF copy of this article, click here.

Author Biographies

Anthony C WichtMr. Anthony C. Wicht completed a Master of Science in Aeronautics and Astronautics at Massachusetts Institute of Technology (MIT) in 2011. He also holds a Bachelor of Laws degree and a Bachelor of Engineering degree with First Class Honours from the University of New South Wales, Australia. His research at MIT focused on architecting complex engineering systems like space infrastructure. Prior to MIT, Mr. Wicht worked as a project finance lawyer at a major Australian law firm on legal aspects of financing and constructing large engineering projects. He is a former president of the National Space Society of Australia and is co-chair of the Australian Space Development Conference series.

(E-mail address: Anthony.wicht@gmail.com)

Dr Edward F CrawleyDr. Edward F. Crawley is the Ford Professor of Engineering at MIT and is a Professor of Aeronautics and Astronautics and Professor of Engineering Systems. He received a Bachelor of Science in Computer Science and Engineering and a Doctor of Science in Aerospace Engineering from MIT. He has served as the department head of Aeronautics and Astronautics at MIT, the executive director of the Cambridge–MIT Institute, and currently serves as the director of the Bernard M. Gordon–MIT Engineering Leadership Program. His research focuses on the domain of architecture, design, and decision support in complex technical systems that involves economic and stakeholder issues. Dr. Crawley is a Fellow of the American Institute of Aeronautics and Astronautics and the Royal Aeronautical Society, United Kingdom (UK), and is a member of three national academies of engineering in Sweden, the UK, and the United States. He has founded three entrepreneurial companies and currently sits on several corporate boards.

(E-mail address: crawley@mit.edu)


References

Boas, R. C. (2008). Commonality in complex product families: Implications of divergence and lifecycle offsets. Cambridge, MA: Massachusetts Institute of Technology.

Boas, R. C., & Crawley, E. F. (2006, July). Extending platforming to the sequential development of system families. Paper presented at the Sixteenth Annual International Symposium of the International Council on Systems Engineering (INCOSE), Orlando, FL.

Brown, M. M., & Flowe, R. (2005, April). Joint capabilities and systems-of-systems solutions. Defense Acquisition Review Journal, 12(2), 137–153.

Cameron, B. (2011). Costing commonality: Evaluating the impact of platform divergence on internal investment returns. Cambridge, MA: Massachusetts Institute of Technology.

Carter, A. B. (2010, September 14). Better buying power: Guidance for obtaining greater efficiency and productivity in defense spending [Memorandum]. Washington, DC: Office of the Under Secretary of Defense for Acquisition, Technology and Logistics.

Defense Acquisition University. (2011). Defense acquisition guidebook. Retrieved from https://dag.dau.mil/Pages/Default.aspx

Flood, S., & Richard, P. (2005–2006, December–March). An assessment of the lead systems integrator concept as applied to the future combat system program. Defense Acquisition Review Journal, 12(4), 355–373.

Held, T., Newsome, B., & Lewis, M. (2008). Commonality in military equipment: A framework to improve acquisition decisions. Santa Monica, CA: RAND Corporation.
Hofstetter, W. (2009). A framework for the architecting of aerospace systems portfolios with commonality. Cambridge, MA: Massachusetts Institute of Technology.

Loudin, K. H. (2010, January). Lead system integrators: A post-acquisition reform perspective. Defense Acquisition Review Journal, 17(1), 27– 44.

Meyer, M., & Lehnerd, A. (1997). The power of product platforms: Building value and cost leadership. New York, NY: The Free Press.

Newsome, B., Lewis, M. W., & Held, T. (2007). Speaking with a commonality language: A lexicon for system and component development. Santa Monica, CA: RAND Arroyo Center.

Rendon, R. G., & Snider, K. F. (2008). Management of defense acquisition projects. Library of Flight Series. Reston, VA: American Institute of Aeronautics and Astronautics.
Rhodes, R. (2010). Application and management of commonality within NASA systems. Cambridge, MA: Massachusetts Institute of Technology.

Robertson, D., & Ulrich, K. (1998). Planning for product platforms. Sloan Management Review, 39(4), 19–31.

Scherer, F. M. (1964). The weapons acquisition process: Economic incentives. Cambridge, MA: Harvard Business School Press.

Terry, T. W., Jackson, S. R., Ryley, C. E. S., Jones, B. E., & Wormell, P. J. H. (1991). Fighting vehicles. Land Warfare: Brassey’s New Battlefield Weapons Systems and Technology Series, Volume 7. London: Macmillan Publishing Company.

Wicht, A. (2011). Acquisition strategies for commonality across complex aerospace systems-of-systems. Cambridge, MA: Massachusetts Institute of Technology.

Comments

comments

Leave a Reply

Your email address will not be published. Required fields are marked *