Here is the excellent Christopher Monsey in the Exceptional Release, Intellectual Property (IP) Strategies in Major System Acquisitions: What are We Missing? He asks the crucial question:
Bundling – the great evil of contracting. Programs often bundle easier-to-get-to-yes data orders with hard-to-impossible-to-get-to-yes data orders. Why do programs bundle incompatible deliverables together and thus trash their ability to get their needs met? Acquisition convenience. Contracting officers often bundle deliverables to make it easier for source selections and contract administration. Thus, conventional contracting thinking can create major data acquisition failures.
There’s certainly truth to that. Here’s what this bundling situation leads to:
Such unreasonable government data orders include the “Big Ask” where the government orders all data regardless of who paid for development. The “Big Ask” threatens contractor revenue models where they have invested in some of the parts and forcing them to enable full and open competition damages their ability to get RoI. Many contractors have good and bad relationships with their suppliers. It is easier for them to get data from suppliers they have good relationships with vs. ones they have bad relationships with. OEMs have data for parts that an OEM developed in house; thus, it is easier for them to say “yes” to a data order versus data orders for parts that a supplier developed. Asking for too much data all at once exceeds the capacity of the OEM to generate data; thus, they necessarily must respond with a “no bid”.
Government thus drives vendors away not because vendors are bad people but because the incentives from government processes and regulation pushes acquisition officials to “big bang” contracting efforts with one-size-fits-all answers. If just one component of subsystem was developed fully at private expense by the OEM or one of their suppliers, then the whole thing can fall apart unless there is tailoring of the contract to the system’s inherent modularity. In other words, the government acts as if it is the investor to the entire weapon system, where in reality it is a partial investor, partial buyer of commodity goods, and partial regulator, depending on what you’re talking about.
Here’s what Monsey recommends:
…. A part/software object map tied to SDF [sources of development funding] status can provide a visual LSCP [life cycle sustainment plan] that implies one of four different LCSPs associated with investor, buyer, no investment/mere engineering, and mass market commercial item status. For example, different SDF status identifiers comprise developed exclusively at government expense (green), developed substantially at government expense (yellow), developed substantially at contractor expense (orange), developed exclusively at private expense (red), no significant development expense/design produced from “mere engineering” using data available to the public without limitation (e.g. what patent law calls “the prior art” and obvious variations of the prior art), Small Business Innovation Research (SBIR) parts (blue), OEM asserted Independent Research And Development (IRAD) parts (striped red), developed on a previous program and modified on the current program (striped green), and mass market commercial items (pink).
This corresponds I think quite well to the recommendations we at Mason GovCon made in Acquisition NEXT about Mastering the Baseline. If a major weapon system is broken down into logical component/subsystems and contracted separately, the government can align its contracting strategy with its IP strategy, sustainment plan, etc. Not only does this help the mapping to sources of development funding, it allows the program to move along at the fastest possible rate. Changing software or electronics, for example, can be decoupled from the slower-evolving platform or infrastructure elements.
This is awesome … more of this, please, in execution as a coordinated Gov team.