Middle Tier of Acquisition (MTA)

AAF  >  MTA Rapid Prototyping Path  >  Prototype Development

Prototype Development

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.



Prototype: A model built to evaluate and inform its feasibility or usefulness.  Non-physical models are acceptable if the non-physical model is the residual operational capability to be fielded.

DoDI 5000.80

Reference Source: DODI 5000.80, Paragraph 3.1.b


Demonstrating and Evaluating Performance. DoD Components will develop a process for demonstrating performance and evaluating for current operational purposes the proposed products and technologies. This process will result in a test strategy or an assessment of test results, included in the acquisition strategy, documenting the evaluation of the demonstrated operational performance, to include validation of required cybersecurity and interoperability as applicable. The operational demonstration assessment will support the initial production decision by the DA. Programs on the DOT&E oversight list will follow applicable procedures.

This is where the MTA team contracts with industry, and/or works with government organizations to design, develop, and test prototypes per the Acquisition Strategy approved by the Decision Authority. 

Prototypes can be one of many possible alternatives:

  • One vendor develops a single prototype
  • One vendor iteratively develops multiple prototypes
  • Multiple vendors each develop a single prototype
  • Multiple vendors develop multiple prototypes

Prototyping will be conducted at the system, subsystem, or component level; and competitive, where appropriate.

Reference Source: Guidance from R&E (Systems Engineering), 2019

Systems engineering (SE) is a methodical and disciplined approach for the specification, design, development, realization, technical management, operations and retirement of a system. SE applies critical thinking to the acquisition of a capability. It is a holistic, integrative discipline, whereby the contributions across engineering disciplines, such as structural engineers, electrical engineers, mechanical designers, software engineers, human factors engineers and reliability engineers, are evaluated and balanced to produce a coherent capability — the system. SE activities begin before a program is officially established and are applied throughout the acquisition life cycle. Any effective SE approach should support and be integrated with sound program management. Prior to program initiation, the Program Manager (PM), or Service lead if no PM has been assigned, should perform development planning to lay the technical foundation for successful acquisition. A system should not be acquired in isolation from other systems with which it associates in the operational environment. The Program Manager and Systems Engineer should understand how their system fills the needs for which it was designed and the enterprise context within which it operates.

The Systems Engineer contributes to defining, establishing and achieving affordability goals and caps throughout the life cycle of the system. Throughout the acquisition life cycle, the PM and Systems Engineer should monitor the system affordability, seek out cost saving opportunities and identify any associated cost, schedule and performance risks. The PM and Systems Engineer use the should-cost estimate as a tool to:

  • Influence design trades and choices when analyzing and setting contract/production execution targets
  • Manage all costs throughout the product’s life cycle
  • Manage the product’s final unit and sustainment cost
  • Provide incentives for both of the parties (Government and industry) to execute efficiently

The practice of SE is composed of 16 processes: eight technical processes and eight technical management processes as shown in the Figure below. The purpose of the SE processes is to provide a framework that allows the program to structure and conduct its technical efforts to efficiently and effectively deliver a capability to satisfy a validated operational need. To fulfill that purpose, a program implements the SE technical processes in an integrated and overlapping manner to support the iterative maturation of the system solution.

Image of Systems Engineering Technical Processes, Technical Management Processes, and SE activities.

All organizations performing SE should scale their application and use of the SE processes to reflect the unique needs of the program and the type of product or system being developed. This scaling should reflect the system’s maturity and complexity, size and scope, life-cycle phase and other relevant considerations. For example, lower-risk, less-complex programs may scale the processes to ensure key activities are effective but not overly cumbersome (e.g., simpler and less-expensive tools, less-frequent reporting and activities adjusted to fit smaller organizations with fewer personnel).

Check out the MTA FAQs and MTA Tips for potentially related questions from the field and helpful tips!

DoD Component Guidance

Note that DoD Component MTA Implementation policies and guidance are currently being updated to be consistent with the newly published DODI 5000.80 (effective 30 Dec 2019). 

Air Force

Systems Engineering

Reference Source: Air Force Guidance Memorandum for Rapid Acquisition Activities, 27 June 2019


6.3. Digital engineering, modular open system architecture, software-defined capabilities, and commercial standards and interfaces are strongly encouraged and should be thoroughly assessed for all rapid acquisitions. Inclusions should be documented in the acquisition strategy.


6.4. Agile software development and development operations (DevOps) is required for all new initiatives unless waived by the MDA for reasons of prohibitive cost, schedule, or performance or other national security considerations. The software development strategy should be documented as part of the ASD.


Reference Source: ASA(ALT) Middle Tier of Acquisition Policy, 20 March 2020, Enclosure 2
[Note: CAC required for access]


Program Executive Officer (PEO)/ Program Manager (PM) will use merit-based processes for the consideration of innovative technologies or existing products to meet user needs. PMs will implement the program acquisition strategy.


Rapid Prototyping


a. The prototyping effort should begin with the most difficult requirements first. This allows for early confirmation that the prototype project is achievable, directs the effort toward a different technology, or informs program termination. Prototyping should have well defined outputs that can be assessed with Soldier Touch Points and/or experimentation. This will be used to inform, in as quantifiable manner as possible, a recommendation made by the PM, with cross-functional team input where applicable. The recommendation should inform the DA, who then decides to proceed, adjust or terminate the prototyping effort.


b. PMs should demonstrate and evaluate the performance of fieldable prototypes developed pursuant to the effort in an operational environment. PMs should also develop specific plans to transition successful prototypes to new or existing acquisition programs for production and fielding under the rapid fielding pathway or the Defense Acquisition System.



Additional Resources