Middle Tier of Acquisition (MTA)

AAF  >  MTA  >  Rapid Prototyping Path  >  Prototype Development

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.

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). 

Additional Resources

• DoD Prototyping Handbook
• DAU Functional Gateway: Engineering
• DAU Community of Practice: Systems Engineering
• DAU Community of Practice: Program Management
• DAU Community of Practice: Modular Open Systems Architecture
• DAU Community of Practice: Information Technology/Software
• DAU Community of Practice: Risk, Issue, and Opportunity Management
• DAU Community of Practice: Test and Evaluation
• DAU Community of Practice: Data Management