4.2.4. Technology Development Phase

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.2.4. Technology Development Phase

4.2.4. Technology Development Phase

The primary objective of the Technology Development (TD) 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 (see Figure 4.2.4.F1.). Usually the Systems Engineer implements a strategy of competitive 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 major efforts associated with the TD phase are:

• Determine the appropriate set of technologies to integrate into a full system
• Mature the technologies including demonstrating and assessing them in a relevant environment
• Conduct competitive prototyping of the system and/or system elements
• Perform trade studies, refine requirements, and revise designs
• Develop the preliminary design, including functional and allocated baselines, specifications, interface control drawings/documents, architectures, and system models
• Perform developmental test, as appropriate

Figure 4.2.4.F1. Systems Engineering Activities in the Technology Development Phase

SE activities should be integrated with TD phase-specific test and evaluation and logistics and sustainment activities identified in DAG Chapter 9 Test and Evaluation and Chapter 5 Life-Cycle Logistics, respectively.

During the TD phase, the program develops and demonstrates prototype designs to reduce technical risk, validate design approaches, validate cost estimates, and refine requirements. In, addition, the TD 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 Technology Development Strategy (TDS), Systems Engineering Plan (SEP), and draft Capability Development Document (CDD) guide the efforts of this phase.

There are two key technical objectives in the TD phase: technical risk reduction and initial system development activity, culminating in preliminary design. The Systems Engineer in the TD phase manages activities to evaluate prototyped solutions (preferably competitive 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 TD phase provides the Program Manager with a preliminary design and allocated baseline that are realistic and credible.

Roles and Responsibilities

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 DAG section 4.1.4. Engineering Resources, the Program Manager focuses on the following TD activities, which rely on and support SE efforts:

• Award TD phase contract(s)
• Provide resources for technical reviews
• Plan and execute the Technology Readiness Assessment (TRA)
• Influence development of the CDD
• Develop the Acquisition Strategy (AS)
• Support pre-EMD review
• Ensure the Government preserves the rights they need consistent with the life-cycle acquisition and support strategy; during TD, proprietary development and design can often lead to issues with data rights (see DAG section 4.3.8. Technical Data Management Process)

In addition to the general roles and responsibilities described in DAG section 4.1.4. 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 TD 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 initial development of the system to include functional analysis, definition of the functional and allocated baselines, and preliminary design (see DAG sections 4.3.11. Requirements Analysis Process and 4.3.12. 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 pre-EMD review
• Conduct a rigorous and persistent assessment of technical risk, determine risk mitigation plans, and work with the Program Manager 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
• Support requirements management and monitor for unnecessary requirements growth (e.g., derived versus implied requirements)
• Manage interfaces and dependencies

Inputs

Table 4.2.4.T1 summarizes the primary inputs associated with this pre-systems acquisition part of the life cycle (see DoDI 5000.02).

Table 4.2.4.T1. Inputs Associated with TD Phase

Activities

The TD phase activities begin when a favorable Milestone A decision has been made (see DAG section 4.2.3. Materiel Solution Analysis Phase) and end with a successful Milestone B decision. Figure 4.2.4.F2 provides the end-to-end perspective and the integration of SE technical reviews and audits across the acquisition life cycle.

Figure 4.2.4.F2. Weapon System Development Life Cycle

The TD phase addresses a set of critical activities leading to the decision to establish a program of record. The SE activities provide 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 TD phase, systems engineers follow comprehensive, iterative processes to accomplish the following:

• Perform Competitive Prototyping. As mentioned earlier, prototyping is an engineering technique employed for several reasons. Competitive prototyping (CP) has as a primary objective to acquire more innovative solutions at better value by ensuring competition. 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. 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 TDS, tasks specified in RFPs/Task Orders, technically managed by the program office, and included in the TES with specific test objectives.
• Perform Technology Maturation. The TDS 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 TES should stipulate the test and evaluation approach for assessing the results of the technology maturation activities (see DAG Chapter 9 Test and Evaluation; Chief Developmental Tester). The Systems Engineer participates in the technology readiness assessment (TRA). The TRA focuses only on technology maturity as opposed to engineering and integration risk. DoDI 5000.02 and OSD TRA Guidance provide policy and guidance for TRAs.
• Perform System Trade Analysis. The Systems Engineer assesses alternatives with respect to performance, cost, schedule and risk, and makes a recommendation to the Program Manager. The SE assessment should consider the full range of relevant factors, for example affordability targets, technology maturity, development and fielding constraints, 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 DAG section 4.3.12. Architecture Design Process for additional information.
• Develop Functional Baseline. See DAG section 4.3.7. Configuration Management Process for additional information.
• Develop Allocated Baseline. See DAG section 4.3.7. Configuration Management Process for additional information.
• Develop Preliminary Design. See DAG section 4.2.12. Preliminary Design Review for additional information.
• Develop Allocated Technical Performance Measures (TPMs). The allocated baseline establishes the first physical representation of the system as subsystem elements with system-level capabilities allocated to subsystem-level technical performance measures.
• Complete PDR Report. After the PDR, the Program Manager develops the PDR Report with support from the Systems Engineer. The Program Manager provides the report to the MDA to support a Milestone B decision. The report includes recommended requirements trades based upon an assessment of cost, schedule, performance, and risk.
• Support pre-EMD review. 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.
• Finalize Documents. The Systems Engineer updates the SEP and PPP and provides inputs for updating the LCSP, TEMP, and other program documents.

Technical reviews typically conducted in the TD phase are:

• System Requirements Review (SRR) (see DAG section 4.2.10. System Requirements Review)
• System Functional Review (SFR) (see DAG section 4.2.11. 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 DAG section 4.2.12. Preliminary Design Review)

Test activities during the TD 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 DAG Chapter 9 Test and Evaluation).

Outputs and Products

The technical outputs identified in Table 4.2.4.T2 are some of the inputs necessary to support SE activities in the EMD phase. The outputs should support the technical recommendation at Milestone B that an affordable solution has been found for the identified need with acceptable risk, scope, and complexity. Technical outputs associated with technical reviews in this phase are addressed later in this chapter.

Table 4.2.4.T2. Technical Outputs Associated with TD Phase

Top of page