Skip Ribbon Commands
Skip to main content
 
      

PM Technical Management

This page list the PM Career Field Technical Management Competencies and related content. Most of the content in the PM CoP is organized into the four major PM competency areas (Acquisition Management, Business Management, Executive Leadership, and Technical Management) as described in detail in the PM Functional Career Field Competencies Memo dated September 6, 2016.

 

Defense Business Systems
   DBS Certification
   DBS Acquisition Approach Preparation
Engineering Management
   Technical Planning
   Requirements Decomposition
   Technical Assessment
   Decision  Analysis
   Configuration Mgmt
   Technical Data Mgmt
   Interface Mgmt
Manufacturing Management
   Manufacturing Planning and Transition
   Manufacturing  Shutdown
Product Support Management
   Product Support Planning
   Product Support Mgmt
   Supply Chain Mgmt
Software Development
Test and Evaluation Management
   Test Planning
   Test Execution

  
  
Topic Area
  
Organization
  
  
ACC Topic
  
Summary Description
  
  
red book.pdf
  
EngineeringArmy; DoDReferenceSoftware Development
The "little red book" is divided into seven sections: general precepts about COTS products, requirements, evaluation and design, maintenance, business processes, testing and debugging, and IPTs.
5/18/2017 7:44 PM
TEN COMM.pdf
  
EngineeringDoDReferenceSoftware Development
Interest in COTS products requires examination both in terms of its causes and effects, and also in terms of its benefits and liabilities. In this paper we offer some observations on all of these, and voice some specific concerns and criticisms. We stress that our observations are essentially cautionary, not condemnatory: it is obvious to almost any observer that the huge growth in software costs will continue, not abate, and that appropriate use of commercially-available products is one of the remedies that might enable us to acquire needed capabilities in a cost-effective manner.  Where use of an existing component is both possible and feasible, it is no longer acceptable for the Government to specify, build, and maintain a comparable product; clearly an existing commercial solution is called for.
5/18/2017 7:44 PM
COTS Gotchas.pdf
  
ReferenceSoftware Development
The presentation provides information on assumptions and errors in COTS procurement that can deleteriously affect the process.
5/18/2017 7:44 PM
25 p822.pdf
  
EngineeringNavyLearning MaterialSoftware Development
Software infrastructure plays a crucial role in adopting industry advances for mission-critical systems. This presentation will explain software infrastructure's role, problem domain, and challenges. In addition, this presentation will describe an approach to determine the merits of emerging technologies. Discussed are the software infrastructure layers, related technologies, and practical experiences; as well as the operating system layer, the middleware layer, the component framework layer, and the data tier.
5/18/2017 7:47 PM
SEI Management Practices.aspx
  
ReferenceSoftware Development
This website is a listing of the software engineering management practices, software engineering management, SEI projects, and software engineering. Topics include: CMM, CMMI, SEI Appraisal program, IDEAL, Risk Management, Personal Software Process (PSP), Team Software Process (TSP), Software Acquisition CMMR, Software Acquisition Guidebooks, Software Risk Evaluation Service, Software Engineering Measurement & Analysis (SEMA), Software Engineering Information Repository (SEIR), and links to SEI Initiatives, Publications and Training.
5/18/2017 7:47 PM
Acquiring All You Need to Maintain Your Software.pdf
  
Contracting; EngineeringNavyLearning MaterialSoftware Development
by Al Kaniss from Defense AT&L; March-April 2005
The government doesn't automatically own software that is produced on a government contract, even if the government paid for 100 percent of its development.
5/18/2017 7:47 PM
James Smith.pdf
  
EngineeringAir Force; Army; DoDLearning MaterialPM Technical Management
James D. Smith II Carnegie Mellon Software Engineering Institute 4301 Wilson Boulevard, Suite 902, Arlington, VA 22203 jds@sei.cmu.edu
 
Within the Department of Defense, Technology Readiness Levels (TRLs) are increasingly used as a tool
in assessing program risk. While there is considerable evidence to support the utility of using TRLs as part of an overall risk assessment, some characteristics of TRLs limit their applicability to software products, especially Non-Developmental Item (NDI) software including Commercial-Off-The-Shelf, Government-Off-The-Shelf, and Open Source Software. These limitations take four
principle forms: 1) "blurring-together" various aspects of NDI technology/product readiness; 2) the absence of some important readiness attributes; 3) NDI product "decay;" and 4) no recognition of the temporal nature of system development and acquisition context. This paper briefly explores these issues, and describes an alternate methodology which combines the desirable aspects of TRLs with additional readiness attributes, and defines an evaluation framework which is easily understandable, extensible, and applicable across the full spectrum of NDI software.
5/18/2017 7:47 PM
Theater Battle Management Core System SE Case Study Collens Krause.pdf
  
Engineering; Information Technology; Intelligence Support; Program Management; Test and EvaluationAir Force; Army; DoD; NavyLearning MaterialEngineering Management
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.

EXECUTIVE SUMMARY
5/18/2017 7:47 PM
129 UH 60 Technology Readiness Level TRL Assessment Lessons Learned.ppt
  
Engineering; Test and EvaluationAir Force; Army; DoD; NavyLessons LearnedPM Technical Management
These are lessons learned in completing a Technology Readiness Level (TRL) Assessment for the UH-60M program in support of the Milestone (MS) B acquisition decision process.  There is a related document and spreadsheet example to this located in the Risk Management Resources and References area.
6/26/2017 8:51 AM
7charsDysfunctionalSoftwareProjects.pdf
  
Engineering; Program ManagementDoDLessons LearnedSoftware Development; PM Technical Management
Experience in identifying and evaluating project risks in large-scale software systems acquisition and development programs has led to development of a risk database. This database was analyzed and seven predominant characteristics were identified that provided insight into causes of dysfunctional software projects: failure to apply essential project management practices; unwarranted optimism/unrealistic management expectations; failure to implement effective software processes; premature declarations of victory; lack of program management leadership; untimely decision-making; and lack of proactive risk management.
6/26/2017 8:51 AM
Acquiring and Enforcing the Government s Rights in Technical Data and Computer Software Under Department of Defense Contrac.aspx
  
ReferenceSoftware Development; PM Technical Management
This handbook is designed to provide you with a practical "cradle-to-grave" handbook to acquiring technical data and computer software rights.
6/26/2017 8:57 AM
Anderson NDIA SE Division Meeting 12Apr05.ppt
  
Contracting; Engineering; Information Technology; Program Management; Requirements ManagementDoD; Joint StaffLearning MaterialEngineering Management
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
6/26/2017 9:10 AM
CMMI Institute.aspx
  
ReferenceKitchen Sink; Software Development; PM Technical Management
As part of its mission to transition mature technology to the software community, the SEI has transferred CMMI-related products and activities to the CMMI Institute, a 100%-controlled subsidiary of Carnegie Innovations, Carnegie Mellon University’s technology commercialization enterprise. The CMMI Institute will conduct CMMI training and certification, sponsor conferences and classes, and provide information about CMMI process improvement models and appraisals.
The SEI will continue to pioneer and advance new research in the field of software process management. More information about our current work is available at http://www.sei.cmu.edu/process.
6/27/2017 8:36 AM
Live Fire T E Wavier ADDM Template v1.0.docx
  
Program Management; Test and EvaluationAir ForceExampleAir Force Examples; PM Technical Management; Test and Evaluation Mgmt
A new template was created based on LFT&E statute,  Title 10 U.S.C § 2366, which requires a LFT&E program to include Full Up System Level (FUSL) testing unless a waiver from FUSL is granted with a certification by the Under Secretary of Defense for Acquisition, Technology and Logistics (USD(AT&L)) or the DoD component acquisition executive (CAE) that FUSL testing would be unreasonably expensive and impractical. 
Template
6/27/2017 2:42 PM
Post CDR Report ADDM Template v 2.0.docx
  
EngineeringAir ForceExampleAir Force Examples; PM Technical Management; Engineering Management
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
Guidance:
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.
Template
6/27/2017 2:45 PM
Net Centric Data Strategy ADDM Template v1.1.docx
  
Information TechnologyAir ForceExampleAir Force Examples; PM Technical Management
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: Defense Acquisition Guidebook dated 15 May 2013
ADDM Application link
Guidance:
Make explicit the data that is produced and used by the program’s implemented operations and that is to be shared with the user community.  Provide the associated metadata, and define and document the program’s data models. These requirements are met by performing the following actions. If not completed, indicate the extent to which progress has been made, or provide a plan to meet the requirement.
A new template was created based on  Air Force Program Manager’s Guide for Developing, Processing, and Approving Information Support Plans (ISP), Appendix E
Template
6/27/2017 2:52 PM
Manufacturing Readiness Assessment ADDM Template v 1.2.docx
  
EngineeringAir ForceExampleAir Force Examples; PM Technical Management; Manufacturing Mgmt
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: Manufacturing Readiness Level (MRL) Deskbook dated AUG 2015
ADDM Application link
Manufacturing Readiness Assessment have been designed to manage manufacturing risk in acquisition, while at the same time increasing the ability of the technology development projects to transition new technology to weapon system applications.  The results of a Manufacturing Readiness Assessment are documented in the Manufacturing Readiness Assessment report.
The government program/project office is the primary audience for the report since it forms the bias for managing manufacturing risk. In general, the report establishes a manufacturing maturity baseline that should be used to either create a plan to increase manufacturing readiness/maturity sufficiently to support transition to the next phase of acquisition or to demonstrate that the technology is ready for transition.  The report may also provide information to an MDA determination of whether the level of manufacturing risk supports Milestone approval.
When actual MRLs are compared to target values based on the stage of the life cycle, the report provides a basis for an analysis and assessment of the risks associated with each manufacturing thread. Cost, schedule or performance manufacturing risks that are not resolved must be defined and require manufacturing maturity plans. These plans should include a description of the approach to resolve the risk, cost estimates, resources available, and schedule impacts. The manufacturing maturation plan is normally delivered along with the assessment report. See section 5 of the MRL Deskbook, v2.4, August 2015.
Within this template, enter applicable verbiage in each of the blue-font “click here to enter text” fields, as specified by the accompanying guidance sections.  If the document section is not applicable, label as such and provide a short rationale.
The Manufacturing Readiness Assessment template has been designed to manage manufacturing risk in acquisition, while at the same time increasing the ability of the technology development projects to transition new technology to weapon system applications.  The results of a Manufacturing Readiness Assessment are documented in the Manufacturing Readiness Assessment report.
Template
6/27/2017 2:58 PM
Alternative Live Fire Strategy ADDM Template v1.2.docx
  
Engineering; Program Management; Test and EvaluationAir ForceExampleAir Force Examples; PM Technical Management; Test and Evaluation Mgmt
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: Test & Evaluation Management Guide dated 20 DEC 2012
ADDM Application link
Guidance:
1.         DOT&E/LFT&E developed the following fixed wing aircraft template.  The strategy starts as an Integrated Survivability Assessment Plan.  After discussions with DOT&E/LFT&E, the document is finalized and becomes the Alternative Live Fire Strategy via a cover page change.
2.         The form on the next page is a one page summary of the Integrated Survivability Assessment Plan.  The details are attached to this summary in a narrative that addresses susceptibility (can the platform be hit) and vulnerability (what damage will result).  The narrative is supplemented by a Survivability Threat Test Matrix, and two tables:
      a.         Susceptibility Critical Issue Resolution Matrix (Table 1)
      b.         Vulnerability Critical Issue Resolution Matrix (Table 2)
The narrative is completed by answering a series of questions regarding the survivability of the system.  The template guidance includes recommended methods for verification.  The three matrices supplement this information by providing details of the test methods and procedures that will be used to verify survivability. Not every question will be applicable to every system; answer those that are appropriate.
Describes the detailed test procedures, test conditions, data collection, and analysis processes to be used during the conduct of LFT&E.
BofV
6/27/2017 3:11 PM
dd1494 ADDM Template 042015.pdf
  
Program ManagementAir ForceExampleAir Force Examples; PM Technical Management; Engineering Management
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, http://www.dtic.mil/whs/directives/forms/eforms/dd1494.pdf
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).
Template
6/27/2017 3:28 PM
Criticality Analysis ADDM Template v 1.1.xlsx
  
EngineeringAir ForceExampleAir Force Examples; PM Technical Management; Engineering Management
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
Guidance:
·    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.
 
Template
6/27/2017 3:32 PM
Life Cycle Mission Data Plan ADDM Template v 3.0 758995.doc
  
Life Cycle Logistics; Program ManagementAir ForceExampleAir Force Examples; PM Technical Management; Product Support Mgmt
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 5250.01 dated 22 JAN 2013

ADDM Application link
Guidance:
This template is a guide to support program office planning for IMD and coordination of the plan with stakeholders.  It may be changed/adjusted as it best supports program execution. Program specifics should replace blue italicized sections.
 
Life Cycle Mission Data Plan ADDM Template v 3.0
6/27/2017 3:34 PM
C 5A Galaxy SE Case Study.pdf
  
Engineering; Information Technology; Program Management; Requirements ManagementAir ForceLearning MaterialEngineering Management
EXECUTIVE SUMMARY

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.
6/28/2017 3:30 PM
DAG Chp 1 PM Technical Mmgt Roles Aug 2016.docx
  
Cybersecurity; Engineering; Information Technology; Life Cycle Logistics; Requirements Management; Test and Evaluation; Program ManagementDoDLearning MaterialProgram Management; PM Technical Management; PM Career Center; Training Center
PM's Compendium of Technical Mmgt Roles, Actions and Activities from Chapter 1 of the Defense Acquisition Guidebook (DAG) August 2016.
6/28/2017 9:43 PM
104EXSAM 450 COTS Issues.ppt
  
Engineering; Information TechnologyArmy; DoDPresentationSoftware Development
Definition of COTS and what makes COTS challenging.
7/25/2017 3:30 PM
Section-901-FY-2017-NDAA-Report.pdf
  
General Acquisition; Program ManagementDoDReportProgram Management; PM Acquisition Management; PM Business Management; PM Executive Leadership; PM Policies and Guidance; PM Resources and Tools; PM Technical Management
August 2017 - In Response to Section 901 of the National Defense Authorization Act for Fiscal Year 2017 (Public Law 114 - 328).

The Fiscal Year (FY) 2017 National Defense Authorization Act (NDAA) (Public Law 114-328) contains a provision (Sec. 901) that amends chapter 4 of title 10, United States Code, to establish an Under Secretary of Defense (Research and Engineering) (USD(R&E)), an Under Secretary of
Defense (Acquisition and Sustainment) (USD(A&S)), and a Chief Management Officer (CMO) within the Department of Defense (DoD), effective on February 1, 2018. Section 901 also makes
other modifying and conforming changes, and requires the Secretary of Defense to conduct a review and submit a series of reports to the congressional defense committees on the
organizational and management structure of the Department.
8/2/2017 3:35 PM
DoD Open System Architecture (OSA) Contract Guidebook for Program Managers-version 1.1- June  2013.pdf
  
Program Management; EngineeringDoDLearning MaterialModular Open Systems Approaches; Engineering Management; Program Management
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.
11/1/2017 6:02 PM
Asking the Right Questions at the Right Time-Lessons Learned for Project, Program and Portfolio Managers-20130624.pdf
  
Engineering; Program ManagementDoDLessons LearnedEngineering Management; Portfolio Management; Program Execution
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.
5/2/2018 10:50 AM
Clinger Cohen Act.pdf
  
Contracting; Information Technology; Program ManagementDoD; Joint StaffReferencePM Policies and Guidance; PM Technical Management; Software Development
The Clinger-Cohen Act of 1996 that shapes DoD's and other Federal Agencies' approaches to IT acquisition and management;
- The House of Representatives Report 104-450, National Defense Authorization Act for Fiscal Year 1996, Conference Report, that provides an historical legislative perspective for the Act;
- Title 10, United States Code, Section 2223 that gives additional responsibilities to the DoD CIO and the CIOs of the Military Departments;
- Executive Order 13011, "Federal Information Technology," that provides policy guidance for significantly improving the acquisition and management of IT by implementing the Clinger-Cohen Act and the Paperwork Reduction Act of 1995;
- Secretary of Defense Cohen's Memorandum, "Implementation of Subdivision E of the Clinger-Cohen Act of 1996 (Public Law 104-106)," June 2, 1997, that defines and clarifies how the Act will be implemented in DoD, and the responsibilities of the DoD Chief Information Officer (CIO) vis--vis those of the Military Department CIOs;
- Deputy Secretary of Defense Hamre's Memorandum, "DoD Chief Information Officer Executive Board," March 31, 2000, and DoD CIO Executive Board Charter; and
- Deputy Secretary of Defense Hamre's Memorandum, "DoD Chief Information Officer (CIO) Guidance and Policy Memorandum No. 8-8001 - March 31, 2000 - Global Information Grid," March 31, 2000. 
2/12/2020 8:35 AM
F 111 SE GK Richey.pdf
  
Engineering; Information Technology; Program ManagementAir Force; Army; DoD; NavyLearning MaterialEngineering Management
EXECUTIVE SUMMARY

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.
2/12/2020 8:35 AM
Systems Engineering Plan Guide v90 1 759265.doc
  
EngineeringLearning MaterialEngineering Management
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. 
2/12/2020 8:36 AM
1 - 30Next