Back to Top

Educating the Aerospace Industry

Blog Archives

Logistics & Supply Management

Public Private Partnerships (PPP)

Public-Private Partnerships (PPP) (10 U.S.C. §2474) for Depot-Level Maintenance is defined as “a public-private partnership for depot-level maintenance under a cooperative arrangement between an organic depot-level maintenance activity and one or more private sector entities to perform DoD or Defense-related work and/or to utilize DoD depot facilities and equipment. Other government organizations, such as program offices, inventory control points, and materiel/systems/logistics commands, may be parties to such agreements.” [1]

Performance-Based Logistics implementation strategies shall consider PPP to satisfy the core capabilities requirements of 10 U.S.C. 2464 “Core logistics capabilities” and the limitations on the performance of depot-level maintenance and materiel requirements contained in 10 U.S.C. 2466 “Limitations on the performance of depot-level maintenance of materiel”.

The three (3) basic types of PPP are: [2]

  1. Workshare: A partnership in which a government buying activity, in collaboration with a contractor and a depot maintenance activity, determines the best mix of work capitalizing on each partner’s capabilities. The workload is then shared between the contractor and the organic activity. The contractor is funded through a contract, and the organic activity is funded through a project or work order (in the case of depot maintenance). The partnering agreement between the contractor and organic activity focuses on the roles and responsibilities of each partner. The partners work jointly to accomplish the overall requirement.
  2. Direct Sale (Sales of Articles and Services): An arrangement, currently authorized primarily for depot maintenance activities designated as Centers of Industrial and Technical Excellence (CITE), and other working capital funded industrial facilities under specified circumstances, whereby military and commercial entities enter into a contractual relationship for the sale of depot maintenance articles and/or services to an outside (non-government) entity, usually a contractor.
  3. Lease: An arrangement that allows a private sector entity to have access to, and beneficial use of, facilities or equipment located at an organic depot designated as a CITE. Facilities and equipment may be made available for lease so long as the arrangement does not preclude the depot maintenance activity from performing its mission. The goal is to make government-owned facilities more efficient through better utilization.

AcqLinks and References:

Updated: 7/19/2017

Major Reviews

Test Readiness Review (TRR)

A Test Readiness Review (TRR) is conducted to determine if the system under review is ready to proceed into formal testing by deciding whether the test procedures are complete and verify their compliance with test plans and descriptions. A TRR is normally conducted before each major test configuration item including hardware and software and provides management with the assurance that a system has undergone a thorough test process and is ready for turnover to the next test phase. The Flight Readiness Review (FRR) is a subset test of the TRR.

Checklist: Test Readiness Review (TRR) Risk Assessment

The TRR assesses test objectives, test methods and procedures, scope of tests, and safety and confirms that required test resources have been properly identified and coordinated to support planned tests. The TRR verifies the traceability of planned tests to program requirements and user needs. The TRR also assesses the system under review for development maturity, cost/ schedule effectiveness, and risk to determine readiness to proceed to formal testing.

The TRR should answer the following questions:

  1. Why are we testing?
  2. What is the purpose of the planned test?
  3. Does the planned test verify a requirement that is directly traceable back to a system specification or other program requirement?
  4. What are we testing (subsystem, system, system of systems, other)?
  5. Is the configuration of the system under test sufficiently mature, defined, and representative to accomplish planned test objectives and or support defined program objectives?
  6. Are we ready to begin testing?
  7. Have all planned preliminary, informal, functional, unit level, subsystem, system, and qualification tests been conducted, and are the results satisfactory?
  8. What is the expected result and how can/do the test evaluation results affect the program?
  9. Is the planned test properly resourced (people, test article or articles, facilities, data systems, support equipment, logistics, etc.)?
  10. What are the risks associated with the tests and how are they being mitigated?
  11. What are the hazards and ESOH risks associated with the specific testing?
  12. Have the necessary “Safety Releases” from the Program Manager (PM) been provided to developmental and operational testers prior to any test using personnel?
  13. What is the fall-back plan should a technical issue or potential showstopper arise during testing?

The scope of the TRR is directly related to the risk level associated with performing the planned tests and the importance of the test evaluation results to overall program success. The level of specific risk and associated risk level will vary as a system proceeds from component level, to system level, to systems of systems level testing. Early component level tests may not require the same level of review as the final system level tests. Sound judgment should dictate the scope of a specific test or series of tests.

Typical TRR success criteria including the following:

  • Completed and approved test plans for the system under test,
  • Completed identification and coordination of required test resources,
  • The judgment that previous component, subsystem, and system test results form a satisfactory basis for proceeding into planned tests, and
  • Identified risk level acceptable to the program leadership.

The Program Manager (PM) should address the scope of the TRR in the Systems Engineering Plan (SEP). Test and Evaluation (T&E) is an integral part of the Systems Engineering Processes of Verification and Validation.

AcqLinks and References:

Updated: 7/18/2017

Test & Evaluation

T&E Program Office Responsibilities

The Program Manager (PM) is ultimately responsible for all aspects of the system development, including testing. The Deputy for Test and & Evaluation (T&E) is normally authorized by the PM to conduct all duties in the area of T&E. [1]

In government acquisition programs, there should be an element dedicated to the management of T&E. This element has the overall test program responsibility for all phases of the acquisition process. T&E expertise may be available through matrix support or reside in the Program Management Office (PMO) engineering department during the program’s early phases. [1]

By System Demonstration, the Program Management Office (PMO) should have a dedicated T&E manager. In the PMO, the Deputy for T&E would be responsible for defining the scope and concept of the test program, establishing the overall program test objectives, and managing test program funds and coordination. The Deputy for T&E should provide test directors (such as a joint test director) as required, and coordinate test resources, facilities, and their support required for each phase of testing. In addition, the Deputy for T&E or a staff member will be responsible for managing the Test and Evaluation Master Plan (TEMP), and planning and managing any special test programs required for the program. The Deputy for T&E will also review, evaluate, approve, and release for distribution contractor-prepared test plans and reports, and review and coordinate all appropriate government test plans. [1]

After the system is produced, the Deputy for T&E will be responsible for supporting production acceptance testing and the test portions of later increments, Preplanned Product Improvements (P3I) upgrades, or enhancements to the weapon system/acquisition. If the program is large enough, the Deputy for T&E will be responsible for all T&E direction and guidance for that program. [1]

Updated: 7/18/2017

Test & Evaluation

Advanced Technology Demonstration (ATD)

An Advanced Technology Demonstration (ATD) is a demonstration of the maturity and potential of advanced technologies for enhanced military operational capability or cost effectiveness. They may provide early insights into available technologies for incorporation into developmental or mature, post-prototype systems. ATDs are identified, sponsored, and funded by Services and agencies. They follow Advanced Technology Development. [1]

AcqLinks and References:

Updated: 7/18/2017

Contracts & Legal

US Code Title 10 Armed Forces

Title 10 provides the legal basis for the roles, missions and organization of each of the services as well as the United States Department of Defense. Each of the five subtitles deals with a separate aspect or component of the armed services. [1]

AcqTips:

AcqLinks and References:

Updated: 7/18/2017

Contracts & Legal

Contract Essential Elements

One of the most important issues to understand about contract law is how a contract is formed. Many agreements may be legally unenforceable or “void” because they lack one of the essential elements for a valid contract. The five essential elements are:

  1. Offer: An offer is a specific promise and a specific demand. For example: “I will pay $13,000 for the car.”
  2. Acceptance: The acceptance may be in the form of a promise or an act. The acceptance must “mirror” the offer. If it changes the terms of the offer, it is a counteroffer. For example: “I agree to sell you the car for $13,000.”
  3. Consideration: The consideration is the receipt of a legal benefit or the suffering of a legal detriment. It may be a promise, an act or monetary. In the example of the sale of the car, the $13,000 would be the consideration.
  4. Capacity: A party to a contract must have the ability to enter into a legal contract. Courts have held 3 classes of persons lack capacity to be bound by contractual promises – minors, intoxicated persons and mentally incompetent persons.
  5. Lawful purpose: A valid contract must have a legal purpose. For example, a “contract” to murder someone would be not be enforceable in court.

AcqLinks and References:

Updated: 7/17/2017

Systems Engineering

Process Inputs Outputs Loops

Process Inputs, Outputs and Loops are part of teh steps that are included in the Systems Engineering Process.

Process Inputs 

The customer’s/User’s needs, objectives and requirements in terms of capabilities, measures of effectiveness, environments, and constraints initiate the systems engineering process. A few of the inputs include:

  • Customer Needs/Objectives/Requirements
  • Measures of Effectiveness (MoE),
  • Environments,
  • Constraints
  • Technology Base
  • Output Requirements from Prior Development Effort
  • Program Decision Requirements
  • Requirements from Specs and Standards
  • Laws and Regulations

Requirements Loops
The Requirements Loop serves to refine the requirements and initiate re-evaluation to determine how firm the requirements are for items that prove to be major cost, schedule, performance or risk drivers. Later in the overall process, detailed system characteristics are compared against the established requirements to verify that they are being met. Requirements analysis links with the Functional Analysis and Allocation to form the Requirements Loop of the System Engineering Process.

Design Loop
The Design Loop operates in parallel with the Requirements Loop. Functional interfaces are established and Functional Architectures defined so that physical system configurations can be developed. As concepts are transformed to hardware and software designs, the design characteristics are analyzed against the allocated requirements. Functional architectures and allocations are re-examined and modified if necessary. Some results of the Design Loop may even reflect into the Requirements Analysis necessitating further re-evaluation.

Process Outputs
The output of the System Engineering Process includes a decision database and a balanced system solution. The database documents include:

  • the design,
  • all the decisions made to arrive at the design,
  • defining specifications,
  • verification requirements
  • traceability of design features to imposed requirements
  • constraints
  • specifications
  • standards

AcqLinks and References:

Updated: 7/17/2017

Systems Engineering

Functional Architecture

A Functional Architecture is an architectural model that identifies system function and their interactions. It defines how the functions will operate together to perform the system mission(s). Generally, more than one architecture can satisfy the requirements. Usually each architecture and its set of associated allocated requirements have different cost, schedule, performance, and risk implications. The functional architecture is used to support functional and performance test development. It also supports development, along with the physical architecture, of verification tasks that are defined to verify the functional, performance and constraint requirements. A system will have a functional and Physical Architecture.

During the Functional Analysis and Allocation step, the functional requirements identified in the Requirements Analysis step are decomposes and their associated performance requirements into sub functions to the point that they can be unambiguously related to the system elements or products that make up the design that flows out of a later step. The result is often called the functional architecture. [1]


Functional Architecture

SMC Systems Engineering Handbook, Figure 15

In the Design Loop, synthesized designs are compared with the originating architectures and allocated requirements to assure compliance or to initiate re-evaluation. Sometimes it is necessary to drive toward optimal solutions by presenting various functional views including those that depict functional relationships with existing assets to enable more thorough assessments of plausible solutions. [1]

AcqLinks and References:

Updated: 7/17/2017

Systems Engineering

Capstone Threat Assessment (CTA)

(This Assessment Has Been Deleted)

The Capstone Threat Assessment (CTA) details how foreign countries are developing capabilities that will/can challenge US warfighting capabilities. The assessment is written by the Defense Intelligence Agency (DIA) with input from other intelligence organizations.

The DIA validates seven (7) types of CTA’s:

  1. Land Warfare Capstone Threat Assessment
  2. Air Warfare Capstone
  3. Chemical, Biological, and Radiological Warfare Capstone Threat Assessment
  4. Information Operations Capstone Threat Assessment
  5. Maritime Warfare
  6. Missile Defense Threat Environment
  7. Space Capstone Threat Assessment

REGULATORY: Capstone Threat Assessments are maintained by the responsible production center and are required to be updated every 2 years, independent of acquisition decision events. [1]

CTA serve as the analytical foundation for System Threat Assessment Reports (STARs) and maintain projections of technology and adversary capability trends over the next 20 years. [1]

AcqTips:

  • Specific web address for each CTA type can be found in the DAG

Updated: 7/17/2017