4.1.6. Systems Engineering Role in Contracting

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.1.6. Systems Engineering Role in Contracting

4.1.6. Systems Engineering Role in Contracting

The Systems Engineer should actively participate in developing program contract tasks to ensure that the appropriate technical activities are contained and properly scoped in the final contract. Proper scoping of the technical tasks in the Statement of Work (SOW), Statement of Objectives (SOO), or Performance Work Statement (PWS) is necessary to ensure that the final system meets end users’ needs. Often contracting activities may appear to be primarily programmatic in nature (e.g., acquisition strategy development, writing requests for proposal, performing market research, developing the Contract Data Requirements List (CDRL)) but, in fact, they reflect technical planning and should be influenced by the desired technical content. For example, technical understanding of data rights can be a key element in planning for modularity and open systems design, or the decision to choose an incremental acquisition strategy depends on generic functionality groupings that may not be appropriate for every system.

The Systems Engineer should contribute to the development of contract incentives and/or incentive approaches that promote an understanding of the technical risks inherent in the selected development approach. Incentives such as award fee may be tied to program performance and progress that may be evaluated during technical reviews, or more frequently the incentive is tied to the completion of a technical review. If that is the case, the developer may have a strong incentive to call the review complete as soon as possible. The Systems Engineer and Program Manager exercise best judgment in an objective and informed manner to ensure the reviews are not prematurely declared completed in order for the developer to qualify for the contract incentive. Another area to which incentives are tied is the Earned Value Management System (EVMS). The Program Manager should ensure that the EVMS tied to any incentive measures the quality and technical maturity of technical work products instead of just the quantity of work. If contracts include earned value (EV) incentives, the criteria should be stated clearly and should be based on technical performance. EV incentives should be linked quantitatively with:

• Technical performance measurement (TPM)
• Progress against requirements
• Development maturity
• Exit criteria of life-cycle phases
• Significant work packages and work products

Additional information about EVMS can be found in DAG Chapter 11 Program Management Activities. The Program Manager should make it a priority to engage with industry to clarify Government expectations and ensure a common understanding of the capability desired, need dates, risks, complexity, and scope. Access to current market information is critical for the program office as it defines requirements for acquisition programs. It is equally important for the contracting officers as they develop acquisition strategies, seek opportunities for small businesses, and negotiate contract terms. The best source of this information is usually found within industry partners. OMB memo, “Myth-Busting: Addressing Misconceptions to Improve Communication with Industry during the Acquisition Process” addresses productive interactions between federal agencies and industry partners. These interactions are strongly encouraged to ensure that the Government clearly understands the marketplace and can award a contract or order for an effective solution at a reasonable price. Early, frequent engagement with industry is especially important for complex, high-risk procurements, including (but not limited to) those for large information technology (IT) projects. Program Managers should develop ways to remove unnecessary barriers to reasonable communication and develop vendor communications plans, consistent with existing law and regulation, which promote responsible exchanges.

The program office uses a Request for Information (RFI) to communicate expectations and plans, including the expected business rhythm for contract execution. This communication ensures the offerors have an opportunity to provide a tight linkage across the Integrated Master Plan (IMP), Work Breakdown Structure (WBS), Integrated Master Schedule (IMS), risk management, and cost in their proposals. Early industry engagement opportunities include pre-solicitation notices, industry days, and other market research venues.

Before releasing the RFP, the program office needs to allow enough time to develop and mature the performance and functional specifications that need to be included in the RFP. The RFP and supporting technical documentation clearly define the Government’s expectations in terms of the performance and functional specifications, program planning, program process, risks, and assumptions. The RFP also should direct potential offerors to integrate their approach to reflect the Government’s expectations.

It is the responsibility of the Systems Engineer to ensure that technical documents accurately and clearly communicate the Government’s requirements including mandatory design, build, test, certification, approval, and acceptance criteria. This ensures the developer is made aware of all required processes and objective quality evidence (OQE) to be produced, to include processes leading to certification, approval, and acceptance using predetermined OQE. In addition, the Program Manager should consider providing all offerors with the IMP and top-level schedule (with internal and external dependencies), expected business rhythm, current risk assessments, and the Systems Engineering Plan (SEP) as part of the RFP.

Although there are many opportunities for contract-related interactions between the Government and potential offerors prior to contract award, the RFP remains the primary tool for shaping the contract, the program, and ultimately the system. See the “Guide for Integrating Systems Engineering into DoD Acquisition Contracts, Version 1.0, 2006” for additional guidance on the content and format of RFPs.

Within the RFP development team, the Systems Engineer should be responsible for the technical aspects of the RFP and should perform the following actions:

• Reference current required operational documentation and system performance specifications
• Identify SE process requirements (for example, requirements management, configuration management, and risk management; see DAG section 4.3. Systems Engineering Processes)
• Identify any design considerations including production; reliability and maintainability(R&M); environment, safety, and occupational health (ESOH); human systems integration (HSI); and security
• Identify for delivery Government-required technical data rights produced by the developer
• List and describe technical assessment evidence and events, including technical reviews, audits, and certifications and associated entrance/exit criteria
• Specify data protection, SoS, and system testing and verification requirements
• Coordinate with Chief Developmental Tester in regard to the test and evaluation requirements
• Provide a requirements verification traceability database (requirements and test method)
• Specify meetings and technical documentation between the program office and the developer
• Conduct a review of the deliverables (what data, level of detail, data rights, and when needed) and buy only what is needed in concert with should cost goals
• Lead or support the technical evaluation during source selection, to include providing inputs to the development of source selection criteria
• Perform schedule risk assessments as part of the source selection evaluation process
• Support the Independent Management Review (Peer Review) of the RFP before release
• Identify external or SoS interfaces and ensure the technical interface requirement and task scope are unambiguous to the offerors

Table 4.1.6.T1 contains the typical technical contents of the RFP and the associated Systems Engineer’s responsibilities, and should not be considered an exhaustive or mandatory list.

Table 4.1.6.T1. Typical Technical Contents of a Request for Proposal (RFP)

Top of page