Skip Ribbon Commands
Skip to main content

Engineering Management

Technical Planning
Requirements Decomposition
Technical Assessment
Decision  Analysis
Configuration Mgmt
Technical Data Mgmt
Interface Mgmt
Topic Area
ACC Topic
Summary Description
Theater Battle Management Core System SE Case Study Collens Krause.pdf
Engineering; Information Technology; Intelligence Support; Program Management; Test and EvaluationLearning MaterialEngineering Management5/18/2017 7:47 PMAir Force; Army; DoD; Navy
The Theater Battle Management Core System (TBMCS) is an integrated air command
and control (C2) system that performs standardized, secure, automated air battle planning and
execution management for Air Force, multi-service, and allied commanders in theaters of
operation worldwide. TBMCS provides the means to plan, direct, and control all theater air
operations and to coordinate with land, maritime, and special operations elements. It is deployed
at C2 nodes at national, force and wing/unit-level elements. TBMCS operates in support of
planners and decision makers at, and below, the level of Joint Force Air Component
Commander. The system is modular and scalable for air, land, or sea transport and the deployed
configurations can be tailored to meet a particular contingency.

Anderson NDIA SE Division Meeting 12Apr05.ppt
Contracting; Engineering; Information Technology; Program Management; Requirements ManagementLearning MaterialEngineering Management6/26/2017 9:10 AMDoD; Joint Staff
NDIA Systems Engineering Division MeetingApril 12, 2005

Warren M. Anderson, Col, USAF
Deputy for Systems Engineering Plans and Policy
Office of the Under Secretary of Defense (AT&L) Defense Systems, Systems Engineering, Enterprise Development
Post CDR Report ADDM Template v 2.0.docx
EngineeringExampleAir Force Examples; PM Technical Management; Engineering Management6/27/2017 2:45 PMAir Force
This Template is courtesy of the Air Force, provided from the Air Force Acquisition Document Development & Management (ADDM) System, which is a restricted DoD site. Please note that this is an Air Force Template provided for your guidance, and that the other services or agencies may have different documentation requirements.
This document is current as of 3/9/2016 ADDM template source review.Based on: DoDI 5000.02 dated 07 JAN 2015
ADDM Application link
Per the Memorandum for Secretaries of the Military Departments Directors of the Defense Agencies, dated 24 February 2011, the Program Manaager’s reporting responsibility for the Post-Critical Design Review (CDR) Report currently required by DoD Instruction 5000.02, Enclosure 2, para 6.c(6)(c)(1) has been eliminated.  The Office of the Deputy Assistant Secretary of Defense (Systems Engineering) (DASD(SE)) will participate in program CDRs and prepare a brief assessment of the program’s design maturity and technical risks which may require Milestone Decision Authority (MDA) attention.
The system-level Critical Design Review (CDR) provides an opportunity to assess design maturity.  For complex systems, the program manager may conduct a CDR for each subsystem or configuration item. These individual reviews would lead to an overall system CDR. When individual reviews have been conducted, the emphasis of the overall system CDR should focus on configuration item functional and physical interface design, as well as overall system detail design requirements. The CDR determines whether the hardware, human, and software final detail designs are complete, and whether the Integrated Product Team is prepared to start system fabrication, demonstration, and test.
The subsystem detailed designs are evaluated to determine whether they correctly and completely implement all system requirements allocated to the subsystem, and whether the traceability of final subsystem requirements to final system detail design is maintained. At this review, the Integrated Product Team also reviews the results of peer reviews on requirements and final detail design documentation, and ensures that the latest estimates of cost (development, production, and support) are consistent with the detail design. A successful review is predicated on the Integrated Product Team's determination that the subsystem requirements, subsystem detail design, results of peer reviews, and plans for testing form a satisfactory basis for proceeding into system fabrication, demonstration and test.
The Post-CDR Assessment provides an opportunity to assess design maturity prior to establishment of the product baseline. (Reference: DoDI 5000.02, paragraphs 6.c(6)b and 6.c(6)c.
dd1494 ADDM Template 042015.pdf
Program ManagementExampleAir Force Examples; PM Technical Management; Engineering Management6/27/2017 3:28 PMAir Force
This Template is courtesy of the Air Force, provided from the Air Force Acquisition Document Development & Management (ADDM) System, which is a restricted DoD site. Please note that this is an Air Force Template provided for your guidance, and that the other services or agencies may have different documentation requirements.
This document is current as of 3/9/2016 ADDM template source review.Based on: DD Form 1494, Apr 2015,
ADDM Application link
The DD Form 1494 / Spectrum Supportability Determination template provides assurance that the necessary frequencies and bandwidth are available to military systems in order to maintain effective interoperability in the operational EME. The assessment of an equipment or system as having spectrum supportability is based upon, as a minimum, receipt of equipment spectrum certification (ESC), reasonable assurance of the availability of sufficient frequencies for operation, Host Nation Approval (HNA), and consideration of EMC (DD Form 1494).
Criticality Analysis ADDM Template v 1.1.xlsx
EngineeringExampleAir Force Examples; PM Technical Management; Engineering Management6/27/2017 3:32 PMAir Force
This Template is courtesy of the Air Force, provided from the Air Force Acquisition Document Development & Management (ADDM) System, which is a restricted DoD site. Please note that this is an Air Force Template provided for your guidance, and that the other services or agencies may have different documentation requirements.
This document is current as of 3/9/2016 ADDM template source review.Based on: Program Protection Plan, Appendix C dated 01 Jul 2011
ADDM Application link
·    Document the results of the most recent Criticality Analysis (CA) in tab Part 1 & tab Part 2, Table C-1 and C-2  respectively in the Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)) Program Protection Plan Outline and Guidance (Version 1.0, July 2011).  The CA should be updated regularly (e.g. at each SE Technical Review).·    Early in the program lifecycle, the CA may only be able to identify missions or missions and critical functions.·    Criticality should be assessed in terms of relative impact on the system's ability to complete its mission if the component fails.·    Level I is total mission failure, Level II is significant/unacceptable degradation, Level III is partial/acceptable, and Level IV is negligible.
The Criticality Analysis table documents the mission-critical functions and components.  The table shows an end-to-end functional decomposition of the system which includes:

Identifying and prioritizing system mission threads; 
Decomposing the mission threads into their mission-critical functions; and 
Identifying the system components (hardware, software, and firmware) that implement those functions; i.e., components that are critical to the mission effectiveness of the system or an interfaced network.
C 5A Galaxy SE Case Study.pdf
Engineering; Information Technology; Program Management; Requirements ManagementLearning MaterialEngineering Management6/28/2017 3:30 PMAir Force

The C-5 Systems Engineering Case Study captures the untold story of the application of
systems engineering during the concept exploration, development, and production of the USAF
C-5A and C-5B aircraft. The case study examines and dissects the systems engineering process
as applied by the Air Force C-5 System Program Office and the prime contractor, Lockheed,
Georgia, from the program's genesis in 1957 to the last delivery of the C-5A and the beginning
of the C-5B program in 1973. Numerous interviews were conducted with the principals who
managed and directed the program and a story of the systems engineering process was
developed. The case study traces the program's systems engineering process in translating a
vision into 125 cargo transport aircraft that have served our nation proudly for the last 35 years.
A description of the program is essential to orient students to the size of the aircraft and
the magnitude of the program and thus enable them to appreciate the systems engineering
process and how it was applied. When the C-5 aircraft first entered the inventory in 1970, it was
the largest aircraft in the world, and it is still the largest transport cargo aircraft in our inventory.
It was the first of the behemoths. Figure 1 shows the dimensions of the aircraft and helps give a
perspective of its size.
DoD Open System Architecture (OSA) Contract Guidebook for Program Managers-version 1.1- June  2013.pdf
Program Management; EngineeringLearning MaterialModular Open Systems Approaches; Engineering Management; Program Management11/1/2017 6:02 PMDoD
Executive Summary
This Open Systems Architecture Contract Guidebook provides contract language targeted at the needs of the Program Manager. This document contains the basic elements to capture the benefits of an open architecture and an open business model. The essence of Open Systems Architecture (OSA) is organized decomposition, using carefully defined execution boundaries, layered onto a framework of software and hardware shared services and a vibrant business model that facilitates competition. OSA is composed of five fundamental principles:

1. Modular designs based on standards, with loose coupling and high cohesion, that allow for independent acquisition of system components:
2. Enterprise investment strategies, based on collaboration and trust, that maximize reuse of proven hardware system designs and ensurewe spend the least to get the best;
3. Transformation of the life cycle sustainment strategies for software intensive systems through proven technology insertion and software product upgrade techniques;
4. Dramatically lower development risk through transparency ofsystem designs, continuous design disclosure, and Government, academia, and industry peer reviews;
5. Strategic use of data rights to ensure a level competitive playing field and access to alternative solutions and sources, across the life cycle.

A mandate of OSA is that technical requirements be based to the maximum extent practicable on open standards. Where there are no standards, the OSA methodology creates them. At a minimum, technical standards and related specifications, requirements, source code, metadata, interface control documents (ICDs), and any other implementation and design artifacts that are necessary for a qualified contractor to successfully perform development or maintenance work for the Government are made available throughout the life cycle.
Asking the Right Questions at the Right Time-Lessons Learned for Project, Program and Portfolio Managers-20130624.pdf
Engineering; Program ManagementLessons LearnedEngineering Management; Portfolio Management; Program Execution5/2/2018 10:50 AMDoD
The intent of this document is to summarize lessons learned and best practices as a result of reviewing 18-plus programs. These lessons learned are intended to assist Program Managers and their Engineering staffs with best practices that have proven successful over the years to ensure that reliability is designed into programs early in the acquisition cycle. All aspects of Reliability design were not addressed by these case studies, and it is not intended to circumvent or replace good systems engineering processes. Rather, the best practices and lessons learned contained herein are a compilation of reliability design activities that are most often overlooked, skipped, or short-changed in the interest of reducing cost or schedule. Adherence to these activities combined with solid system engineering processes has proven to be invaluable in helping programs through the major Milestones (MS A, B, and C) of the DoD Acquisition System.

To ensure systems performance is achieved, each reliability activity should be thoroughly addressed during technical or program reviews. Program Managers are encouraged to engage the Program’s Engineering staff using the questions recommended for each reliability activity to ensure the Contractor has appropriately incorporated each activity into the design process.
F 111 SE GK Richey.pdf
Engineering; Information Technology; Program ManagementLearning MaterialEngineering Management2/12/2020 8:35 AMAir Force; Army; DoD; Navy

The application of key Systems Engineering principles to the F-111 provides a wealth of lessons learned to be used as heuristics for future development and production programs and to compare to the modern systems engineering theory and practices taught in the leading universities today. The systems engineering lessons from the F-111 program will facilitate
learning by emphasizing practical applications and resulting outcomes to the current processes and tools used on today's programs. The student will understand the long-term consequences of systems engineering as implemented on the F-111 and its effect on cost, schedule, and operational effectiveness. The reader can then postulate outcomes of alternate decisions at the program/system level.
Systems Engineering Plan Guide v90 1 759265.doc
EngineeringLearning MaterialEngineering Management2/12/2020 8:36 AM
Preparation Guide Version 0.90
October 18, 2004
Purpose of the Guide
This document guides program teams in generating their program's Systems Engineering Plan (SEP) regardless of the ACAT level of the program.  This Guide provides an approach for organizing, compiling, and writing a SEP.  It describes the key information to include in a SEP; it is not a tutorial on how to accomplish the systems engineering activities discussed in the Plan.  The SEP is a "living" document that captures a program's current and evolving systems engineering strategy and its relationship with the overall program management effort.  The SEP purpose is to guide all technical aspects of the program.  It should be established early in the Concept Refinement phase and updated continually.  The level of fidelity and emphasis will evolve as the program progresses through its lifecycle.  It provides a comprehensive, integrated technical plan that reflects the program's strategy to achieve its objectives within acceptable risks.  Throughout the Guide are links to the appropriate reference material that will give the program team additional information regarding the key systems engineering activities within the systems engineering strategy. 
Hubble Space Telescope SE Case Study JJ Mattice.pdf
Contracting; Engineering; Information Technology; Program Management; Requirements ManagementLearning MaterialEngineering Management2/12/2020 8:54 AMAir Force; DoD
Executive Summary:
The Hubble Space Telescope (HST) is an orbiting astronomical observatory operating in the spectrum from the near-infrared into the ultraviolet. Launched in 1990 and scheduled to
operate through 2010, HST carries and has carried a wide variety of instruments producing imaging, spectrographic, astrometric, and photometric data through both pointed and parallel observing programs. Over 100,000 observations of more than 20,000 targets have been produced for retrieval. A macroscopic, cumulative representation of these observations is shown in the figure below to provide a sense of the enormous volume of astronomical data collected by the HST about our universe, our beginnings, and, consequently, about our future. The telescope is already well known as a marvel of science. This case study hopes to represent the facet of the HST that is a marvel of systems engineering, which, in fact, generated the scientific research and observation capabilities now appreciated worldwide.