Major Capability Acquisition (MCA)

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.

Source: DAG CH 3-3.2.3 Technology Maturation and Risk Reduction Phase

The primary objective of the Technology Maturation and Risk Reduction (TMRR) phase is to reduce technical risk and develop a sufficient understanding of the materiel solution to support sound investment decisions at the pre-Engineering and Manufacturing Development (EMD) Review and at Milestone B regarding whether to initiate a formal acquisition program. The Systems Engineer supports the production of a preliminary system design that achieves a suitable level of system maturity for low-risk entry into EMD. Usually the Systems Engineer implements a strategy of prototyping on a system element or subsystem level, balancing capability needs and design considerations to synthesize system requirements for a preliminary end-item design for the system. The prototyping objectives should focus on risk reduction and/or competition.

The major efforts associated with the TMRR phase are:

• Determining the appropriate set of technologies to integrate into a full system.
• Maturing the technologies, including demonstrating and assessing them in a relevant environment.
• Conducting prototyping of the system and/or system elements.
• Performing trade studies, refine requirements and revise designs.
• Developing the preliminary design, including functional and allocated baselines, specifications, interface control drawings/documents, architectures and system models.
• Performing developmental test activities as appropriate.

SE activities should be integrated with TMRR phase-specific test and evaluation and logistics and sustainment activities identified in CH 8–4.2. and CH 4–3.2., respectively.

During the TMRR phase, the program develops and demonstrates prototype designs to reduce technical risk, validate design approaches, validate cost estimates and refine requirements. In addition, the TMRR phase efforts ensure the level of expertise required to operate and maintain the product is consistent with the force structure. Technology development is an iterative process of maturing technologies and refining user performance parameters to accommodate those technologies that do not sufficiently mature (requirements trades). The Initial Capabilities Document, the Acquisition Strategy (AS), Systems Engineering Plan (SEP) and Capability Development Document (CDD) guide the efforts of this phase. The CDD enters the TMRR phase as a draft  and is validated during this phase to support preliminary design activities and the PDR.

There are two key technical objectives in the TMRR phase: technical risk reduction and initial system development activity, culminating in preliminary design. The Systems Engineer in the TMRR phase manages activities to evaluate prototyped solutions (competitive and risk reduction prototypes) against performance, cost and schedule constraints to balance the total system solution space. This information can then be used to inform the finalization of the system performance specification as a basis for functional analysis and preliminary design.

Effective systems engineering (SE), applied in accordance with the SEP and gated by technical reviews, reduces program risk, identifies potential management issues in a timely manner and supports key program decisions. The TMRR phase provides the Program Manager (PM) with a preliminary design and allocated baseline that are realistic and credible.

Source: DAG CH 3-3.2.3 Technology Maturation and Risk Reduction Phase

The program office team provides technical management and may employ industry, Government laboratories, the Service science and technology (S&T) community or Federally Funded Research and Development Centers (FFRDCs)/universities to accomplish specific risk-reduction or prototype tasks as described in the SEP.

In addition to the general responsibilities identified in CH 3–2.5. Engineering Resources, the PM focuses on the following TMRR activities, which rely on and support SE efforts:

• Awarding TMRR phase contract(s).
• Providing resources for technical reviews.
• Planning and executing the Technology Readiness Assessment (TRA) (MDAPS only).
• Influencing development of the CDD.
• Developing the Acquisition Strategy (AS).
• Developing the strategy and objectives for use of prototypes; considering both contracted efforts and government sources.
• Supporting the Development RFP Release Decision Point.
• Ensuring the Government preserves the rights needed to be consistent with the life-cycle acquisition and support strategy. During TMRR, proprietary development and design can often lead to issues with intellectual property and associated data rights (see CH 3–4.1.7. Technical Data Management Process).
• Supporting the Configuration Steering Board once the CDD has been validated. This board assumes responsibility to review all requirements changes and any significant technical configuration changes for ACAT I and IA programs in development, production and sustainment that have the potential to result in cost and schedule impacts to the program.

In addition to the general roles and responsibilities described in CH 3–2.5. Engineering Resources, during this phase it is the Systems Engineer’s responsibility to:

• Lead and manage the execution of the technical activities as documented in the SEP.
• Plan and execute technical reviews, including the System Requirements Review (SRR), System Functional Review (SFR), and Preliminary Design Review (PDR)
• Measure and track program maturity using technical performance measures, requirements stability and integrated schedules.
• Support award of TMRR phase contract(s), as necessary.
• Balance and integrate key design considerations.
• Maintain the Systems Engineering Plan (SEP), including generating the update in support of Milestone B.
• Lead the initial development of the system to include functional analysis, definition of the functional and allocated baselines and preliminary design (see CH 3–4.2.2. Requirements Analysis Process and CH 3–4.2.3. Architecture Design Process).
• Support configuration management of the baselines, since they are required in later technical reviews, audits and test activities (e.g., functional baseline at the Functional Configuration Audits (FCAs)).
• Conduct technical activities in support of the Development RFP Release Decision Point.
• Conduct a rigorous and persistent assessment of technical risk, determine risk mitigation plans and work with the PM to resource the mitigation plans.
• Support the Technology Readiness Assessment (TRA) including creation of the plan, the pre-EMD preliminary TRA and the TRA final report (MDAPs only).
• Support requirements management, and monitor for unnecessary requirements growth (e.g., derived versus implied requirements).
• Manage interfaces and dependencies.
• Maintain oversight of the system (software and hardware) development processes, system testing, documentation updates and tracking of the system development efforts.
• Support the PM in his interactions with the Configuration Steering Board.

Source: DAG CH 3-3.2.3 Technology Maturation and Risk Reduction Phase

Source: DAG CH 3-3.2.3 Technology Maturation and Risk Reduction Phase

The TMRR phase activities begin when a favorable Milestone A decision has been made (see CH 3–3.2.2. Materiel Solution Analysis Phase) and end with a successful Milestone B decision. 

The TMRR phase addresses a set of critical activities leading to the decision to establish a program of record. The SE activities are aimed at reducing technical risk and providing the technical foundation for this decision. Depending on the nature of the technology development strategy, the order and characteristics of these activities may change. During the TMRR phase, systems engineers follow comprehensive, iterative processes to accomplish the following:

• Perform Technology Maturation. The AS identifies technologies requiring further maturation before they can be implemented within a solution. Technology maturation involves design, development, integration and testing. There could be one or more risk areas related to hardware, software or information technology, and there may be multiple industry contracts/Government efforts for maturing the technology. The TEMP should stipulate the test and evaluation approach for assessing the results of the technology maturation activities (see CH 8–4.2.). The Systems Engineer participates in the technology readiness assessment (TRA). The TRA focuses only on technology maturity as opposed to engineering and integration risk. OSD TRA Guidance provides policy and guidance for TRAs.
• Perform Prototyping. Prototyping is an engineering technique employed for several reasons: to reduce risk, inform requirements and encourage competition. For example, the primary objective for competitive prototyping (CP) is acquiring more innovative solutions at better value by ensuring competition. CP are addressed in statute for MDAPs (see P.L. 114-92 (SEC. 822 para (c))). Other prototypes should be considered if they materially reduce engineering and manufacturing development risk at an acceptable cost. At this point in the life cycle, the CP strategy should focus on mitigating key technical risk areas. The program office should have a clear understanding of technical, engineering and integration risks at Milestone A. Current policy does not require full-up system prototypes; therefore, competitive prototyping may include prototyping critical technologies, system elements, integration of system elements or full-up prototypes. Because a primary objective of this type of prototyping is to support a follow-on award choice between developers, contract incentives should be aligned to CP strategy goals. These goals most often emphasize cost, schedule and performance realism and quantification. Contract goals should require the solutions demonstrated during CP be used in the subsequent PDR/CDR designs. The CP strategy should be identified in the SEP and AS, tasks specified in RFPs/Task Orders, technically managed by the program office and included in the TEMP with specific test objectives. Risk reduction prototypes can be at the system level or can focus on technologies, sub-components or components, and may or may not include objectives associated with competitive contracts. And in nearly all cases, prototypes can be extremely useful in assessing technical performance, supporting trade studies and updating requirements.
• Perform System Trade Analysis. The Systems Engineer assesses alternatives with respect to performance, cost, schedule and risk, and makes a recommendation to the PM. The SE assessment should consider the full range of relevant factors, for example, affordability goals and caps, technology maturity, development and deployment constraints, modular open system approaches and user-identified needs and shortfalls. System trades should be used to inform and shape the CDD and cost and schedule objectives to be documented in the Acquisition Program Baseline (APB).
• Develop System Architecture. See CH 3–4.2.3. Architecture Design Process for additional information.
• Develop Functional Baseline. See CH 3–4.1.6. Configuration Management Process for additional information.
• Develop Allocated Baseline. See CH 3–4.1.6. Configuration Management Process for additional information.
• Develop Preliminary Design(s). May involve competitive, preliminary design activities up to and including PDRs. See CH 3–3.3.4. Preliminary Design Review for additional information.
• Develop Allocated Technical Performance Measures (TPMs). The allocated baseline establishes the first physical representation of the system as system elements with system-level capabilities allocated to system element-level technical performance measures.
• Support CDD Validation. The purpose of this support is to inform the MDA and requirements validation authority about the technical feasibility, affordability and testability of the proposed requirements. CDD (or an equivalent requirements document) forms a basis for the set of requirements used for design activities, development and production. Specific SE attention is given to trade-off analysis, showing how cost varies as a function of system requirements (including Key Performance Parameters), major design parameters and schedule. The results should identify major affordability drivers.
• Support Development RFP Release Decision Point. The purpose of the MDA-level review is to assess the AS, RFP and key related planning documents and determine whether program plans are affordable and executable and reflect sound business arrangements. Specific SE attention is given to engineering trades and their relationship to program requirements and risk management. Typically, this event occurs after PDR to allow for feedback from the PDR into the technical aspects of the RFP. The Development RFP Release event can come before the PDR if there is confidence the RFP will not need to be substantially changed.
• Finalize Documents. The Systems Engineer updates the SEP and PPP and provides inputs for updating the LCSP, TEMP and other program documents.

The Systems Engineer uses technical reviews and audits to assess whether preplanned technical maturity points are reached during the acquisition life cycle as the system and system elements mature. A key method for doing this is to identify technical risks associated with achieving entrance criteria at each of these points (See the DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs.) Technical reviews typically conducted in the TMRR phase are:

• System Requirements Review (SRR) (see CH 3–3.3.2. System Requirements Review)
• System Functional Review (SFR) (see CH 3–3.3.3. System Functional Review)
• Software Specification Review (SSR) for programs with significant software development; a SSR is typically performed before, and in support of, a PDR. The SSR technical assessment establishes the software requirements baseline for the system elements under review (e.g., computer software configuration items (CSCI)) to ensure their preliminary design and, ultimately, the software solution has a reasonable expectation of being operationally effective and suitable.
• Preliminary Design Review (PDR) mandated (unless formally waived) to confirm the development of the allocated baseline (see CH 3–3.3.4. Preliminary Design Review)

Test activities during the TMRR phase that depend on SE support and involvement include developmental test and evaluation of system and/or system element prototypes and Early Operational Assessments (EOAs). Developmental Test and Evaluation (DT&E) activities, for example, should be closely coordinated between the engineering and test communities, since DT&E activities support:

• Technical risk identification, risk assessment and risk mitigation
• Providing empirical data to validate models and simulations and
• Assessing technical performance and system maturity (see CH 8–4.2.)

Reference Source: DAG CH 8-4.2 Technology Maturation & Risk Reduction Phase

The Acquisition Strategy and the Milestone A TEMP guide this acquisition phase. The Chief Developmental Tester, in collaboration with the T&E WIPT, monitors the execution of the T&E events and reviews T&E reports, . Multiple technology development demonstrations/ evaluations, defined in the Acquisition Strategy (AS) and the TEMP, may prove necessary before the user and developer can substantiate a preferred solution is feasible, affordable, and supportable; satisfies validated capability requirements; and has acceptable technical risk. Programs identify critical program information during this phase as well as implement program protection measures to prevent disclosure of critical information.

Contractor DT&E. During early DT&E, the contractor approach includes tests and evaluations for optimizing designs and functionalities. The contractor may also use modeling and simulation, laboratory, test bench, and system mock-ups or prototypes to gain knowledge of integrated system performance. Government T&E organizations may observe the critical contractor testing, conduct additional T&E, and, when practical, facilitate early user involvement. The government may be able to utilize contractor data to enhance or replace planned government testing, and to enable T&E efficiencies to be realized if testing is observed by a government T&E organization. The TMRR contract with industry should support open communication between government and contractor test organizations.

Government DT&E. During early DT&E, the Chief Developmental Tester uses government testing to evaluate competitive prototypes, competing technologies, technology maturity of critical technology elements, etc. The Lead DT&E Organization conducts developmental testing and evaluation activities for the program, as directed by the Chief Developmental Tester. The Lead DT&E Organization also ensures the AoA assumptions and findings are validated.

Early Operational Assessments. Early Operational Assessments (EOAs) provide a means to evaluate a program’s progress early in the process towards developing an operationally effective, suitable, and survivable system. EOAs are typically an analysis, based on a review of current program plans and documentation, as well as data from early developmental testing, technology assessments, modeling and simulation, and program reviews. EOAs enable the OTA to provide early input on key issues that, if not corrected, could have a detrimental effect to the determination of operational effectiveness, operational suitability, and survivability (including cybersecurity) or lethality. EOAs provide a means to examine the links and consistency between the concept of operations, requirements, and technology limitations to provide recommendations to the program and the requirements authority.

EOA reports are provided to support one or more of the design phase life-cycle events (namely, the CDD Validation Decision, the Development RFP Release Decision, or Milestone B). For programs entering development at Milestone B, the lead OTA (as appropriate) prepares and reports EOA results after program initiation and prior to the Critical Design Review (CDR).

T&E Support during Technology Maturation & Risk Reduction

The TMRR phase includes activities intended to reduce the specific risks associated with the functions, technologies, environments, and developed products. This includes additional design trades and requirements necessary to ensure an affordable product and an executable development, production, and sustainment program.

Logistics Risk Assessment. During the TMRR phase, programs conduct a logistics risk assessment as part of life-cycle considerations. The PM finalizes sustainment requirements for approval at the CDD Validation Decision, and decomposes sustainment requirements into more detailed requirements to support the Preliminary Design Review (PDR) and for use during the logistics risk assessment. The T&E WIPT leverages the logistics risk assessment during development of the Milestone B TEMP. Refer to the DAG, CH 4, Life Cycle Logistics for more information.

Technology Readiness Assessment (TRA). The TRA is a systemic, metric-based process that establishes the maturity of critical technologies. The TRA may be conducted concurrently with other technical reviews. The Chief Developmental Tester assists the chief engineer/lead systems engineer when assessing the technological maturity and integration risk of critical technologies. Refer to the DAG, CH 3.4.1.3., Technical Assessment Process, for more information.

Preliminary Design Review (PDR). Conducted after preliminary design efforts, but before the start of detail design, the PDR provides the first opportunity for the DoD to closely observe the contractor’s hardware and software design. The contractor describes all design changes made with respect to trade studies, design considerations, and design decisions that provide a rationale for the system’s preliminary design. The contractor also provides a hardware or hands-on demonstration of some of the preliminary designs to better illustrate important aspects. The Chief Developmental Tester provides developmental test data collected to date to support the PDR. Test organizations attend technical reviews to provide current assessments, keep abreast of program progress, and provide insight into design direction. Unless waived by the MDA, the Preliminary Design Review occurs prior to Milestone B. Refer to the Preliminary Design Review, for more information.

Capability Development Document (CDD) Validation. The Technology Maturation and Risk Reduction (TMRR) Phase requires continuous and close collaboration between the program office and the requirements validation authority During this phase, the Requirements Authority for the program validates the final CDD in order to provide a basis for preliminary design activities and the Preliminary Design Review, which normally occurs prior to Milestone B unless waived by the MDA. Prior to validation, the program coordinates the Capability Development Document (or other draft requirements document) with the MDA to ensure requirements remain technically achievable and affordable. The T&E WIPT reviews the draft CDD and coordinates the input with the PM. This effort provides the T&E WIPT a key opportunity to review requirements, to determine if they are clear, testable, measurable, and technically achievable.