Sign In
  • Question

    We are discussing the viability of dropping one hardware solution and switching to the other Service's solution as a cheaper alternative that can be fielded as soon or sooner than currently planned. Is there anything that guides one Service in adopting another Service's JROC approved capability document? If another Service's CDD or CPD is adopted, are we then tied to the same hardware solution? Are we required to run another open competition before selection?


    If your service/agency has a requirement for a material solution, you can not just simply adopt another service’s Capability Development Document. The CDD is a service or joint requirement document identifying the material solution for a very specific capability need. What your service can do, however is to coordinate thru your Service Acquisition Executive (SAE), that your organization believes the material solution identified in the CDD of the other service appears to meet the requirements of your own program (I take it your program does have an ICD?). There would have to be additional study and comparison. However, there is considerable guidance and direction on avoiding the acquisition of duplicative/redundant systems.

    Title 10 U.S. Code § 2377 directs departments/agencies to conduct market research in order to ascertain if there exists either commercial or non-developmental items that could fulfill the requirements of a stated need (see this link:

    Title 15 U.S. Code § 644 para (e)(2) (

    Both of these laws are cited in Enclosure 1, Table 2, of the DoDI 5000.02 as rationale, "…to reduce the duplication of existing technologies and products, and to understand potential materiel solutions, technology maturity, and potential sources…" Unfortunately, the CJCSI 3170.01-H (current JCIDS manual), does not mention specific procedures for reducing duplicative systems within the requirements generation process… however, it does say the following:

    Para 4.c: JCIDS uses Joint Capability Areas (JCAs) as an organizing construct for Functional Capability Boards (FCBs) and portfolio assessments, consistent with reference d. This provides the FCBs with portfolios of similar DOD capabilities functionally grouped to support capability analysis, strategy development, investment decisions, capability portfolio management, and capabilities-based force development and operational planning.

    At the highest level, for Major Defense Acquisition Programs (MDAPs), Congress has mandated in Title 10 U.S.C. 2366a (

    I recommend contacting the Joint Staff J-8 Requirements Management Division (J-8/RMD), to articulate your organization’s desire to join with the material solution of this "other" program. It is highly likely that while you might NOT have to adopt the other organization’s CDD, your program could very well identify their material solution (their particular system acquisition) as fulfilling your stated requirements. It’s also possible to either modify their existing development/production contracts, or to draft your own, in order to invest or procure in the same exact system (or to even modify it slightly to accommodate your own unique requirements). Just because you have identified their hardware as meeting your needs, does not mean your organization is adopting their CDD – just their material design. This meets the requirement for identifying "non-developmental" solutions.

    Besides contacting your SAE, and the J-8/RMD, I would highly recommend contacting the Program Manager for the system being developed/procured which you feel meets your needs, and investigating what his/her assessment is of your situation. They would probably welcome your organization’s investment dollars, as it would ultimately lower the per-unit cost of the hardware being acquired. This marks the starting point for avoiding duplication. provides the rationale within the context of market research for consolidating contracts. Chief rationale among those stated is substantial cost savings, reduction is cycle times, and "any other benefits"., for the Milestone Decision Authority (MDA), to actually certify that, "…(3) if the program duplicates a capability already provided by an existing system, the duplication provided by such program is necessary and appropriate…" Therefore, even though your program might not be an MDAP, there is still sufficient overarching direction to avoid acquiring a completely separate system which duplicates the capability of another system. So, it seems you have ample justification/supporting rationale for why your organization should pursue this "already-developed" technology.

    Open full Question Details
Bot Image