U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Acquisition of Services (AoS)
Title 10 Changes Summary Table
Software Acquisition Pathway (SWP)
Defense Business Systems (DBS)
Software Acquisition Pathway (SWP)

Middle Tier of Acquisition (MTA)

Breadcrumb

  1. Home
  2. About AAFDID
  3. Middle Tier of Acquisition (MTA)

DoDI 5000.80 Overview. The DoDI 5000.80 Middle Tier of Acquisition (MTA) Pathway is authorized pursuant to FY16 NDAA Section 804 which establishes the MTA authority and to 10 USC 4201 that directs MTA programs are not to be treated as MDAPs. The pathway is intended to balance speed with rigor.

The term "Major Defense Acquisition Program" (MDAP) does not include an acquisition program or project that is carried out using the rapid fielding or rapid prototyping acquisition pathway under section 804 of the National Defense Authorization Act for Fiscal Year 2016 (Public Law 114-92).

However, for purposes of compliance with 10 U.S.C., Sections 4323 and 4324, the term "covered system" DOES include an MTA program or project that is carried out using either the rapid fielding or rapid prototyping acquisition pathway under section 804 and requires an eventual total expenditure that would otherwise make it an MDAP, if not covered by section 804.

The MTA Pathway values efforts to rapidly develop field-able prototypes that demonstrate new capabilities, and/or rapidly field production quantities of systems with proven technologies that require minimal development. Documentation is not developed merely for compliance purposes or to pass the next milestone (as there are no milestones in MTA), but rather to proceed with speed and rigor.

DoDI 5000.80 Statutory Requirements. The MTA Pathway intent is to assist in the creative thinking and expand the potential recommendations that can be put forward to the Decision Authority. In turn, the desired approach is predicated on the concept that documentation requirements are reduced and the program focuses efforts on rapidly developing and fielding capabilities. It is recognized that there are some statutory and regulatory information requirements that must be met depending on the characteristics of the respective program, such as Clinger-Cohen Act compliance for programs with an IT component or Frequency Approvals for RF-emitting systems.  However, the Department takes the view that most statutory requirements are simply information requirements that can be included in the Acquisition Strategy, or combined into other documents, and do not need to be stand-alone documents.

Under certain scenarios, some statutory information may be required; e.g.:

  • Bandwidth Requirements Review
  • Clinger-Cohen Act Compliance
  • Core Logistics Determination/ Core Logistics and Sustaining Workloads Estimate
  • DOT&E Report on Initial Operational Test and Evaluation (IOT&E)
  • Frequency Allocation Application (DD Form 1494)
  • Live-Fire Test and Evaluation (LFT&E) Report
  • PESHE and NEPA/E.O. 12114 Compliance Schedule
  • Post Implementation Review (PIR)
  • Product Support Strategy (PSS)

Other potential scenarios involving IT components; joint, multinational, and/or interagency interoperability requirements; and programs on the DOT&E oversight list offer a layer of complexity that will require review and legal opinion by the program and Service-level OGC.

DoDI 5000.80 Regulatory Requirements. Regulatory documents should only be developed if deemed essential to program execution.  Some document content should be combined.  Most regulatory information requirements can be addressed in the Acquisition Strategy. Decision Authorities ultimately have the discretion on what regulatory information is required and the appropriate mechanism for documentation.

The following two tables provide additional details about MTA information requirements.   The first table lists Submission Deliverables and Timelines that must be submitted via DAVE interfaces to OSD.  The rows list information requirements for MTA programs, and the 'x' indicates when OSD requires submission of each. Programs are highly encouraged to review Component-specific MTA information requirements and submission timelines.  The second table lists the MTA Statutory/Regulatory requirements THAT MAY BE APPLICABLE.  Program Managers are required to comply with statutory requirements unless waived in accordance with relevant provisions.