Back to Top

Educating the Aerospace Industry

Blog Archives

Contracts & Legal

Contracting Officer Representative (COR)

 

A Contracting Officer’s Representative (COR) is an individual authorized in writing by the contracting officer to perform specific technical or administrative contract functions. The COR must receive a written designation of their authority to act on behalf of the contracting officer. (DFARS Subsection 201.602-2)

 

The COR is not authorized to make any commitments or changes that will affect price, quality, quantity, delivery, or any other term or condition of the contract.

 

Handbook: DoD Contracting Officer Representative (COR) Handbook – 22 March 12

 

Contracting Officers may designate qualified personnel as their authorized representatives to assist in the technical monitoring or administration of a contract. A COR: [1]

  1. Must be a Government employee, unless otherwise authorized in agency regulations.
  2. Must be qualified by training and experience commensurate with the responsibilities to be delegated in accordance with department/agency guidelines.
  3. May not be delegated responsibility to perform functions at a contractor’s location that have been delegated under FAR 42.202(a) to a contract administration office.
  4. May not be delegated authority to make any commitments or changes that affect price, quality, quantity, delivery, or other terms and conditions of the contract.
  5. Must be designated in writing, and a copy furnished the contractor and the contract administration office:
    • Specifying the extent of the COR’s authority to act on behalf of the contracting officer;
    • Identifying the limitations on the COR’s authority;
    • Specifying the period covered by the designation;
    • Stating the authority is not redelegate; and
    • Stating that the COR may be personally liable for unauthorized acts.
  6. Must maintain a file for each contract assigned. This file must include, as a minimum:
    •  A copy of the contracting officer’s letter of designation and other documentation describing the COR’s duties and responsibilities; and
    • Documentation of actions taken in accordance with the delegation of authority.

 

Contract Office Representative Tracking Tool (CORT)

CORT Tool is a web management capability for the appointment of CORs. This Tool allows a perspective COR, COR Supervisor, and Contracting Officer to electronically process the nomination of CORs for one or multiple contracts. It provides built-in workflows for the nomination process to include email alerts/status reminders for monthly status report due-ins and delinquencies. The CORT Tool provides contracting personnel and requiring activities the means to track and manage COR assignment across multiple contracts across DoD.

 

AcqLinks and References:

Updated: 7/29/2019

Acquisition Process

Materiel Development Decision (MDD)

 

A Materiel Development Decision (MDD) is a point in time where the Joint Capabilities Integration and Development System (JCIDS) analysis has identified a capability gap/need and an MDD Review has determined a materiel solution is needed. The MDD is the formal point that initiates the Materiel Solutions Analysis (MSA) Phase.

Acquisition System

 

After a program has an approved MDD, the Analysis of Alternatives (AoA) process is expected to contribute to the selection of a preferred materiel solution that satisfies the capability gap/need documented in the approved Initial Capabilities Document (ICD). In an Evolutionary Acquisition program, the initial increment will be preceded by a MDD but follow-on increments will start at a predetermined Milestone.

 

There is no information required by Statute for an MDD for an Acquisition Program.

 

AcqLinks and References:

Updated: 6/18/2018

Program Management

Integrated Product Team (IPT)

 

An Integrated Product Team (IPT) is a team composed of representatives from appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision making. IPTs are used in complex development programs/projects for review and decision-making. The emphasis of the IPT is on the involvement of all Stakeholders (users, customers, management, developers, contractors) in a collaborative forum. [2]

 

There are three (3) types of IPTs that each acquisition program will implement: [2,3]

  • Overarching IPTs (OIPTs): Focus on strategic guidance, program assessment, and issue resolution;
  • Working-level IPTs (WIPTs): Identify and resolve program issues, determine program status, and seek opportunities for acquisition reform; and
  • Program-level IPTs (PIPTs): Focus on program execution and may include representatives from both government and industry after contract award.

Integrated Product and Process Development (IPPD) is the DoD management technique that simultaneously integrates all essential acquisition activities through the use of IPT to optimize design, manufacturing, and supportability processes.

 

Logistics: The Program Manager (PM) and/or Product Support Manager (PSM) should establish multidisciplinary teams to develop and manage the implementation of the performance-based support strategy. The IPTs should consider all factors and criteria necessary to achieve an optimum support strategy using the best capabilities of the public and private sectors in a cost-effective manner. DoD Component and Defense Logistics Agency (DLA) logistics activities should participate in support strategy development and IPTs to ensure the support concept is integrated with other logistics support and combat support functions and provide agile and robust combat capability. These participants can help to ensure effective integration of system-oriented approaches with commodity-oriented approaches (common support approaches), optimize support to users, and maximize total logistics system value. [1]

 

AcqTips:

  • In 1995, the Secretary of Defense directed that the Department adopt IPTs as the preferred approach for development, review, and oversight of the acquisition process.

AcqLinks and References:

Updated: 5/31/2018

Test & Evaluation

Development Test & Evaluation (DT&E)

 

Developmental Test & Evaluation (DT&E) is conducted throughout the acquisition process to assist in engineering design and development and to verify that technical performance specifications have been met. DT&E is planned and monitored by the developing agency and is normally conducted by the contractor. It includes the T&E of components, subsystems, Preplanned Product Improvement (P3I) changes, hardware/software integration, and production qualification testing. It encompasses the use of models, simulations, testbeds, and prototypes or full-scale engineering development models of the system.

 

Guide: DAU Test and Evaluation Management Guide – Chapter 7

Guide: DoD Test and Evaluation Management Guide – Chapter 6

 

The (3) three specific types of DT&E are: [1]

  1. Production Acceptance Test & Evaluation (PAT&E)
  2. Product Qualification Testing (PGT)
  3. Live-Fire Test & Evaluation (LFT&E)

 

DT&E is focused on early involvement in the acquisition life cycle by testing and evaluating earlier and more effectively, which will help to decrease costs, enhance performance, and retain schedule for programs. OSD DT&E Website 

 

DT&E includes activities that: [2]

  • Demonstrate that the engineering design and development process is complete
  • Demonstrate that the design risks have been minimized
  • Demonstrate that the system will meet specifications
  • Estimate the system’s military utility when introduced
  • Determine whether the engineering design is supportable (practical, maintainable, safe, etc.) for operational use
  • Provide test data with which to examine and evaluate trade-offs against specification requirements, life cycle cost, and schedule
  • Perform the logistics testing efforts to evaluate the achievement of supportability goals, the adequacy of the support package for the system, (e.g., deliverable maintenance tools, test equipment, technical publications, maintenance instructions, and personnel skills and training requirements, etc.).

 

The Program Manager (PM) is responsible for the ultimate success of the overall program. The PM and the test specialists on the PM’s staff must foster an environment that provides the contractor with sufficient latitude to pursue innovative solutions to technical problems and, at the same time, provides the data needed to make rational trade-off decisions between cost, schedule, and performance as the program progresses. [1]

 

Product Qualification Testing (PGT) is also another form of development testing that verifies the design and manufacturing process. PQTs are formal contractual tests that confirm the integrity of the system design over the operational and environmental range in the specification. [1]

 

Qualification Test and Evaluation (QT&E) is performed by government test representatives and is a tailored type of DT&E for which there is little to no RDT&E-funded development effort. It validates how a system integrates into its intended environment, how it meets specified requirements in accordance with the approved design, and how it meets performance standards.


AcqLinks and References:

Updated: 11/1/2019

JCIDS Process

Joint Requirements Oversight Council (JROC)

 

The Joint Requirements Oversight Council (JROC) charters and oversees the work in developing overarching joint operational and integrating concepts for joint missions during the joint concept development component of the JCIDS Process. The JROC reviews and approves all joint capabilities documents designated as JROC interest and supports the acquisition review process. The JROC validates capability needs and Key Performance Parameters (KPP) along with their associated threshold and objectives when it approves the associated capabilities documents; (Initial Capabilities Documents (ICD), Capability DEvelopment Documents (CPD), and Capability Production Documents (CPD)).

 

The JROC charters the Functional Capabilities Boards (FCB) to assist in carrying out its duties and responsibilities. The FCB reviews and, if appropriate, endorses all Joint Capabilities Integration and Development System (JCIDS) and joint DOTMLPF Change Recommendation (DCR) documents prior to their submission to the JROC. The JCIDS process was created to support the statutory responsibility of the JROC to validate joint warfighting requirements.

 

The JROC Title 10 responsibilities are identified below and in CJCSI 5123.01 Reference A.  The JROC processes are delineated in Reference G.

  1. The JROC reviews programs designated as JROC Interest and supports the acquisition review process. The JROC may review any JCIDS document or other issues requiring joint resolution. The JROC will also review programs at the request of the Secretary of Defense, Deputy Secretary of Defense, Under Secretary of Defense (Acquisition, Technology, and Logistics), Assistant Secretary of Defense (Networks and Information Integration/DOD Chief Information Officer, Under Secretary of the Air Force (as DOD Executive Agent for Space), or the Director of National Intelligence, Intelligence Resources Board (DNI IRB).
  2. For JROC Interest documents, the JROC will receive a recommendation from the Joint Capabilities Board (JCB) and the lead and supporting FCBs.
  3. The JROC validates and approves joint DOTMLPF Change Recommendations (DCR) that capture joint DOTMLPF and/or policy recommendations resulting from joint concept development and experimentation or Capability Based Assessments (CBA).

 

AcqLinks and Resources:

Update: 11/13/2018

Systems Engineering

Concept of Operations (CONOPS)

 

A Concept of Operations (CONOPS) is a verbal or graphic statement of a commander’s assumptions or intent in regard to an operation or series of operations as defined by Joint Publication 1-02 “DoD Dictionary of Military and Associated Terms”. It’s designed to give an overall picture of an operation.

 

Template: Concept of Operations (CONOPS)

 

In Acquisitions, a CONOPS is used to examine current and new and/or proposed capabilities required to solve a current or emerging problem.  It describes how a system will be used from the viewpoints of its various stakeholders. This provides a bridge between the often vague capabilities that a project begins with and the specific technical requirements needed to make it successful.  A CONOPS is a useful tool that helps the user community write/refine their Initial Capabilities Documents (ICD), System Requirements Document (SRD), and Capabilities Development Documents (CDD).

 

REGULATORY:  Component approved acquisition document that is derived from and consistent with the validated/approved capability requirements document. Will be provided to the Milestone Decision Authority (MDA) at the specified decision events and normally provided to the industry as part of the Request for Proposal (RFP). [2]

 

There are several reasons for developing a Concept of Operations:

  • Get stakeholder agreement identifying how the system is to be operated, who is responsible for what, what the lines of communication;
  • Define the high-level system concept and justify that it is superior to the other alternatives;
  • Define the environment in which the system will operate;
  • Derive high-level requirements in the ICD and CDD;
  • Provide the criteria to be used for validation of the completed system

 

A CONOPS can be developed in many different ways but usually share the same properties. In general, it will include the following:

  • Statement of the goals and objectives of the system
  • Strategies, tactics, policies, and constraints affecting the system
  • Organizations, activities, and interactions among participants and stakeholders
  • A clear statement of responsibilities and authorities delegated
  • Specific operational processes for fielding the system
  • Processes for initiating, developing, maintaining, and retiring the system

Checklist: Critical Information

  • Is the reason for developing the system clearly stated?
  • Are all the stakeholders identified and their anticipated roles described?
  • Are alternative operational approaches described and the selected approach justified?
  • Is the external environment described?
    • Does it include required interfaces to existing systems?
  • Is the support environment described?
    • Does it include maintenance?
  • Is the operational environment described?

 

AcqTips:

  • The CONOPS is also called a commander’s concept

AcqLinks and Resources:

Updated: 2/19/2019

Proposal Development

Sole Source – Justification and Approval

 

Justification and Approval (J&A) is a document required by the Federal Acquisition Regulation (FAR) (Subpart 6.3) that justifies and obtains approval for contract solicitations that use Other than Full & Open Competition (FOC). Also called sole source.

Quick Sheet: Justification and Approval (J&A) Primer

Template: Justification & Approval (J&A) Template – 13 Sept 2017

Guide: Amy Justification and Approval (J&A)

Guide: Justification & Approval Preparation Guide and Template 

 

Circumstances permitting other than full and open competition (FAR 6.302):
The following statutory situations permit contracting without providing for full and open competition:

  • Only one responsible source and no other supplies or services will satisfy agency requirements
  • Unusual and compelling urgency
  • Industrial mobilization; engineering, developmental, or research capability; or expert services
  • International agreement
  • Authorized or required by statute
  • National security
  • Public interest

 

Justifications Requirements (FAR 6.303):  
A contracting officer shall not commence negotiations for a sole source contract, commence negotiations for a contract resulting from an unsolicited proposal, or award any other contract without providing for full and open competition unless the contracting officer:

  •  A contracting officer shall not commence negotiations for a sole source contract, commence negotiations for a contract resulting from an unsolicited proposal, or award any other contract without providing for full and open competition unless the contracting officer:
    • Justifies the use of such actions in writing;
    • Certifies the accuracy and completeness of the justification; and
    • Obtains the approval.
  • Technical and requirements personnel are responsible for providing and certifying as accurate and complete necessary data to support their recommendation for other than full and open competition.
  • Justifications may be made on an individual or class basis. Any justification for contracts awarded under the authority of FAR 6.302-7 shall only be made on an individual basis. Whenever a justification is made and approved on a class basis, the contracting officer must ensure that each contract action taken pursuant to the authority of the class justification and approval is within the scope of the class justification and approval and shall document the contract file for each contract action accordingly.
  • The justifications for contracts awarded under the authority may be prepared and approved within a reasonable time after contract award when preparation and approval prior to award would unreasonably delay the acquisitions

Justification Content (FAR 6.303-2):
Each justification shall contain sufficient facts and rationale to justify the use of the specific authority cited. As a minimum, each justification shall include the following information:

  1. Identification of the agency and the contracting activity, and specific identification of the document as a “Justification for other than full and open competition.”
  2. Nature and/or description of the action being approved.
  3. A description of the supplies or services required to meet the agency’s needs (including the estimated value).
  4. An identification of the statutory authority permitting other than full and open competition.
  5. A demonstration that the proposed contractor’s unique qualifications or the nature of the acquisition requires use of the authority cited.
  6. A description of efforts made to ensure that offers are solicited from as many potential sources as is practicable, including whether a notice was or will be publicized as required by Subpart 5.2 and, if not, which exception under 5.202 applies.
  7. A determination by the contracting officer that the anticipated cost to the Government will be fair and reasonable.
  8. A description of the market research conducted and the results or a statement of the reason market research was not conducted.
  9. Any other facts supporting the use of other than full and open competition, such as:
    • Explanation of why technical data packages, specifications, engineering descriptions, statements of work, or purchase descriptions suitable for full and open competition have not been developed or are not available.
    • For follow-on acquisitions as described (FAR 6.302-1(a)(2)(ii)) an estimate of the cost to the Government that would be duplicated and how the estimate was derived.
    • When (FAR 6.302-2) is cited, data, estimated cost, or other rationale as to the extent and nature of the harm to the Government.
  10. A listing of the sources, if any, that expressed, in writing, an interest in the acquisition.
  11. A statement of the actions, if any, the agency may take to remove or overcome any barriers to competition before any subsequent acquisition for the supplies or services required.
  12. Contracting officer certification that the justification is accurate and complete to the best of the contracting officer’s knowledge and belief.

 

AcqLinks and References:

Updated: 5/21/2018

Purchasing & Small Business

Small Disadvantaged Business

 

A Small Disadvantaged Business (SDB) is a small business that is at least 51 percent owned by one or more individuals who are both socially and economically disadvantaged. SDB status makes a company eligible for bidding and contracting benefit programs involved with federal procurement. Businesses must be certified by the Small Business Administration (SBA) to qualify for SDB status. FAR Subpart 19.304 requires an SDB at the time of its offer (prime or subcontracting) to have certification from SBA or to have completed and submitted a SDB application.

 

The SBA defines socially disadvantaged groups as those who have been, historically, subjected to “racial or ethnic prejudice or cultural bias” within the larger American culture. Identified groups include African Americans, Asian Pacific Americans, Hispanic Americans, Native Americans, and Subcontinent Asian Americans. Members of other groups may qualify if they can satisfactorily demonstrate that they meet established criteria.

 

Small Business Certification [1]
Before you can begin a business with the government your business must obtain the proper certifications. The Federal government sets aside certain contract bid opportunities exclusively for small businesses. In order to compete for these contracts, you must first register as a vendor with the government.

As part of the registration process, you will be required to enter information about your company in the System of Awards Management (SAMS) database. In SAMS, you may self-certify yourself as a small business, but you must meet the Federal government’s definition of a small business.

 

Steps to Registering as a Federal Contractor [1]

  1. Obtain a D-U-N-S Number – You will need to obtain a Dun & Bradstreet D-U-N-S® Number. This is a unique nine-digit identification number for each physical location of your business. The assignment of a D-U-N-S Number is free for all businesses required to register with the federal government for contracts or grants. Visit the D-U-N-S Request Service to register.
  2. Register your Business with the SAMS – You need to register your business with the federal government’s System of Awards Management (SAM).
  3. Find the NAICS Codes for Your Company – North American Industry Classification System (NAICS) code for administrative, contracting and tax purposes.  Read Identifying Industry Codes for more information.
  4. Obtain Past Performance Evaluations – Businesses interested in getting on the U.S. General Services Administration (GSA) Schedule for contracts should obtain an Open Ratings, Inc. Past Performance Evaluation

 

AcqNotes:

  • The System for Award Management (SAM) has replaced the Central Contractor Registration (CCR)

 

AcqLinks and References:

Updated: 3/1/2021

Systems Engineering

System Requirements Document (SRD)

 

The System Requirement Document (SRD) defines system level functional and performance requirements for a system. The SRD is derived from the Capability Development Document (CDD), Concept of Operations (CONOPS), system-level performance metrics, mission threads/use cases, and usage environment and is developed but by the program office.  It should include a system-level description of all software elements required by the preferred system concept.  The SRD is developed during the Technology Maturation & Risk Reduction (TMRR) Phase but a draft SRD should be developed for the Analysis of Alternatives (AoA) in the Materiel Solutions Analysis (MSA) Phase. The SRD is used by the program office to provide more detailed requirements than what’s provided in the CDD and is normally included in a solicitation package. The SRD should be finalized prior to the contract award. [1]

 

Standard: MIL-STD-961 “Defense and Program-Unique Specifications Format and Content” – 9 Jan 2014

 

The SRD should be developed with feedback and input from the industrial base. Once the SRD is placed on contract, the contractor will further develop the specification and develop their own, more detailed requirements document; sometimes called a Weapons Systems Specification (WSS).

 

The term “System Requirements Document” is a phrase commonly used to describe a software performance specification. If your acquisition is exclusively for software, you may call yours a “System Performance Specification” or “System Requirements Document”.

 

Follow MIL-STD-961E “Defense and Program-Unique Specifications Format and Content” when developing the SRD.

 

AcqTips:  

  • A contractor may build an internal document for managing the traceability of their requirements. If they call this an SRD, you might want to call yours a system specification to avoid confusing the two. Any requirements in their document should be ultimately traceable back to your system performance specification.
  • The SRD and WSS should all be traceable to the Initial Capabilities Document (ICD) and CDD.

AcqLinks and References:

Updated: 6/01/2018

Proposal Development

DoD Source Selection Procedures

 

The Department of Defense (DoD) Source Selection Procedures, dated 1 April 2016, was established to standardize the methodology and approach the DoD used to conduct competitive negotiated source selections. It outlines a common set of principles and procedures for conducting such acquisitions. The goal of this procedure is to ensure the Department’s source selection process delivers quality, timely products and services to the Warfighter and the Nation at the best value for the taxpayer.

 

The procedures state: [1]

  • Mandatory for all competitive acquisitions utilizing FAR Part 15 procedures
  • Source Selection Authority (SSA) shall be an individual other than the Procuring Contracting Officer (PCO) for >$100M
  • Source Selection Advisory Council (SSAC) required >$100M
  • SSAC required to provide written comparative analysis of proposals and award recommendation to the SSA
  • Required use of standardized rating criteria for the “technical” and “past performance” factors
  • Required use of standardized rating criteria for the “technical” and “past performance” factors
  • Standardized Lowest Price Technically Acceptable process rating criteria
  • Prescribed Source Selection Plan format
  • SSA makes a determination for discussions
  • Provides guidance on the use of Non‐Government advisors
  • Program Management/Requirements Office roles and responsibilities
  • Use of a draft RFP is highly recommended on all acquisitions
  • Cost, Quality, and Past Performance shall be evaluated in every source selection
  • Written Narrative Report required by the Source Evaluation Board for the SSA and SSAC

 

Website DAU Tool: Source Selection Procedures (SSP)

 

These procedures ARE NOT required for the following acquisitions: [1]

  • Competitions where the only evaluated factor is price
  • Basic research and acquisitions where Broad Agency Announcements (BAA) are used in accordance with FAR Part 35 to solicit proposals and award contracts,
  • Small Business Innovative Research (SBIR), Small Business Technology Transfer Research (STTR) and Small Business Technology Transfer (SBTT) acquisitions solicited and awarded in accordance with 15 United States Code (U.S.C.), Section 638.
  • Architect-engineer services solicited and awarded in accordance with FAR Part 36,
  • FAR Part 12 Streamlined Acquisitions
  • Acquisitions using simplified acquisition procedures in accordance with FAR Part 13 (including Part 12 acquisitions using Part 13 procedures),
  • Orders under multiple-award contracts – Fair Opportunity (FAR 16.505 (b)(1))
  • Acquisitions using FAR subpart 8.4.

 

AcqLinks and References:

Updated: 6/28/2018