NISTIR 7749

Model Based Enterprise

Technical Data Package Requirements

Simon Frechette

Paul Huang

Mark Carlisle
1

NISTIR 7749

Model Based Enterprise

Technical Data Package Requirements

Simon Frechette

Systems Integration Division

Engineering Laboratory

Paul Huang

Department of the Army

Army Research Laboratory

Mark Carlisle

Systems Integration Division

Engineering Laboratory

February 2011

U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, Director
i

Contents

Executive Summary 1

1 Introduction 4

1.1 What is a TDP? 4

1.2 What is Changing? 4

1.3 DoD Engineering, Drawing, and Modeling Working Group (DEDMWG) 5

1.4 MBE/TDP Summit 5

2 Background 6

2.1 Challenge 6

2.2 Workshop 6

3 TDP Workshop Results 9

3.1 Group A – Acquisition 9

3.1.1 Deficiencies or Barriers 9

3.1.2 Vision Statement 15

3.1.3 Issues and Solutions 16

3.2 Group B – Production, Planning, and Design 21

3.2.1 Deficiencies or Barriers 22

3.2.2 Vision Statement 36

3.2.3 Issues and Solutions 37

3.3 Group C – Provisioning, Logistics, and Sustainment 44

3.3.1 Deficiencies or Barriers 46

3.3.2 Vision 52

3.3.3 Issues and Solutions 53

3.4 Group D – Policy Management 56

3.4.1 Deficiencies or Barriers 57

3.4.2 Vision 59

3.4.3 Issues and Solutions 60

4 Full Group Prioritization and Resulting Nuggets 65

4.1 Analysis 68

A-1 Group A. Acquisition Issues and Solutions Table 71

A-2 Group B. Production, Planning, and Design Table 76

A-3 Group C. Provisioning, Logistics, and Sustainment Table 82

A-4 Group D. Policy Management Table 85

A-5 Summit Agenda 90

A-6 Participants 93

A-7 Wiring Diagrams 96
1

Executive Summary

Workshop Summary

The Department of Defense and the National Institute of Standards and Technology held a Model Based 

Enterprise Summit and Technical Data Package (TDP) Workshop December 15-17, 2009 in Gaithersburg, 

MD. The TDP workshop gathered subject matter experts to make recommendations for changes to DoD 

technical data package specifications. These changes are needed to support DoD transition to total 

lifecycle management based on digital models rather than 2D drawings. 

77 subject matter experts from government and industry identified 46 critical issues affecting adoption 

of model based technical data packages during the day and a half workshop. Issues were separated into 

four categories: acquisition, production, sustainment, and policy. The attendees developed 148 

proposed actions needed to address the critical issues. Each of four breakout sessions identified 

solutions and presented them in a final large group setting. The full assembly then prioritized the 

actions in order to provide a basis for a model based TDP implementation roadmap. 

Figure 1. Prioritization of Proposed Activities

Importance of Technical Data

The Technical Data Package delivered with a defense system contains all the engineering data and 

descriptive documentation required to support the system throughout its lifecycle. The information in 

the TDP is initially used to support the operation of the system - provisioning, logistics, training, and 

maintenance. For maintenance operations, production of interactive technical manuals directly from the 

product data has proven to be very effective. Later in the system life, the TDP is used to support repair, 

refit, and re-engineering of the system. The TDP provides the basis for modifying the system and 

supports competitive re-procurement of system components.

A technical data package includes applicable engineering data such as models, drawings, associated lists, 

specifications, standards, quality assurance, performance, and operational requirements. TDP 

completeness varies with each system procurement. Most major defense system support contracts are 

unique. Some systems have been delivered with fairly comprehensive data packages, while others have 

been delivered with very little technical data. In the cases where no technical data is delivered, the 

government must rely on the system prime manufacturer for support. Support provided by prime 

0

5

10

15

20

25

30

35

Priority Ranking 

Activites Proposed to Support Model Based Technical Data Packages

Acquisition

Production, Planning, and Design

Provision, Logistics, and Sustainment

Policy Management
2

contracts may or may not be cost effective and in the case of increased operational tempo, the prime 

contractor may not be willing or may not be able to provide support or critical components in a timely 

manner. In some cases, government personnel have had to resort to reverse-engineering systems 

components in order to manufacture needed replacement parts. This is especially true of orphaned 

systems whose original manufacturers no longer exist.

Supporting advanced defense systems with little or no access to technical data adds significant costs and 

reduces system availability. Over 70% of the lifecycle cost of a system is incurred during the 

maintenance, support, and refit portion of the system lifecycle. Reverse engineering system 

components is a complex and error prone process. Reverse engineered component data and 

manufacturing processes must be completely re-certified prior to production. This process is potentially 

an order of magnitude more expensive than producing a component directly from the original data. 

Robust, accessible technical data is vital for long term system support, but there are barriers to acquiring 

this data.

Barriers to Acquisition of Technical Data

The U.S. Department of Defense (DoD) has recently implemented policies that encourage DoD program 

managers (PMs) to consider a program’s life cycle during initial system acquisition. PMs are encouraged 

to acquire a complete TDP with major system acquisitions and system upgrades. Despite policies that 

stress the importance of technical data, there are several factors that inhibit the acquisition and delivery 

of adequate technical data. Major factors are cost, perceived competitive advantage, data rights, and 

TDP delivery.

TDPs are considered expensive to acquire, which reduces the funding available for the system itself. 

With defense systems, the main concern is system delivery and initial cost control versus reducing 

long term sustainment costs. Program Managers often respond by obtaining only the minimal TDP 

to manage initial costs. 

Technical data is considered a competitive advantage for the manufacturer. Most prime 

manufacturers do not consider it in their best interest to deliver complete technical data packages. 

Most primes would rather “lock in” future business as the only entity capable of providing the 

sustainment support and spare parts for the system. This exposes the government to the risk of the 

sole supplier not having sufficient capacity during critical times in the system’s life-cycle. 

Data rights are sometimes not clearly asserted. Uncertainty about technical data rights - what 

development was paid for by the government and what belongs to the manufacturer – has made 

the acquisition of technical data difficult in the past. The government can clearly assert its rights and 

data requirements in a well understood TDP framework.

Modern technical data package requirements are not sufficiently specified. The Office of the 

Secretary of Defense (OSD), as well as the individual services, have implemented directives that 

require acquisition of technical data, but with little, if any, direction as to what constitutes an 

adequate TDP, its format, or how it must be handled. Currently, nearly all TDPs are based upon 

centuries old methods limited to two-dimension (2D) drawings and associated documentation files. 

Industry, including most small businesses, has adopted a model based enterprise (MBE) approach 

where system data is captured as digital product models (e.g., computer aided design applications) 

and managed in a centralized database.

MBE technology has matured to the point where there is significant opportunity to dramatically improve 

defense systems operations and reduce support costs. By moving from the 2D drawing world into the 

digital 3D model world, the full product description can not only be captured in a digital product model 
3

but the information becomes reusable throughout the system lifecycle. Improved access to data enables 

all manner of automation and cost savings. Industry’s migration to the model based enterprise should 

significantly ease the production of TDPs and make acquisition of adequate documentation more viable 

– but only if DoD TDP specifications are complete, well understood, and developed in partnership with 

industry. 

Recommended Actions

Proposed actions from the workshop breakout sessions were consolidated and grouped into four 

distinct areas of need:

 Actions needed to completely define DoD TDP content requirements and delivery requirements.

 Actions needed to improve direction, instructions, and policy to better articulate the necessity 

for acquiring adequate technical data.

 Improvements in technology needed to fully enable more efficient use of the 3D product 

description.

 Actions needed to improve acquisition processes and provide more uniform contract language.

Workshop actions were formulated to provide a basis to move forward with planning, support, and 

execution of TDP-related projects. The central action identified by the workshop was the revision of MILSTDs and other specifications to support model based technical data packages. Even when prime 

contractors are willing to provide system technical data, there are significant questions regarding how 

the data will be transmitted, in what format, and how the government will organize this data in its own 

data management systems. 

The top actions in each category are listed below.

TDP Definition for MBE

 Create a comprehensive description of the data required in a TDP.

 Define requirements for completely annotated models.

 Revise current MIL-STDs and related documents to consolidate requirements for distinct TDP 

levels and 3D model based product representations.

Acquisition Policies and Directives

 Mandate participation of all stakeholders and subject matter experts at Data Call and 

throughout the program, including IP attorneys experienced in data acquisition contractual 

issues.

 Make accountability of decisions made by PM extend beyond tenure for acquisition, such as 

practiced by the UK Defense Department.

 Revisit DODI 5000.02 to better address TDP policy.

Technology Development

 Identify acceptable native, neutral, and viewable data formats and ensure that standards are in 

place to support these formats.

 Identify TDP repository requirements and repository architecture options.

 Develop a validated translation process for delivering TDP information to the government and 

establish independent TDP validation processes.

Acquisition Workforce and Processes

 Establish training, certification, and knowledge capture to address declining workforce issues for 

acquisition data management professionals.

 Expand use of automated acquisition and contract development tools, i.e., SYSPARS & SMART-T.

 Ensure that transportable, shareable, usable, and clearly identifiable data formats are 

established at Data Call.
4

1 Introduction

1.1 What is a Technical Data Package?

A technical data package (TDP) contains a technical description of an item adequate for supporting an 

acquisition strategy, production, engineering, and logistics support. The description defines the required 

design configuration or performance requirements, and procedures required to ensure adequacy of 

item performance. It consists of applicable technical data such as models, drawings, associated lists, 

specifications, standards, and performance requirements.1, 2, 3Lastly, as echoed by Ric Norton’s large 

group presentation “Contracting for Data; a DLIS/DLA Perspective” - a Technical Data Package (TDP) 

should provide not only sufficient data to procure “up front” but re-procure later in the product 

lifecycle.

1.2 What is Changing?

We now have the opportunity to advance the state of product definition and its use. By moving from the 

2D printed world into the 3D digital universe, the full product description is not only archived in a digital 

product model but the information becomes reusable without manual reentry. Figure 2 offers an 

example of the kind of clear graphic that can be easily and automatically extracted from a 3D computer 

model of an assembly. 

The computer sensible information enables automation 

that leads to both speed and accuracy of data 

manipulation. Development of the Model Based 

Enterprise (MBE) is causing this technology to have

tremendous value to the production of TDPs. Taking full 

advantage of the 3D product definition that an MBE will 

enable will be met sooner and with more coherent 

results if the steps required for fully effective use in TDPs 

are identified and then addressed in the appropriate 

order and timeliness.

 

1

 MIL-STD-31000 found at https://assist.daps.dla.mil/online/start/

2

The acronym ‘TDP’ for Technical Data Package is NOT found in Joint Publication 1-02, DoD Dictionary of Military 

and Associated Terms, as amended through 31October 2009 located at 

http://www.dtic.mil/doctrine/dod_dictionary/

3

From DoD Replenishment Parts Purchase or Borrow (DoD RPPOB) Program per Department of Defense 

INSTRUCTION NUMBER 4140.57, May 30, 2008 at http://www.dtic.mil/whs/directives/corres/pdf/414057p.pdf

Figure 1 Example of an automated 

drawing generated by a 3D model
5

1.3 DoD Engineering, Drawing, and Modeling Working Group 

(DEDMWG)

The DEDMWG, currently co-chaired by Paul Huang (Army) and Ric Norton (DLIS), involves participation 

by individuals from the DoD Services plus NIST, Coast Guard, DOE, and interested industrial and 

academia personnel. The group works in two areas:

 Looking for methods to encourage acquisition managers to require an adequate TDP, and

 Modifying the definition of an adequate TDP to anticipate and/or encourage the use of 3D 

product models in TDP packages.

The DoD Engineering, Drawing, and Modeling Working 

Group (DEDMWG) charter calls for the group to lead 

efforts for technical coordination and policy guidance 

on technical data for product design, analysis, 

simulation, manufacturing, provisioning and other 

product lifecycle management functions. This includes 

guidance on technical data requirements for computeraided design, engineering, manufacturing, data tools 

for archival and retrieval, and related applications for 

total product lifecycle management.

This group’s current accomplishments include 

highlighting the need to focus on understanding data 

rights and how to use them in the acquisition process, 

highlighting the benefits of a completely adequate TDP, 

and are actively seeking support for developing 

improved training for acquisition managers in 

collaboration with Defense Acquisition University.

Their main vehicle used to modify the requirements for 

a TDP has been the creation of MIL-STD-31000 (to include several features compatible with a 3D product 

description’s use (Figure 5).

1.4 MBE/TDP Summit

To further advance this work, the MBE/TDP Summit was designed to present current efforts dealing 

with MBE selected applications. Subject matter experts could then share their expertise on what should 

happen next with respect to TDPs in a secondary workshop.

On December 15-17th at the NIST facilities in Gaithersburg, MD, the DoD sponsored the Model Based 

Enterprise & Technical Data Package Summit.

On December 15th and the first half of December 16th the summit offered 18 presentations of selected 

Model Based Enterprise (MBE) efforts where models have been applied successfully in new ways to 

benefit our Warfighters. Participates contributed in a workshop (facilitated by IMTI4) to gather focused 

input from on what data a Technical Data Package (TDP) should contain when embodied in a 3D Model 

definition. This report focuses on the findings of the workshop portion of the Summit.

 

4

IMTI - Integrated Manufacturing Technology Initiative is a non-for-profit Technology Management company 

headquartered in Knoxville, TN

Figure 2. MIL-STD-31000 Revised

by the DEDMWG.
6

2 Background

The evolving model-based product realization process will produce a 3D product definition as a natural 

course of producing the product. This is because in a model based enterprise the execution of product 

and process models to realize the product will naturally produce a virtual product as well. Companies 

are beginning to realize that integrating the various models with collaborating applications that assist 

the various functions throughout the enterprise can provide untold benefits not only to the enterprise

but to all downstream customers. This includes those needing a TDP to enable provisioning, provide 

logistics, and sustain the real product. One recently revealed example documented time and cost 

savings of 25 to 1 when model-based techniques are compared to conventional engineering practice. 

Further, savings and time compression of a factor of 5 were found in the change management process. 

5

2.1 Challenge

Technical information about a defense acquisition is required as part of the acquisition process,

especially for major systems. According to Department of Defense Instruction DODI 5000.02 program 

managers for ACAT I and II programs,

6

regardless of planned sustainment approach, shall assess the 

long-term technical data needs of their systems, and reflect that assessment in a Data Management 

Strategy (DMS). The DMS shall (1) be integrated with other life-cycle sustainment planning and included 

in the acquisition strategy; (2) assess the data required to design, manufacture, and sustain the system, 

as well as to support re-competition for production, sustainment, or upgrades; and (3) address the 

merits of including a priced contract option for the future delivery of technical data and intellectual 

property rights not acquired upon initial contract award considering the contractor’s responsibility to 

verify any assertion of restricted use and release of data.

7

The DFARS8further strengthen this requirement by stipulating that, for major acquisitions, the 

acquisition manager shall establish acquisition strategies that provide for the TDP. These strategies are

usually embodied in a technical data package and associated license rights needed to sustain those 

systems and subsystems over their life cycle.9

Containing sufficient information to sustain equipment throughout its useful life-cycle places stiff 

requirements on the TDP that should be acquired with each piece of major equipment. Current TDPs 

often fall short in providing the needed information for product use, provisioning, repair, and 

modification. The challenge is to use the emerging MBE to enrich the TDP to its fully required level of 

detail in as automated way as possible.

2.2 Workshop

During the workshop portion of this summit, representatives from government (primarily DoD), 

industry, and academia worked together to answer questions that will lead to the most effective 

 

5

BAE Systems U.S. Combat Systems Benchmarking Notes. October 20, 2009, IMTI2010001

6

Acquisition Categories costing greater than approximately $140M for research, development, and evaluation or 

procurement greater than $300M in FY1996 constant dollars

7

Department of Defense Instruction No. 5000.02 (December 8, 2008)

8

Defense Federal Acquisition Regulation Supplement (DFARS)

9

DFARS SubPart 207.1 – Acquisition Plans (S-70)(1)(ii)
7

investment strategy required to advance the technology, the manufacturing readiness, and the state of 

the industry. By reviewing the current state, envisioning the perfect future, articulating the issues, and 

proposing a suite of solutions for their resolution the participants outlined a plan for moving forward. 

The results from this workshop, presented herein, will lead to the strategic investments needed to 

achieve the needed TDP maturation. 

To facilitate the discussion the summit participants were divided themselves into four groups to discuss 

the topic from different viewpoints. The four subtopic areas were: 

A. Acquisition;

B. Production, Planning, and Design(PP&D);

C. Provisioning, Logistics, & Sustainment (PL&S); and

D. Policy Management.

The functional diagram for this structure is provided in Figure 3. 

Figure 3 Functional diagram for the TDP Workshop

Following a brief overview of the workshop methodology and using the breakdown in Figure 3 the large 

group divided into four small groups. The facilitator in each topic group guided the discussion and 

assured that all had an opportunity to contribute. A scribe in each group captured the thoughts in a predeveloped template that IMTI used to keep the groups focused. 

The first step in the workshop defines the Current State of Practice for each subject element in the 

functional model. While this included identification of emerging best practices, the primary objective of 

this step was to identify deficiencies and barriers that must be overcome on the way to success.

The next step defined the Future Vision for each element. The Vision step, simply put, answers the 

question, “If this function were perfect, what would its attributes be?”

The process core is the articulation of current Issues, followed by the actions (Solutions) needed to 

realize the vision. The facilitator led the group through a structured process of information gathering. 

The shortness of this workshop necessitated keeping it more strategic and less tactical. 
8

The final step in the workshop process was the prioritization of the solutions, i.e., determination of the 

recurring compelling themes that require immediate attention. IMTI accomplished this by developing 

group consensus in selecting the “critical solutions” for priority emphasis. 
9

3 TDP Workshop Results

This section presents the developments in each of the four individual small groups. Although based 

upon the raw notes10 they are somewhat augmented by the IMTI team to this improved articulation of 

the findings.

3.1 Group A – Acquisition 

A TDP must be based on the Government's need for technical data required to support the acquisition 

and life cycle support strategies for the product being documented. The Government's need for 

technical data varies greatly from program to program. It may also be required at various stages of the 

acquisition process ranging from conceptual design data for concept evaluation to a complete set of 

detailed design data for re-procurement of items essentially identical to the original item. 

TDPs define the physical and functional characteristics of the accepted configuration of the item and its 

subordinate assemblies, subassemblies, and parts thereof. TDP levels, types, elements, and TDP data 

management products are currently identified in accordance with MIL-STD-31000 and applicable data 

item descriptions. These items are tailored and imposed through the TDP Option Selection Worksheet

and Contract Data Requirements Lists (CDRL) in contracts, purchase orders, and Military 

Interdepartmental Procurement Requests (MIPRs).

MIL-STD-31000 specifies two types of TDPs: Type 2D and Type 3D. This workshop focused on Type 3D. 

The point of this sub-topic was to capture elements that the MIL-STD-31000 fails to address and that a 

3D model should be able to provide. 

To receive an adequate technical data package as part of the acquisition process, we must first specify it 

as a contract deliverable. Too often, due to poorly defined requirements especially for 3D product data, 

the TDP provided with an item proves inadequate for provisioning and sustaining an item throughout 

the useful portion of its life cycle. 

This section of the workshop will enable people who need to specify or deliver a TDP to express what 

changes they feel are required to specify the TDP requirements in the contract. 

3.1.1 Deficiencies or Barriers 

A variety of acquisition activities are required to support defense systems programs from their inception 

to retirement of the program. Inclusion of Technical Data Packages (TDPs) with procured systems and 

products is critical to success at each stage. During initial development of a system, the technical data 

will help define and evaluate the conceptual design while developing the ultimate system. During 

system use (which may be decades later in many cases), detailed specification data must be used in 

acquisition of suitable spares and replacement parts, and the acquired parts and systems must be fully 

documented to assure successful performance and maintenance/support capability. TDPs are especially 

critical when technology changes or system modifications occur, to enable configuration management 

of deployed systems. Coding various components and commodities into catalogs that enable acquisition 

of standard components for replacement parts or to create new products and systems, an often 

overlooked set of activities, lends further dependability and efficiency to DoD’s acquisition activities. 

Here too, the presence of accurate TDPs for every system is of critical importance.

 

10

 Each group raw notes are available at http://www.mel.nist.gov/div826/msid/sima/mbe/2009.html.
10

Increasing attention is being placed on the TDP because lack of adequate technical information on 

operational systems not only impacts the cost, manufacture, and delivery of defense systems, but also 

has an ongoing impact on the Warfighter and the ability to adequately repair and operate the 

equipment. However, there are a number of barriers or deficiencies that limit realization of the TDP’s 

benefits. 

The general lack of up-to-date, complete guidance and standards for acquisitions is one widespread 

problem with the delivery of TDPs with acquisitions. When there is no guidance or only out-of-date or 

ambiguous guidance that doesn’t address digital data or 3D requirements, then it is not practical to 

expect compliance with the existing guidance or consistent data with which to operate. Furthermore, 

the sets of guidance and related practices are inconsistent across the services and across locations 

within some services. There are some good examples of TDP requirements and guidance for preparing 

and delivering good TDP data, including 3D data and models if and when used by the vendor (e.g. the 

Navy and Warner Robins Air Force examples of best practice in the Current State table below). These 

examples can serve as initial models for widespread use across the services.

A serious problem underlying DoD contracting and program management is the low priority given to 

TDP acquisition at the time the contract is being developed and thus it becomes a convenient item to 

negotiate away. The problem is not just with contract officers. Program managers often fail to see the 

value of the technical data defining the system, consider it optional, and need strong justification to 

insist on the delivery of the TDP along with the procured system. Program managers seem to have an 

erroneously high conception of the actual costs to acquire TDP. Indeed, the negative impact of 

acquisition decisions concerning the TDP is often not felt for some years, long after the PM has gone on 

to another assignment, so there are currently few consequences for bad TDP-related decisions.

A large part of the acquisition activity for any program is re-procurement of spares and replacement 

parts throughout the system’s life cycle. Failure to have accurate and complete technical data to 

generate specs limits the program manager’s options for re-procurement and impairs the support of the 

system. Contracted data rights are also an issue, particularly if vendors use technology already 

developed for the commercial market. Even if a TDP was specified and delivered, the vendor may still 

claim intellectual property and limit the right to use that delivered data for subsequent procurements, 

effectively limiting follow-on procurements to sole source. These issues must be resolved and 

contracted at the beginning of system acquisition. Another limitation that must be addressed is that 

vendors can claim an initial list of limited rights to TDP data, but they sometimes come back later and 

add to the limited rights list. The government must adjudicate such OEM assertions of proprietary data, 

especially since the burden of proof is on the vendors (since NDAA 07).

TDP delivery is needed not just at the end of development, but should be at regular intervals during high 

development phases, with changes and updates reflected more quickly after deviations from the initial 

baseline product.

There has been much discussion of the cost of complete and effective TDP data and it is not clear 

whether separate pricing of the TDP is wise. Perhaps the requirement should be simply to deliver all 

data, models, and process definitions used to create the system, particularly if they were developed as 

government-paid activities. Procurements will typically require delivery of technical manuals for a 

system, but providing high quality and up-to-date information during years of system use requires 

ongoing access to a complete and regularly updated TDP.

The ability to adequately specify the TDP requirements for a defense system can be quite challenging, 

and a key deficiency is limited perspective on the needs for the TDP. The Data Call for the system

should all stakeholders and included all lifecycle perspectives. Designers and acquisition staff are not 
11

sufficient; manufacturing partners, IP lawyers, maintenance and logistics staff, support/training staff, 

and user representatives must all be included.

Data needs to be consistently validated. We are losing expertise needed to validate data, especially 3D 

and model-based data. There is a risk in waiting to get the data and in waiting (perhaps for years) to use 

the data and only then seeing whether it is valid data for the system. Some services are using a variety 

of validation reviews, mostly paper-based, but a complete solutions requires a DoD-wide systematic 

approach and automated means of validation.

A final, related challenge is the declining resource base. DoD has lost its ability to do a good job at 

defining and procuring TDPs. There is insufficient training and few recruits due to lack of recognition of 

the area as a valued profession. The few remaining experts cannot cover the current acquisition 

workload and there is concern that there may not be enough remaining expertise to train a new, 

replacement workforce knowledgeable in TDP issues.

Table 1 contains the complete set of points made by the Acquisitions group concerning the Current 

State of TDP acquisition

Table 1. Current state table for Acquisition.

Current State of TDP Acquisition

Deficiencies or Barriers Emerging Best Practice

Guidance and Standards

 Lack of technical data impacts Warfighter daily; 

even as a safety issue. Data lacking to adequately 

repair/operate equipment, etc.

 Key TDP acquisition guidance/standards- Out of 

date; not complete; non-compliance; doesn’t deal 

with 3D

o Mil Std 31000 just released

o 5000.02 – guidance under which operate

o DoD 5010.12-M (Manual)– out of date; not 

being complied with; doesn’t deal with 3D; 

acquisition of any type of data; wasn’t 

intended for digital data

 Verbiage of guidance is ambiguous and too 

general; 

 Operations and Procedure Manual for 

Contractor Prepared Data – TMIS 

Technical Manual Information System 

SL150-AA-PRO-010/DMP Rev 2 01Jun09 

has latest guidance for developing 

contractor prepared data; Navy 

ownership; joint document – all services 

have access;

 Army TARDEC requiring 3D data

 When successful getting requirements in 

contract, will get good data.

Contracting and Program Management

 Acquisition of adequate TDP lacking; negotiated 

away in Contract/Program office. PM office allows 

deletions of requirements; OEMs not incentivized 

to sell DoD the data and the loss in contracting is 

due to their ‘war of attrition’ w/KOs. 

 Policy lacks emphasis on TDPs; Program manager 

should define; services do differently; 

programming officer has many ways to evade 

acquiring TDP;

 Warner Robins AF has stringent data 

requirements; submit a sample of digital 

data in native, neutral, viewable formats. 

Engineers review; if don’t meet 

requirements then vendor will do over.

 AF has full tech data validation review, 

but without first article manufacturing

 Expeditionary Combat Support System –

ECSS; AF currently in process; other 
12

Current State of TDP Acquisition

Deficiencies or Barriers Emerging Best Practice

 Too often, PMs feel that buying the TDP is 

optional and must be justified.

 Haven’t defined TDP up-front; need to support 

requirements.

 Have good data requirements but get tailored out 

of contract.

 PMs don’t know what they want, they ask 

technical people for TDP requirements when PM 

cannot define product.

 Have to predict data requirements for TDP

 Needs to be procured on each contract; not 

procuring TDP takes away your options.

 Large part of business is re-procurement – and we 

don’t have technical data to generate specs with

 Contractors say they will support product for 10 

years and data is not contracted; will give TDP to 

satisfy intent of specs; will deliver tech manuals 

that are loosely defined; government ends up 

with no data and contractor support people 

ended up with no data. 

 Inconsistent/in-complete/untimely delivery of 

data. Product Baseline is established at end of 

development phase. Data constantly changing 

because in production; during high development 

phases need interim delivery; contract should 

require that any deviation from baseline then 

changes and updates should be incorporated into 

TDP and not necessarily wait until end of 

production. 

 Incentivize PMs: Impact of Acquisition decisions 

is often not felt for 10 years and the PM has long 

gone to another assignment. So, no consequences 

to him.

 Need to ‘predict’ what tech data you will need (a 

priori) 

 Very difficult to do in advance.....should the 

process be a series of data calls across the 

early phases of the Acquisition Lifecycle 

and finalize in DMS? 

 Need to be able to specify TDP later in the 

life cycle

services have similar efforts

Visibility of Costs
13

Current State of TDP Acquisition

Deficiencies or Barriers Emerging Best Practice

 Engineering data is no longer separately priced 

the price of the TDP and the tech manuals is 

included in the hardware cost; don’t know what 

drawings cost or models cost. 

 Section in DOD-5010.1211 clearly defines that we 

need the vendor to generate to do our work.

 Vendor generates TDP data to meet contract 

specifications. If government paid to generate 

that TDP data, then government should have 

rights to data.

Impact of Non-Compliance

 Impact of lack of TDP realized too late; no 

consequences for non-compliance 

 Emphasis is on procurement of tech manuals; but 

tech manuals depend on a completeness of TDP.

 PMs and Acquisitions don’t put emphasis on 

engineering data;

Data Call

 Data Call must include all stake holders, including 

Acquisitions; to hold accountable for TDP 

requirement.

Resources & Support

 Acquisition support for TDP has diminished 

(personnel, support, $). 

 Leadership doesn’t always support/understand 

the importance of acquisition of TDP.

 Funding constraints (acquisition as a whole)

 Gate keeper function in acquisition service; no 

longer have expertise to do it well

 DoD has lost the ability to do a good job on TDPs:

 Not emphasized or professionalized DM

 Lack of training/education for DM career field

 Lack of career field and progression; 

 If we hire a boatload of DMs there may not be 

enough expertise left to train them 

 There are not enough conversations about issues 

across DoD

 DoD is losing the level of expertise needed to 

 

11

 DOD-5010.12L Acquisition Management Systems and Data Requirements Control. List (AMSDL)
14

Current State of TDP Acquisition

Deficiencies or Barriers Emerging Best Practice

train new resources in TDP acquisition

Data Rights

 Data Rights – you can get everything you specified 

but still not have entitled rights to use it; can buy 

data but can’t use it for procurement purposes; 

restricted to sole source procurement. (IP issues)

 At beginning of acquisition it is the best time to 

procure data and rights to data.

 Vendors may have commercial equivalent and 

therefore allow only limited rights; have clear cut 

rights only if government paid for development. 

Government should have unlimited rights to any 

modifications to the commercial equivalent 

funded by the government; typically government 

doesn’t pursue data rights for modifications. 

Misinterpretations of DFARS clauses cause loopholes – need IP enforcements to close loop-hole.

 DFARS requirement for offerors to state their 

data rights claims (claim limited rights early on) 

but they can come back later and add to the 

limited rights list; and government typically 

doesn’t challenge.

 Legal issues: 

We don’t adjudicate OEM assertions of proprietary or 

other restrictions even though the burden of proof is 

on them (since NDAA 0712)

Contract Officers (KO’s) don’t negotiate hard 

w/contractors—may need a ‘game plan’ or other 

tools 

Validation

 We do not consistently validate data and we are 

losing expertise to validate 3Ds; don’t know how 

good the 2D data is until try to use it so how can 

we validate/know MBE data (e.g. to build a test 

article); there is a risk in waiting to get the data 

and waiting to use the data

 In Process Review (IPR) not being accomplished; 

IPR for tech manuals and separate IPR for tech 

data.

 

12

 National Defense Authorization Act (NDAA) for Fiscal Year 2007
15

Current State of TDP Acquisition

Deficiencies or Barriers Emerging Best Practice

 Delivery and Acceptance of data ‘deliveries’ 

(whether by access or otherwise) how do we 

validate? Do we have the expertise to validate it? 

 Long lag time in applying the data delivered, so 

true validation may be long after we can fix it.

 How to know if TDP is actual representation of 

vendor’s existing data.

 If can’t solve issues for 2D data then how can we 

solve for 3D MBE data?

 No systematic processes or validation tools for 2D 

or 3D MBE.

3.1.2 Vision Statement

In the future, a well-established and enforced DoD Acquisition Process will 

require delivery of the Technical Data package (TDP, as defined by an 

updated and complete MIL-STD-31000) along with the physical product. 

The model-based data will be received in both native and neutral format

and will be easily viewable. There will be a systematic process to validate 

TDPs ensuring that what has been delivered to government customers 

and within government entities is a complete and accurate reflection of 

the vendor’s underlying models and data. This implies that all product 

data and data exchange systems are interoperable and communicate 

without error.

All stakeholders will be involved early in the acquisition process (Data Call); with requirements easily 

defined and inserted into Contracts, CDRLs, DIDs, and SOWs; and tailored tools that aid the call-out of 

relevant requirement clauses of lengthy standards documents. As a result, the TDPs delivered with initial 

procurements will be sufficient to support economical re-procurement.

In a paradigm shift from earlier days, the Program Manager and Contract Officers will have to justify (or 

get a waiver for) not purchasing a full or complete TDP/PDD (Product Definition Data) instead of 

considering the TDP to be an optional item that may be yielded in negotiations. 

Other elements of the Vision:

 The government will have unlimited data rights to portions of systems developed under government 

contract, restricted rights to contractor-developed portions, and adjudicating rights in data claims 

assertions.

 Incentive programs will be in place to reward or recognize Contractors who consistently provide full 

TDPs. Significant penalties will result if PM and Contractor fail to acquire/deliver TDP.

 The TDP and other engineering data are consistently funded and delivered, whether separately 

priced or automatically included in DoD procurements. This data includes drawings, models, and 

source data for technical manuals.
16

 No item shall be stock listed without adequate engineering data (the TDP including form, fit, 

function, and interface).

 Data Management personnel in Acquisitions will enjoy professional status, with enhanced career 

options including training and certifications.

 All TDP data will reside in a common, federated DoD data repository with appropriate access and 

security provisions.

3.1.3 Issues and Solutions 

The Acquisition Team identified eleven major Issues or challenges for acquisitions dealing with TDPs. 

The complete table of Issues and all solutions generated is shown in Appendix A-1. The Issues and their 

high-priority solutions are discussed in this section, followed by the team’s Consolidated Top Ten 

solutions that were presented at the end of the workshop.

 There is limited enforcement of existing DFARS, e.g. the requirement for data to be shown as 

separately priced from hardware (e.g. TDP/TM). The problem is not so much that new regulations 

are needed; it is that compliance to existing regulations should be enforced, and perhaps some 

updating where needed. 

 There is limited enforcement of existing DFARS, e.g. the requirement for data to be shown as 

separately priced from hardware (e.g. TDP/TM). The problem is not so much that new regulations 

are needed; it is that compliance to existing regulations should be enforced, and perhaps some 

updating where needed. 

 There is a diminishing supply of TDP knowledge/expertise for Technical Data Management and other 

stakeholders. This relates to the diminishing supply of staff discussed in the previous issue, but here 

the focus is on the actual knowledge required for successful acquisition and use of technical data 

packages. Some Acquisition Data Managers feel that DoD no longer has the expertise to do a good 

job on TDPs. 

 There is a lack of accountability and enforcement by Contracting Officers (KOs) and Program 

Managers (PMs) for TDPs. The length of acquisition cycle exceeds the length of PM involvement. The 

typical term in office for a PM is two years; this tends to encourage short-term decisions. Even if the 

acquisition is completed, the impact of a lack of TDP data is often realized only years later, and there 

are no consequences for those who failed to ensure TDP delivery as part of the acquisition. 

 There is a failure to include all stakeholders involved in a defense system when establishing 

requirements for TDPs. All the groups that produce, use and maintain the systems should be 

involved, including an IP attorney experienced in data acquisition issues. The group must assure that 

the TDP delivered contains all the data and information needed for support, maintenance, reprocurement, etc. throughout the program. 

 Decisions related to Contracted Logistic Support (CLS) or PBL; this argument is too often used to 

remove the TDP requirement in early procurements. Then later modifications result in custom 

versions. There are often no defined exit strategies in contract when previous decisions are altered –

in these cases, the TDP decisions must also be altered. 

 Standards are not concise and complete. There is a lack of clear guidance for obtaining/navigating 

standards. MIL-STD-31000 has too many options/disconnects and opportunities for special 

procurement items (e.g., DIDs – special, commercial, developmental, tooling, etc). As an example, 

when completing form DD-1423, we need to know where to find appropriate requirements. 
17

 Current TDP practices and decisions result in increased vendor dependence and ever increasing

costs. Without the TDP, the government is unable to adequately support its systems or re-procure 

replacement parts. The result is inability to use open procurements and get cost competition. 

 Lack of standard delivered TDP formats and interfaces causes excess cost and complexity. The 

government should receive all information on delivered systems in a neutral technical format and an 

easily viewable format accessible to all parties, whatever tools they are using. The vendor should 

also deliver all data and models in the format native to their tools, thus assuring in case of 

translation data loss that all possible data is retrievable. High priority solution called for:

 We don’t adjudicate OEM assertions of proprietary or other data rights restrictions even though the 

burden of proof is on the OEM (since NDAA 07). Sometimes vendors come back later and put 

additional information to the limited right list and the government doesn’t challenge them. 

 We have no systematic processes or validation tools for 2D or 3D Model-Based Data (MBD). We 

don’t know have good the provided data is until we try to use it (perhaps much later) to build a test 

article or re-procure replacement systems or parts. We don’t have sufficient expertise to validate 

whether the vendor is providing the actual data and models that they were using to develop the 

procured systems. 

These 11 issues were then modified for clarity, prioritized, and their titles shortened somewhat to 

identify eleven major issues that need attention in producing and managing the TDP. The issues and 

their solutions are documented below. The complete table of issues and all solutions generated is 

provided in Appendix A-1. The issues and their high-priority solutions are discussed in this section, 

followed by the team’s consolidated Top Solutions that were presented at the end of the workshop.

Section Format

A.x Issue

A.x.y Solution

A.1 Limited enforcement of DFARS, e.g. requirement for separately priced data from hardware (e.g. 

TDP/TM).

A.1.1 Establish a check-list at project start-up itemizing established contract requirements for 

data and data rights, and have it signed by contractor that they agree.

A.1.2 Periodic mandatory compliance and verification through out the life-cycle. 

A.1.3 Add performance against project check-list to CPARS check-list. Allow OEM to correct 

non-compliance.

A.1.4 Report to GAO/IG for enforcement of DFARS clause (rights of data, separate price of 

data).

A.1.5 Require a General Officer signature when out of compliance.

A.1.6 System that assists navigation to specific DFARS clauses, not just title and number.

A.1.7 Include as a stakeholder an IP Attorney experienced in data acquisition contractual 

issues.

A.2 Lack of career path and training for Acquisition Data Management personnel (includes 

Engineering Data Management officers) and other stakeholders for the understanding and 

establishment of TDP requirements. 
18

A.2.1 Establish a cross-functional DoD/Engineering Data Management working group to offer 

training, identify training resources, bring awareness, brainstorm, and encourage 

standardization across DoD; group should meet at least semi-annually.

A.2.2 Promote awareness and communicate via DAU DM Community of Practice. 

https://acc.dau.mil/dm

A.2.3 Publicize “horror stories” and exemplars showing the cost of ineffective TDP acquisitions 

practices, to increase awareness of the values and benefits of increased capability and 

redirection of cost. Raise awareness/make visible GAO reports concerning TDP impact.

A.2.4 Establish a career field and multi-level certification criteria in DAU for Acquisition Data 

Management professionals.

A.2.5 Establish and maintain capability inventory showing current and projected levels of 

expertise in Acquisition Data Management.

A.2.6 Perform a Desktop Study to assess job requirements and staffing needed to effectively 

perform Acquisition Data Management. Use results to both classify and determine 

staffing requirements.

A.3 Diminishing supply of TDP knowledge/expertise for Technical Data Management and other 

stakeholders.

A.3.1 Establish a searchable knowledge base repository with links to standards, regulations, 

policies, directives, instructions, and guidance, and with an intuitive interface 

customizable to the user’s needs. This may be an extension of existing tools.

A.3.2 Establish funding and identify expertise between services to develop and implement an 

automated tool to assist the acquisition of TDPs.

A.3.3 Reconvene an OSD advisory group to identify and promote critical needs and to create a 

uniform standard for conducting business for TDPs requirements. 

A.3.4 Establish a system to capture and disseminate the knowledge and expertise of existing 

Acquisition Data Management professionals.

A.4 Lack of accountability and enforcement by Contracting Officers (KO) and PMs for TDPs. The 

length of acquisition cycle exceeds the length of PM involvement (PM in office for 2 years; 

makes short-term decisions).

A.4.1 Establish a governance structure to clearly define decisions needed and authorities to 

make them and verify/document that they have been made.

A.4.2 Accountability for acquisition decisions made by PM that extends beyond his/her tenure 

(investigate U.K. example).

A.5 Lack of all stakeholder involvement in establishing requirements for TDPs

A.5.1 Mandated participation of all stakeholders/SMEs at Data Call and throughout program. 

A.5.2 Engineering Management Data plan identifies all stakeholders.

A.5.3 Include as a stakeholder an IP Attorney experienced in data acquisition contractual 

issues.

A.6 Decisions related to Contracted Logistic Support (CLS) or PBL; argument too often used to 

remove TDP requirement in early procurements. Later modifications result in custom versions. 
19

No defined exit strategies in contract when previous decisions are altered – must also alter TDP 

decisions.

A.6.1 At Data Call, establish requirement for the exit strategy in contract, i.e. data access at 

scheduled intervals with clearly defined physical delivery requirements.

A.6.2 Establish requirements for data in specified formats in SOW/CDRL regardless of ACAT 

category.

A.7 Standards are not concise and complete; lack of guidance for obtaining/navigating standards. 

MIL-STD-31000 has too many options/disconnects opportunities for special procurement items 

(e.g. DIDs – special, commercial, developmental, tooling, etc). For example, completion of DD1423; need to know where to go to get appropriate requirements.

A.7.1 Revise MIL-STD-31000 to consolidate requirements for the three TDP levels currently 

defined as separate (conceptual, developmental, and production)

A.7.2 Expand SYSPARS to incorporate an automated tool to assist developing TDP 

requirements (CDRL, SOWs, worksheets)

A.7.3 Create a standards knowledge base for navigating and linking standards and other 

relevant guidance. 

A.8 Current TDP practices and decisions result in increased vendor dependence and ever increasing 

costs.

A.8.1 Apply TDP requirements and evaluate all related decisions to make sure contractor 

dependence is not increased. Do this early and maintain throughout contract.

A.8.2 Establish metrics to represent the level of contractor dependency in an acquisition, 

including the ability to track changes to TDP requirements.

A.9 Lack of standard delivered TDP formats and interfaces causes excess cost and complexity.

A.9.1 Require native, neutral, and viewable formats for the entire supply chain. Ensure that 

transportable, shareable, usable, clearly identifiable formats are established at Data 

Call.

A.9.2 Standardize metadata requirements within the TDP across DoD.

A.10 We don’t adjudicate OEM assertions of proprietary or other data rights restrictions even though 

the burden of proof is on the OEM (since NDAA 07).

A.10.1 Require all programs to adjudicate and validate all of contractor data rights assertions. It 

is a DFARS requirement today, but seen as an option.

A.11 No systematic processes/validation tools for 2D or 3D/MBD.

A.11.1 Update 20-year old guidance data.

A.11.2 Use DAU DMCoP group to identify and share Best Practices within DoD.

A.11.3 Develop a formal verification/validation process used by all DoD entities.

Acquisition team Balloted Prioritized Solutions:

The acquisition team felt that a merging of a number of these solutions listed above was appropriate for 

the final balloting. This lead to the following list of the Acquisition Team’s consolidated top ten solutions 

as they were presented on the ballot for voting at the end of the workshop.
20

A.1.1: Establish a check-list of data requirements at Data Call, itemizing established contract 

requirements for data in specified formats and including data rights and the exit strategy, with 

clearly defined physical delivery requirements [also includes A.6.1 & A.6.2].

A.5.1: Mandated participation of all stakeholders/SMEs at Data Call and throughout program, including 

an IP Attorney experienced in data acquisition contractual issues [also includes A.1.7 & A.5.3].

A.7.1: Revise MIL-STD-31000 to consolidate requirements for the three TDP levels currently defined as 

separate (conceptual, developmental, and production). 

A.3.2: Establish funding and identify expertise between services to develop an automated tool (e.g. by 

expanding SYSPARS) to assist developing TDP requirements (CDRL, SOWs, worksheets) [also 

includes A.7.2].

A.8.1: Apply TDP requirements and evaluate all related decisions to make sure contractor dependence 

is not increased. Do this early and maintain throughout contract. 

A.9.1: Require native, neutral, and viewable formats for the entire supply chain. Ensure that 

transportable, shareable, usable, clearly identifiable formats are established at Data Call.

A.4.2: Require accountability for acquisition decisions made by PMs and other stakeholders that 

extend beyond their tenure (investigate U.K. example) [also includes A.4.1 & A.1.5].

A.10.1: Require all programs to adjudicate and validate all of contractor data rights assertions. It is a 

DFARS requirement today, but seen as an option. 

A.2.4: Establish training, certification, and knowledge capture to address declining workforce issues for 

Acquisition Data Management professionals [also includes A.2.1, A.2.6, A.3.4, A.3.1,& A.7.3].

A.3.3: Reconvene an OSD advisory group to identify and promote critical needs, showing the value of 

TDP and the high cost of ineffective TDP acquisition practices [also includes A.2.3 & A.11.3].
21

3.2 Group B – Production, Planning, and Design 

The naming of this group was accidental in a way. We are trained to think of the design and 

manufacturing process as sequential – design, manufacturing planning, and production. The fact that 

this group was named exactly backwards from the norm may mean that we are making progress in 

thinking of design and manufacturing as a system. The name was left as originally defined to make the 

point of unity of the design and manufacturing processes. However, we will revert to the sequential 

view because, in the interest of concurrency, design must precede production. 

It is reasonable to define the scope of the group’s assignment before the work is reported. There is 

some legitimate debate about the starting point because, as our group continually reminded itself in the 

workshop, our focus is on the technical data package, and the linkage to requirements in the technical 

data package may not be well established. However, the provision of the TDP of the future must address 

requirements and their traceability into design and production. Therefore, our starting point is the clear 

definition of product performance, process limitations, materials specifications, and compliance issues. 

These are all requirements that must be met in delivering a successful product. Hence, the group’s 

scope starts with the requirements and is defined as all activities and functions associated with creating 

and managing a TDP in a model-based environment, from requirements through production. It is 

emphasized that, although sustainability and lifecycle issues are addressed in the workshop by Group C 

– Provisioning, Logistics, and Sustainability, there must not be any breaks in the “digital tread” or any 

disconnects in the seamless information flow in the model-based enterprise. 

For the purposes of our mission a TDP transfers information from the people whose job includes 

creation of the information to the people who need it to do their job further downstream. People who 

supply the needed information to the TDP for the item they produce need to know how to package their 

information so that it will meet the TDP requirements. They also need to help develop the content and 

format of that information to make the process as efficient as is possible. 

Historically, 2D drawings with notes and associated lists were, by default, the only standard way to 

document the product definition. There are many reasons for this default including both technology and 

cultural aspects. Recently, however, the computational capabilities required to capture the full product 

definition in 3D models has become more widely available leaving culture as the major obstacle. Many 

discrete part manufacturers use 3D product models to communicate requirements and drive the 

manufacturing process, especially those of large complex assemblies. It is time to rethink the cultural 

and business practice norms and commit to a 3-D environment.

In the small group discussions, the focus was on how best to take advantage of the 3D model ability to 

present a virtual view of the product is integrated with notes and lists as a replacement for the 

traditional set of noted drawings and the associated lists. The group considered the topics to be 

addressed and modified the functional model to include:

 Requirements/Concepts - the initial formulation of what goals/needs must be satisfied 

and the approaches to be used; 

 Design - defining and creating/presenting both the functional and physical aspects of 

the envisioned product

 Planning - determining the sequencing of actions/methods to actually manufacture 

 Production - manufacturing and includes sourcing whether made internally or made in a 

supply chain
22

3.2.1 Deficiencies or Barriers 

The following narrative is based upon the group modified functional model and provides insight to the 

major deficiencies, barriers, and/or needs along with emerging best practices identified by the group. A 

‘bullet’ view of key points is also provided in Table 2. 

Overall, the current state of TDP development is one of good progress in the technical capability with

clear directives and mandates to move toward complete 3-D TDP provision. But, much work remains to 

be done to achieve the ultimate objective of consistent, rich TDPs for every product produced. This 

section deals with the technical and business practice requirements and, although we acknowledge the 

needs, seeks to leave the policy and legal issues to other groups.

From the technology standpoint, the ability to produce and support a fully functional 3-D TDP is readily 

available. It is certainly possible to produce a rich package for almost any envisioned system. The 

limitations exist in the fact that these packages would not be the result of an integrated product and 

process development methodology. It would not adhere to standards (or would achieve only limited 

adherence) because there are voids in the standards sets, there are duplicative standards that are not 

harmonized, and there does not exist a complete and integrated, standard method for developing TDPs.

In addition to the voids in standards there are process and methodology voids. While instructions, 

directives, and mandates are in place, a common methodology for applying a systems approach to 

creating a uniform and consistent TDP does not exist. It is important to note that, as is the case in all 

current state discussion, the fact that there is work to be done does not in any way seek to provide a 

disservice to the excellent progress that is being made.

There are emerging best practices that point in the direction of the ultimate solution. The DLA has 

conducted studies and performed pilots that seek to define common structures for complete 3-D TDPs.

These prototypical TDPs are being reviewed and updated. Rich TDP packages have, indeed, been 

produced and delivered, especially at the component level. At the systems level, there are programs 

that have committed to the provision of a complete 3-D TDP package. One example from outside the 

DoD community is the NASA Aries program wherein there is a contractual commitment to the delivery 

and maintenance of both 2-D and 3-D TDPs for all components, subsystems, and systems. While there is 

much to do, much has been accomplished.

Requirements/ Concepts

The TDP has its beginning in requirements definition – often as early as the Request for Information (RFI) 

phase of product development. The intent to “grow” or mature the TDP from these early phases, and to 

provide traceability of design to requirements dictates that technical data be developed and maintained 

during conceptual development, which feeds the detailed design process.

In the current state the model-based tools that enable evaluation of requirements and development of 

concepts are spotty or immature in the best cases. In many applications, there is very limited systematic 

processing of requirements to concepts. There are several reasons for this. So often new concepts are 

developed almost exclusively from existing designs which stifles innovative solutions. While there are 

many advantages to such an approach – like assured maturity of both technologies and manufacturing 

readiness - the practice limits capability improvements to only incremental potential. The second reason 

for limited processing of requirements to concepts is that the MBE tools to support such development 

are very immature or are not available. Requirements management tools are part of the Product 

Lifecycle Management (PLM) packages, but are not yet as well integrated with the 3-D designs as they 

must and will be. As the integration of requirements modeling tools with CAD matures the ability to 

produce 3-D conceptual designs traceable to requirements including tradeoff support, will also mature.
23

The model-based enterprise dictates the rich evaluation of concepts for the ability to satisfy 

requirements. Cost, producibility, schedule, performance, and risk assessment, based on requirements, 

that enables best decisions very early in the design process is essential for mission success. This 

document is focused on the TDP, and the TDP can and should capture the decision process as concepts 

are evaluated, down selected, optimized, and the knowledge gathered from that process, for future 

application.

The TDP in the requirements/conceptual stage is immature - still undergoing evolution. TDP 

requirements are not usually collected into a database that collaborators can access and that restricts

availability of the information needed to develop a TDP during the conceptual phase. The information is 

dispersed and currently resides with other parties. Moreover, there are no current tools to accomplish 

the exchange and collaboration tasks. Therefore, data cannot be effectively exchanged with other 

parties thus creating an environment that impedes the ability to apply MBE tools in the initial 

conceptual requirements and design activities. 

Although the MBE toolset has dramatically and rapidly matured, there are still many voids to fill. One is 

the systematic traceability or linkage of specific design artifacts to the requirements. Interoperability of 

systems management tools and a methodology for mapping the progress of product realization would 

be a great improvement. An MBE initial capabilities document would help clarify this situation and 

supply much needed direction. Systems engineering methodologies and vendor specific toolsets are 

needed to move toward this capability.

To further complicate the situation, during the conceptual design phase of a project, the requirements 

for TDP packages change too many times. These changes create significant configuration management 

and closure issues. One of the problems is that design package requirements are allowed to change 

when fixing or locking them in place would be more appropriate. Change propagation is often a manual 

function, and prone to errors and disconnects.

One of the biggest deficiencies is a lack of clear definition for TDP management. Presently, the TDP 

package deliverable items and the mechanisms for delivery are not clearly defined. Resolution of this 

lack of clarity is critical to the overall use of model based TDPs.

The PPD team identified several Emerging Best Practices that are applicable to the Requirements/ 

Concepts area. Model based systems engineering initiatives are beginning to integrate the systems 

model from which designs are driven. The use of Systems Modeling Language (SML) and the Unified 

Profile for DoDAF/MoDAF (UPDM) as a standard way of systems modeling is evolving. Automated 

settings within CAD tools are being used to force users to comply with process requirements.

There is an emerging use of a knowledge based tool set for requirements capture and decision support 

during conceptualization. These tools often work in a web enabled environment to support 

collaboration with stakeholders. An increasingly strong emphasis on affordability is driving a strong push 

in requirements management to support design optimization.

Increased use of tools and standards for requirements support is evidenced by the U.S. Army 

Automotive Research, Development, and Engineering Center (TARDEC) utilizing standards with Pro-E 

START files and TDP developing processes to satisfy design requirements. Likewise, the NAS 3500 

(National Aerospace Standard) provides scorecard mechanisms which assure completeness of 

requirements and information flow mechanisms. The STEP AP233 systems engineering information 

model also provides an emerging capability to represent requirements and other systems engineering 

information.
24

Lastly, there is an emerging strong link between funded programs and Warfighter needs. The DoD has 

implemented many programs to assure that its expenditures are directly aligned with the needs of the 

missions and the Warfighters. Whatever systems may be put in place, response to Warfighter needs will 

always require response to the voice of the customer and excellent communications of the 

requirements from that voice - a key purpose of the TDP.

Design 

One qualifier, right up front – the consensus of the group was that “design is design.” While we 

understand that there may be a difference in fidelity and completeness in conceptual designs and that 

the TDP might not be taken to the same level of detail, a conceptual design should be considered as an 

integrated part of the design process, including the full use of all data generated. Data entered and 

captured in the TDP in the conceptualization process should flow directly to the detailed design.

There are several limitations in today’s environment. The cost of procuring and maintaining the Product 

Life-cycle Management (PLM) toolsets is seen as too high. This problem may be very manageable at 

large companies, even when multiple PLM platforms are maintained, but it creates real problems for the 

supply network. STEP has come a long way in mitigating the need for multiple systems, but STEP does 

not yet provide all of the information that is necessary to fully convey design intent. Some emerging 

tools like Adobe reader are entering this market and providing some exciting options.

Annotations to capture specific requirements and processing instructions must be added to the design, 

and must persist throughout the design and manufacturing environment. Special tools have been 

required to manage annotations, but recent additions to PLM systems have greatly increased the 

functionality. In today’s CAD environment, it is reasonable to expect that all needed annotations can be 

provided. However, they may only persist in native model and there are no (or limited) standards for the 

integration of annotations in the TDP.

Change propagation is a critical element of a design environment and for the provision of the needed 

TDP. This deficiency has multiple areas of impact. On the grand scale, a design change should be 

propagated forward to the downstream applications and upstream to the requirements/conceptual 

design environment. This means that the TDP would automatically be updated. Tools are not available 

to support this functionality. On a more specific scale, when changes are made in a single component, 

subsystem, or system, in either the product or process, in today’s environment, significant manual 

modification is required. The achievement of a seamlessly integrated - as conceived, as designed, as 

planned, as produced, as used and as supported environment is still to be achieved.

There is a distinct shortfall in the overall set of integrated tools and tool capabilities. Integration is 

lacking between conceptualization tools and detail design tools. The ability to make early producibility 

assessments does not generally exist in either the tools or the current practices. As mentioned before, 

adding to the shortfall is the high cost of design tools (product lifecycle management (PLM) and

computer aided design (CAD) tools plus the lack of fully implemented Product Manufacturing 

Information (PMI) standards.

Models need proper annotation to match MBE standards but there is a lack of proper annotation to 

extract the true meaning from of a model. There are inconsistencies in the methods with which CAD 

vendors implement standards and a hesitancy or unwillingness of CAD vendors to respond to the 

definitions of the content and structure of data that is defined in the STEP application protocol. This 

inconsistency creates huge problems when software vendors update their systems without supporting 

legacy needs.
25

Another severe shortfall is found in the current 3D environment which does not support mechanisms for 

change. The lack of OEM buy-in to MBE and 3D TDPs compounds this problem. STEP 232 TDP13 is a move 

in the right direction but modularization is needed to interact with other modular applications. STEP 232 

TDP does not identify what is needed in the TDP but only arranges items in the correct locations. 

Because STEP requires data conversion to make use of the data, it must be validated. Unfortunately, the 

government has not made the necessary conversion to their system. Finally, there is a lack of insight into 

the design requirements for commercial off-the -shelf (COTS) and source controlled components.

Confidence in the design information at every level in the supply network is critical, but short falls 

undermine the needed confidence. There is difficulty in exchanging data with design partners and 

suppliers. Product libraries possess models that are unique to companies and organizations, but such 

libraries may have the same part number for different parts leading various systems to reject the parts 

because the model is different. This issue affects the completeness and accuracy of the models which 

may effect and not support the necessity of spawning designs for related components (tooling, fixtures, 

and molds).

At this time, the government requires the delivery of a fully annotated 2D drawing. In the current 2D 

TDP arena there is a clear definition of what is required in the TDP, such as, drawings, tech data, 

specifications, quality assurance processes, and packaging. The 3D TDP needs a similar definition. 

Standardization of quality requirements is also needed to assure that they are captured into the design 

and in a format acceptable to the government. There is currently no standard method for defining or 

delivering a complete TDP to the government that includes all narrative documents that must be 

delivered (digital product definition packages). The government does not clearly define the content and 

structure of the data it requests resulting in inconsistencies in the deliverable of the TDP to the 

government.

Currently, there is no scorecard available for tracking items through the product realization cycle to 

ensure that the TDP requirements are being met. A design maturity index is needed that is accepted and 

useful for all members of the supply chain. There are multiple scales for this task but there is no unifying 

scale to build a scorecard.

From the DoD perspective, the lack of integrating MBE and TDP strategies with the DoD acquisition 

process is a major barrier. One approach to overcoming many deficiencies for the DoD is leveraging the 

well defined acquisition strategy complete with stages called the “Acquisition Technology Development 

Process.” The capabilities document is created as these phases are addressed. Mapping of MBE and TDP 

strategies with the acquisition process would be helpful. The Joint Capabilities Integration System 

(JCIDS) could provide the initial requirements.

While there is much to overcome, many emerging best practices are in place and evolving such as the 

increasing use of Design Structure Matrix (DSM) - a simple tool to perform both the analysis and the

management of complex systems. The DSM enables the user to model, visualize, and analyze the 

dependencies among the entities of any system and derive suggestions for the improvement or 

synthesis of the system. There is emerging availability of free 3D viewers is assisting in making 3D 

imaging more widely received and used. The use of standard models of components for collaborative 

design model libraries of components is becoming common. Development and sharing of domain

specific modeling procedures, based on an information model, are being developed. Automated tools 

 

13

 AP 232: Application Protocol for Technical Data Packaging Core Information and Exchange. The standard 

published in 2002 as ISO 10303-232:2002(E).
26

for generating, translating, converting, validating, and distributing models as files are being applied.

Rather dramatic productivity improvements are being realized from these implementations.

Several government and industry initiatives are enhancing the MBE and TDP environment. There is 

emerging use of knowledge based automated design in the aerospace and marine industries. In 

November 2008, the aerospace industry published National Aerospace Standard NAS 3500--Technical 

Data Package--Composition, Communication, and Application. Its purpose is to “facilitate better 

composition, communication, and application of technical data at every level of the supply chain. For 

aerospace industry primes, this means less expensive deliverables, for suppliers it means enhanced 

efficiency and responsiveness to their customers’ requirements.” 14 European Aeronautic Defense and 

Space Company (EADS), the parent company of Airbus, has developed a TDP messaging standard. 15 The 

automotive industry has developed recommendations addressing the implementation of STEP for 

engineering change management and requirements management per Automotive Industry Action 

Group (AIAG) D2616 The Organization for the Advancement of Structured Information Standards 

(OASIS), a standards consortium, is developing data exchange sets and specifications to implement the 

ISO 10303 Standard for Exchange of Product Model Data (STEP) Product Life Cycle Support System 

(PLCS). Likewise, the convergence of STEP 203 and 214 to create a super set for mechanical product CAD 

standards is a major improvement. Additional improvements include tools to validate Product 

Manufacturing Information (PMI) results; improved CAD Data Exchange via the SME Productivity 

Through Interoperability (PTI) initiative,

17 and tools from ITI TransenData18 and the overall dramatic 

improvements in design tools.

Lastly, a much needed and welcome major foundational element is found in the growing 3D focused 

workforce that is emerging across the manufacturing and design community.

Planning

Many companies experience a disconnect between product design and process design. This disconnect 

comes into play in the manufacturing planning and manufacturing execution functions. Companies, like 

Boeing, have aggressively embraced “as planned” as an important and visible part of the product 

development cycle. However, they openly admit that to achieve “as planned” they have been forced to 

develop a home grown toolset that interfaces with the CAD/PLM environment, but must be maintained 

in house.

It is fair to say that manufacturing planning suffers from a lack of good 3D simulation tools, which

evidences itself in difficulties producing and supporting the process needs of the TDP. The majority of 

the models are textual based and not 3D based highlighting a need for consistent text in model 

annotation and notes. The lack of manufacturing process and facility models (e.g. machine tools, crane 

capacities, and etc.) and difficulty in creating and supporting tooling models across the supply chain also 

 

14 http://www.qualitydigest.com/magazine/2009/apr/article/reducing-errors-manufacturing.html

15 http://www.eads.com/1024/en/eads/eads.html

16 AIAG D-26 Engineering Change Management (ECM) Reference Process; A reference document which supports 

AIAG's D-29 (Engineering Change Management - ECM Recommendation) & D-30 (ECM Recommendation -

Engineering Change Request - ECR) Engineering Change Management Documents.

https://www.aiag.org/source/Orders/index.cfm?section=orders&ETask=1&Task=1&SEARCH_TYPE=FIND&FindI

n=0&FindSpec=D-26&x=13&y=5

17 http://www.sme.org/cgi-bin/get-event.pl?--001642-000007-019944--SME18 http://www.transcendata.com/
27

impact the planning and the ability to capture that process to the needed level of fidelity. The lack of 

information integration from product to process limits the flow of information and inhibits effective 

change management. In fact, process changes must be manually captured, recorded, and should initiate 

a change in process planning and shop work instructions. The management of those changes is costly 

and takes too long!

There is a lack of visibility into enterprise wide assets, including characterization of equipment,

processes, and the models that support their characterization. This inhibits efficient production of the

complete set of data needed to support downstream applications such as first article inspection and the 

consumption of characteristics during production planning, and etc.

There are other deficiencies that make the execution and capture of the planning function inefficient. 

The lack of value stream mapping standards hinders the use of this important methodology in 

optimizing process flow. There is a lack of adequate tools to translate electronic bills of material (EBOM) 

to manufacturing bills of material (MBOM). There are interoperability issues between product life-cycle 

management (PLM), material requirements planning (MRP) and manufacturing execution systems 

(MES). All of these issues inhibit the process of creating and managing an adequate TDP that includes 

process information.

Problems are exacerbated due to frequent changes in design requirements during TDP development and 

resulting conformity issues. These challenges are magnified by the lack of integration among production 

planning, design data, and design requirements across the supply chain. The inability to adequately plan 

for surge, design changes, and lack of materials availability impacts production and product support.

Incompatible business practices and lack of tool interoperability limits the engagement of suppliers in 

the process planning and leads to voids in the documentation.

The lack of interoperability and limitations in translators that support neutral presentation impacts the 

ability to create and share needed plans. There is a strong need to understand the limitations of the 

translation toolset to assure that the functionality needs are met and to systematically provide better 

solutions. Incomplete or ambiguous product information is often delivered to the supply chain due to a

lack of interoperability and incomplete translation of product data needed to define key characteristics.

Process modeling systems may also not integrate with a PLM tool set within a company or across 

multiple companies.

A lack of availability of automated tools for annotating the TDP model and the difficulty in effectively 

using the available tools multiplies the necessity for manual labor and cost of providing a complete TDP.

The TDP requirements do not include process plans because they are often derived from Intellectual 

Property (IP). It certainly would be in the best interest of the government to review this policy.

The maturity of the process technologies and manufacturing readiness are not now included in the TDP. 

In the TDP of a mature, fielded product, it is fair to assume that the readiness levels would be high, and 

that they might be irrelevant. However, in product development the integration of readiness into the 

Level I or Level II TDP process would add value. Also, MBE activities are not presently included in the 

MRL documentation (the MRL desk book). But new acquisition policies state that a new TDP must be 

both Technology Readiness level (TRL) and Manufacturing Readiness Level (MRL) compliant.

Much work is needed to resolve problems in the planning arena, but emerging best practices are 

indicative of rapid progress. Some companies are beginning to design to the maximum capability of

interoperability within a tool-set. There are now tools available to identify and document characteristic 

level data. Improved process simulations that incorporate actual equipment performance and behavior 

into the model are available. This results in higher fidelity models and allows for better planning. Some 

companies are seeing the advantages of leveraging a TDP and pieces of the TDP set for reuse with other 
28

designs. Likewise, the ability to validate the process plan in a 3D simulation is a very valuable asset. 

Other advancing capabilities include leveling the loading of production resources by comingling product 

and product lines to save time and material e.g., optimizing the use of steel plates by laying out 

components for multiple ships on the same plate. The ability to line balance the TAKT time19 by using 

multiple products on the same line can make a huge difference and improvement in production line 

scheduling and productivity. The ability to capture an approved vendor list (AVL) and an approved 

material list (AML) into the metadata is being used to help assure TDP compliance.

One huge emerging advantage digital model capture is the ability to store manufacturing process 

recipes instead of stockpiling parts. For example, Defense Micro Electronics is using recipes for 

supporting obsolete parts. Parts can be more easily manufactured on demand instead of having to be 

stockpiled.

Improved tools that enable 3D work instructions by directly using the product and process models – part 

of the TDP - are becoming commonplace. Some of these tools are COTS, but, in the main, they are 

custom applications developed and locally supported by the companies themselves. Many tools are 

available and in use to enable consumption of characteristic level data directly from the TDP. One 

interesting development in 3D model use is that NASA-Michoud has placed responsibility for 

management for the facility model with the facilities contractor. Elsewhere, government in-house 

capabilities are storing details of their process plans in the TDP and managing them in the product lifecycle management (PLM) system. This system is used by vendors and other government depots but is 

not yet used by private industry.

Production (includes sourcing whether made internally or made in a supply chain)

Note: many of the deficiencies and best practices described in the design sub-section also apply here, 

particularly those related to interoperability and data exchange across supply chain.

In an MBE enterprise, the information and data should be continually enriched until, at the point of 

production, all needed information is available and in the form needed. The TDP should have matured 

through that process. Today, this is not the norm, especially associated with providing needed data to 

the supply base. Similarly, the needed understanding may not be provided. For example, in a design to 

requirements contract, the language of the TDP may not be understood by the members of the supply 

chain that must receive and respond to that data. Because the language may not be clear the flow and 

interpretation of technical requirements through the supply chain are often not understood properly. If 

a supplier does not understand and cannot receive timely clarification the production of defective parts 

may result and time and cost is the price that is paid. One example is that in some processes, e.g. 

stamping a flat plate, or composite parts, the TDP may not adequately represent the details necessary to 

make a required 2D representation. In other cases there may be poor application of general dimensions 

and tolerances within models. It is noted that CAD tools are very expensive (particularly from the 

perspective of small businesses), which may impact broad based adoption by smaller lower tier 

members of the supply chain.

 

19 Takt time isdefined as the maximum time per unit allowed to produce a product in order to meet demand. It is 

derived from the German word Taktzeit which translates to cycle time. http://en.wikipedia.org/wiki/Takt_time

Alternative: “Lean manufacturing systems work on a rhythm. Whole organization works on the rhythm provided by 

the customer. This rhythm is known as the TAKT time of the system.” 

http://www.leanmanufacturingconcepts.com/LeanTool_TAKT.htm
29

The TDP typically does not include production data but it is acknowledged that it is important to do so if 

we are committed to TDP’s that fully support the product through its lifecycle, e.g. G-code or CNC code 

is not incorporated in the package. 

There is a need to extract key characteristic data from the model to support statistical process control 

(SPC) and process control. This functionally may not be supported. The TDP usually does not contain a 

schedule for components for the timely completion of assembly and also may not contain the hierarchy 

of components and assembly.

Change propagation is a major issue in an MBE environment. Changes that are made to the product 

model during manufacturing may not be reflected in the TDP and the information that production needs 

may not be available in the TDP. The changes made in the manufacturing cycle may include substitute 

parts, alternative parts, substitute materials, and process changes. Sometimes changes made in the 

design TDP are not given to production in a timely and useful way. One reason for this disconnect may 

be that the current shop floor delivery systems are 2D based and cannot take advantage of 3D TDP.

Mechanisms for managing non-conformances that are identified on the shop floor as part of a digital 

environment may not be adequate. Also, at present, there is no definition of the data required for an “as 

built TDP” in an MBE environment.

Lastly, regardless of whether prime vendor or supply chain member, the skill sets for using 3D data and 

TDP data on the shop floor must be learned skills and that learning curve must be incorporated into 

production schedules.

Several emerging best practices were identified by the PPD team in the Production phase. Use of the 

National Aerospace Standard NAS 3500--Technical Data Package--Composition, Communication, and 

Application enables the understanding of technical requirements in production across the supply chain.

There are increasing deliveries of 3D models to supply chain management portals, i.e. MEP Columbia.

Paperless communication of configuration managed condition of supply with partners and vendors is 

being used for the production of the Boeing 787. Integrating suppliers and vendors and other 

stakeholders into internal PLM system is becoming more common. Based on characteristics in the TDP, 

ongoing application of tools to acquire characteristic level SPC data from the supply chain is being 

accomplished. 

3D interactive work instructions on the shop floor are becoming more commonplace and greatly assist 

the skilled crafts persons in performing their tasks. CNC processes are being embedded in the 3D model. 

This reduces time necessary to independently generate those instructions. Animated assembly tools 

used in production, e.g. Red River transmission, are being used during the actual assembly process to 

assist in accurate and timely production. The tremendous improvement in CAD and CAM systems has 

allowed the ability to machine freeform surfaces on multi-axis machines. The Open Applications Group 

Integration Specification (OAGIS) format is being used for process routes which will aid in data exchange 

and interoperability.

Table 2 Current state table for Production, Planning, and Design

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

Requirements/ Concepts

 TDP requirements are not collected into a 

database that collaborators can access.

 Model based systems engineering initiatives 

are beginning to integrate the systems 

model from which designs are driven.
30

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

 The information needed to develop a TDP is not 

available because it belongs to other parties. 

(There is no clarity regarding the information 

that is necessary).

 Data cannot be effectively exchanged with other 

parties while working at the concept level. This 

is true because the TDP at this stage is not 

mature. There are no current tools to 

accomplish this task.

 Tools to support the application of MBE tools in 

the initial design activities are not readily 

available, and those that exist lack maturity and 

functionality.

 There is a lack of MBE technology to enable 

requirements driven conceptual design.

 Traceability or linkage of design artifacts to the 

requirements is usually not achieved.

 A methodology for mapping the progress 

through the product realization cycle does not 

exist, or, at least, is not well utilized. Work flow 

models get at the essence of this deficiency, but 

are not well utilized.

 A lack of interoperability of systems 

management tools is a problem.

 The capabilities of MBE tools are not well 

known.

 Product realization processes allow design 

package requirements to change when they 

should be fixed.

 The requirements for design packages change 

during the development process, which creates 

configuration management and closure issues.

 The deliverable items of the TDP are not clearly 

defined in the “deliver package”. The 

uncertainty of which items are separated 

creates a lack of clarity. 

 Mechanisms for the delivery of a TDP are not 

clearly defined.

 Systems Modeling Language (SML), and the 

Unified Profile for DoDAF/MoDAF (UPDM ) 

are emerging as a standard mechanism for

systems modeling.

 Automated settings within the CAD tool are 

being implemented to force the users to 

comply with process requirements.

 Web enabled tools are in limited use to 

collaborate with stakeholders and manage 

various data and documents.

 Early adopters are making use ofof a 

knowledge based tool set for requirements 

capture and for decision support in 

conceptualization.

 A strong affordability emphasis is driving a

major emphasis on requirements 

management for design optimization. The 

emphasis is being places on strong 

functionality with minimal extras.

 TARDEC utilizes a standard with a Pro-E 

START file and TDP developing process to 

satisfy design requirements.

 The NAS (National Aerospace Standard) 3500 

provides scorecard mechanisms to 

determine completeness of requirements, 

connect, flow mechanisms.

 The STEP AP233 systems engineering 

information model represents requirements 

and other systems engineering information.

 merging strong link between funded 

programs and the Warfighter needs -

however improved customer and user voices 

are needed via TDP.

Design – (Functional and Physical)

 There is a lack of integration between 

conceptualization tools and the tools needed for 

detail design. We enter and reenter data.

 Design structure matrix – a design of 

experiments approach to the design 

problems.
31

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

 The ability (tools and practices) to make early 

producibility assessments does not exist.

 The cost of design tools (PLM and CAD) tools is 

too high.

 Product Manufacturing Information (PMI)

standards are not fully implemented.

 There is a lack of proper annotation to extract 

the true meaning from a product model. 

Standards for annotation are inadequate.

 Validation tools are needed to assure that 

models comply with TDP requirements.

 There are no validation tools that accommodate 

the various tools and formats.

 There is inconsistency in the methods with 

which CAD vendors implement standards.

 There is unwillingness on the part of CAD 

vendors to respond to the definitions of the 

content and structure of data that is defined in 

the STEP application protocol.

 STEP TDP Application Protocol (AP) is not 

modularized so it can interact with other 

modular APs.

 Huge problems are created when software 

vendors update their systems without 

supporting legacy needs.

 Change management methods and tools that 

support a 3D environment are not adequate to 

meet the need.

 There is a lack of OEM buy-in to MBE and 3D 

TDPs.

 There is a general lack of confidence in the 

design information at every level in the supply 

network due to a difficulty in exchanging data 

with design partners and suppliers. The lack of 

confidence is, in too many cases, well founded.

 Product libraries possess models that are unique 

to companies and organizations. Some of the 

modeled products have the same part number; 

therefore, various systems reject the parts 

because the model is different.

 Completeness and accuracy of the models may 

not support the necessity of spawning designs 

 The emerging availability of free 3D viewers.

 The use of standard models of components 

for collaborative design component model 

libraries.

 Development and sharing of domain specific 

modeling procedure, based on an 

information model, to generate needed 

data.

 Automated tools for generating, translating, 

converting, validating, and distributing files.

 Knowledge based automated design –

aerospace, marine industry.

 Publication and use of NAS 3500

 Organization for the Advancement of 

Structured Information Standards (OASIS) 

data exchange specification to implement 

STEP PLCS.

 Automotive industry has developed 

recommendations addressing how to 

implement STEP for engineering change 

management and requirements 

management AIAG D26.

 European Aeronautic Defense and Space 

Company (EADS) Airbus has developed a TDP 

messaging standard.

 Convergence of STEP 203 and 214 to create 

a super set mechanical product CAD 

standard.

 Tools to validate PMI and generally the 

dramatic improvements in design tools.

 3D focused workforce emerging everywhere
32

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

for related components (abstractions for tooling, 

fixtures, and molds).

 STEP 232 TDP is a move in the correct direction, 

but it must be modularized. STEP 232 TDP does 

not identify what is needed in the TDP. It only 

arranges the information in the correct 

locations.

 There is a lack of insight into the design 

requirements for COTS and source controlled 

components

 STEP requires data conversion to make use of 

the data. Therefore, the data must be validated. 

Often, the best alternative is to create the model 

in the native mode.

 The government requires the delivery of a fully 

annotated 2D drawing. In the current 2D TDP 

arena there is a clear definition of what is 

required in the TDP. Example, drawings, tech 

data, specifications, quality assurance processes 

and packaging. The 3D TDP needs a similar 

definition.

 Standardization of quality requirements is 

needed to assure they are captured in the 

design and in a format acceptable to the 

government.

 The government does not clearly define the 

content and structure of the data it requests.

 There is no standard method for defining or 

delivering a complete TDP to the government, 

including the specification of all narrative 

documents that must be delivered (digital 

product definition packages)

 There are no consistent tools available to deliver 

the TDP to the government.

 There is no scorecard for tracking items through 

the product realization cycle to ensure that the 

TDP requirements are being met.

 A design maturity index is needed that is 

accepted and useful for all members of the 

supply chain. There are multiple scales now 

available, but there is no unifying scale.

 There is a lack of integration of MBE/TDP 

strategies with the DOD acquisition process. The 
33

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

DoD has a well defined acquisition strategy 

complete with stages called the “Acquisition 

Technology Development Process”. The 

capabilities document is created as the phases 

are addressed. The Joint capabilities integration 

system (JCIDS). JCIDS could provide the initial 

requirements. A mapping of the MBE

capabilities and TDP requirements to the 

acquisition process is needed.

Planning

 There is a lack of good 3D based process 

simulation tools.

 Most of the existing models are textual based 

and not 3D based.

 The lack of facility models (crane capacities, etc.) 

limits the ability to optimize product and process 

flow.

 The capability and scope of process modeling is 

limited. A rich set of reusable and adaptable 

models is needed.

 Difficulties with creating and supporting tooling 

models across the supply chain is a problem.

 The ability to spawn fixturing and tooling models 

from product and process models is 

 It takes too long to implement design changes in 

process planning and shop work instructions.

 There is a lack of visibility of enterprise wide 

assets and capabilities.

 There is a lack of sufficient characteristics

definition. There is a need for level data to 

support downstream requirements, e.g. first 

article inspection, consumption of 

characteristics during production planning, etc.

 Tools to translate EBOM to MBOM are needed

 There are interoperability issues between PLM, 

MRP and MES systems.

 Value stream mapping standards do not exist, so 

the results can’t be uniformly shared or 

understood.

 Frequent changes of design requirements during

TDP development cause conformity failures.

 Design to the maximum capability of 

interoperability within a tool/toolset.

 Tools are available to identify and document 

characteristic level data.

 Improved process simulations that 

incorporate actual equipment performance 

and behavior into the model, resulting in 

higher fidelity models for better planning.

 The ability to reuse the TDP set and pieces of 

that TDP set and send that information to 

the floor.

 Ability to validate the process plan in a 3D 

simulation environment

 Level loading of production resources by 

“comingling” product and product lines. 

(e.g., optimizing the use of steel plates by 

laying out components for multiple ships on 

the same plate.)

 The ability to line balance the TAKT time by 

using multiple products on the same line.

 The ability to capture AVL (approved vendor 

list) and AML (approved material list) into 

the metadata for assuring compliance.

 Stockpiling manufacturing process recipes 

instead of parts. (Defense Micro Electronics 

is utilizing recipes for supporting obsolete 

parts.)

 Enabling 3D work instructions by directly 

using the TDP.

 Tools are available to enable consumption of 

characteristic level data directly from the 

TDP
34

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

 Limited integration of production planning

based on design data and design requirements 

across the supply chain.

 At times design changes are forced due to a lack 

of availability of materials.

 Availability of materials sometimes forces design 

changes. These design changes often are not 

incorporated in the documentation of the TDP.

 Models are needed to support planning for 

surge. There is a need to understand the limits 

of the translation tools and design for the 

maximum possible functionality and the 

maximum capability of the interoperability 

toolset.

 Suppliers are often not adequately engaged in 

the process planning process.

 Incomplete or ambiguous product information 

(to define key characteristics) delivered to the 

supply chain is a problem. Sometimes this 

inadequacy results in product errors, and 

sometimes in less than optimum production 

planning.

 Process modeling systems may not integrate 

with a PLM tool sets within a company or across

multiple companies.

 There is a lack of availability of automated tools 

for annotating the TDP model.

 Manufacturing process tools have a steep 

learning curve. 

 TDP does not include process plans (IP issue).

 MBE activities are not integrated within TRL and 

MRL definitions guidance documents (MRL desk 

books).

 MRLs are not part of the TDP.

 NASA-Michoud (New Orleans) has placed 

responsibility for management for the facility 

model with the facilities contractor.

 Government in house capabilities are storing 

details of their process plans in the TDP and 

managing in the PLM system. This is used by 

vendors and other depots but not to private 

industry.

 STEP NC for machine and controller 

independent process plans.

 New acquisition policy states that TDPs must 

be both TRL and MRL compliant.

 MANTECH has developed a 3-D CAD 

capability assessment scale.

Production– (includes sourcing whether made internally or made in a supply chain).

 There is a lack of direct access to the data 

models by members of the supply base (we 

email, ship...)

 In design to requirements contracts the 

language of the TDP may not be understood by 

 NAS 3500 enables the understanding of 

technical requirements in production across 

the supply chain

 Delivery of 3D models to supply chain 

management portals., i.e. MEP Columbia
35

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

the members of the supply chain that must 

receive and respond to that data. There needs to 

be an understanding of the cost implications of 

supplying or not supplying the data needed at 

the fidelity that is needed.

 The flow and interpretation of technical 

requirements through the supply chain are often 

not clear. If the supplier does not understand 

and cannot get clarification, defective parts may 

result.

 Some processes (stamping a flat plate, 

composite parts) that require a 2D 

representation may not be adequately 

represented in the TDP. 

 There is a poor application of general 

dimensions and tolerances within models. 

 The TDP does not include production data, and it 

is acknowledged that it is important to do so. 

E.g. G-code or CNC code is not incorporated in 

the package. Note: there is an understanding 

that the utility for reuse may be limited.

 There is a need to extract key characteristic data 

from the model to support SPC and process 

control

 The TDP does not contain the schedule for 

components for the timely completion of 

assembly.

 The TDP may not contain the hierarchy of 

components and assembly.

 Changes that manufacturing makes to the 

product model may not be reflected in the TDP 

(substitute parts, alternative parts, substitute 

materials, process changes).

 Changes made in the design TDP are not given to 

production in a timely and useful way

 The current shop floor delivery systems are 2D 

based and cannot take advantage of 3D TDP

 Mechanisms for managing shop floor identified 

nonconformance as part of a digital 

environment may not be adequate.

 There is no present definition of the data 

required for a “as built TDP” in an MBE 

 Paperless communication of configuration 

managed condition of supply with partners 

and vendors e.g. 787.

 Integrating suppliers and vendors and other 

stakeholders into internal PLM system.

 Ongoing application of tools to acquire 

characteristic levels SPC data from the 

supply chain, based on characteristics in the 

TDP

 3D interactive work instructions on the shop 

floor.

 CNC processes are being embedded into the 

3D model.

 Animated assembly tools used in production. 

e.g. Red River transmission.

 Ability to machine freeform surfaces on 

multi-axis machines due to the tremendous 

improvement in CAD and CAM systems.

 Open Applications Group Integration 

Specification (OAGIS) format for process 

routes
36

Current State of Production Planning, and Design

Deficiencies or Barriers Emerging Best Practice

environment

 There are not enough employees that possess 

the skills needed to utilize 3-D data and TDPs. 

The skill sets for using the 3D data and TRP data 

on the shop floor must be learned skills.

3.2.2 Vision Statement

The Technical Data Package for the MBE will drive all applications and 

will support the product throughout its lifecycle – from requirements 

through demilitarization.

In the future, the TDP will be an accurate, complete portrayal of the process of product realization and 

will be the natural result of that process. A requirements driven design and manufacturing environment 

will produce optimized products and processes in a structured and systematic environment. The 

environment will be an integrated system that supports the continuous flow of information as the 

models mature. The design and realization of the physical product will be mirrored and guided by a rich 

model set that will represent that physical product and enable its total value, total lifecycle optimization. 

The TDP will be a readily available, extractable and abstractable, presentation of the product realization 

model set.

This vision is built upon the following elements:

 A complete product definition capability will be capable of driving all downstream 

applications and supporting the product throughout its lifecycle.

 3D will be the authoritative source for all programs based upon contractual requirements.

 The tools and methods for producing and managing a 3D TDP will mature to make 3-D 

models clearly the most cost effective method for product realization – clearly less 

expensive than using 2D drawings.

 TDP that incorporates all elements of producibility and sustainability will be a reality.

 The TDP shall include electronic and software information.

 The TDP shall be completely CAD and PLM agnostic.

 There will be a sufficiently annotated model to support all the elements of producibility and 

desired sustainability.

 The TDP will be accessible at all levels of the supply chain based on a need to know (ITAR).

 There will be a clear mechanism for communication and collaboration throughout the 

supply chain and with the customer. (and a clearly defined mechanism for delivering to the 

government, with the capability to handle a delta transaction)

 There will be a cataloging and archiving information mechanism included in the TDP 

(resolution of LOTAR issues)
37

 A TDP that is used and useful for all CAD systems will be freely accessible for system 

agnostic viewing and utilization.

 The requirements are fully documented and traceable to their satisfaction in the design and 

product realization cycle.

 Automated change propagation is a reality

 As-built TDPs will be delivered to the government at the end of every contract.

3.2.3 Issues and Solutions 

The Production, Planning, and Design Team evaluated the deficiencies, reviewed the directions pointed 

to by the emerging practices, and considered the issues that needed to be addressed to achieve the 

envisioned state. From this evaluation the major issues associated with producing and managing modelbased TDPs were listed within the context of production, planning, and design. These issues include:

 The requirements and the data to develop a TDP are not available

 There is a lack of MBE technology to meet requirement.

 Tools do not interoperate limiting the ability to exchange information for effective

collaboration.

 A lack of standard methods for use (conditions) limits the ability to effectively 

communicate. (addressed in global interoperable topic)

 The acquisition professionals, PMs, and PEOs do not properly perceive the value of MBE 

over the lifecycle. The value of the TDP is understood in some areas and not understood 

in others but is not usually a priority.

 Mechanisms for the delivery, (or provision of access) storage and management of the 

TDP throughout the product lifecycle are not adequately in place. Subset of No. 2

 The inability to provide adequately annotated models. There is no clear guidance to 

define what a fully annotated model should be at each level of TDP maturity and for 

each purpose.

 The lack of a fully integrated supply chain negates the ability to propagate the TDP 

throughout the enterprise – education, standards and interoperability.

 The inability to assure through validation and verification the accuracy and 

completeness of the model. There is no enforcement of the provision of validated TDPs.

 Characteristic level accountability – traceability of requirements through produce design 

and manufacturing at the level at which they make sense and can be 

measured/consumed.

o There is no definition of what manufacturing planning data is required in the

TDP. 

o The need to include narrative documents along with the geometric data in the 

TDP is not well served.

o There is no definition of requirements or methodologies for inspection or QA of 

minimally dimensioned MBE models.
38

 The cost of MBE tools and their implementation is perceived to be too high. The 

industry and government wide business case (ROI) is not established.

 Some organizations lack the infrastructure, IT resources, and tool sets to institutionalize 

and manage an MBE environment. 

 Multitude of IT certification requirements across DoD is a barrier for adopting MBE 

tools.

 The DoD enterprise IT strategy does not enable with MBE tools well.

 The migration of legacy models into new systems is lacking 

 Legacy business practices, tool sets, etc., are barriers to MBE implementation. The 

multiplicity of business processes and their diversity makes it virtually impossible to 

implement new tools sets and practices.

 Information model standards are incomplete and difficult to implement.

 There is no requirement to deliver an as-built TDP, including 3D geometry, to the 

government appropriate for the contract.

 Emerging tools support a portion of the need set, but they support pieces of the 

solution and are not working toward a comprehensive solution to the TDP vision.

These 19 issues were prioritized to identify eleven major issues or challenges that need attention in

producing and managing the TDP. The major issues and their solutions are documented below. The 

complete table of issues and all solutions generated is provided in Appendix B-1. The issues and their 

high-priority solutions are discussed in this section, followed by the team’s consolidated Top Solutions 

that were presented at the end of the workshop.

Section Format

B.x Issue

B.x.y Solution

B.1 The requirements and the data to develop a TDP are not available.

B.1.1 Evaluate existing standards to define the degree to which they address the need.

B.1.2 Evaluate and evolve coordinated contractual language to incorporate a model-based 

response for the TDP (it must include all stakeholders in the procurement process).

B.1.3 Create government regulations supporting MBE that mandate the delivery and 

enforcement of the provision of a complete and adequate TDP.

B.1.4 Create a comprehensive description of the data required for the TDP.

B.1.5 Establish responsibility and accountability including a plan of action to implement the 

TDP requirements.

B.1.6 Conduct pilots to evaluate the effectiveness and utility of the TDP structure and process.

B.2 There is a lack of MBE technology to meet the necessary requirements

B.2.1 Develop a comprehensive plan for MBE.

B.2.2 Conduct benchmarking studies, develop a desired architecture and identify the gaps.
39

B.2.3 Define best practices and standards for MBE and mechanisms for enforcing them.

B.2.4 Create a roadmap to fill the gaps.

B.2.5 Create champions, secure funding and implement the plan (include incentives for 

industry implementation).

B.2.6 Create contractual language that enforces TDP requirements.

B.2.7 Create a continual process of management of the plan and its implementation.

B.3 The acquisition professionals, project managers (PMs), and Program Executive Offices (PEOs) do 

not properly perceive the value of MBE over the lifecycle of the TDP. The value of the function 

of the TDP is understood in some areas and not understood in others. Overall the value of a 

model based environment is not usually a priority.

B.3.1 Provide separate funding for the PM to embrace and implement MBE and the provision 

of complete, 3-D TDPs.

B.3.2 Embed MBOs (management by objectives) that include total cost of ownership in the 

PM fitness report (annual review).

B.3.3 Contract based on total lifecycle costs instead of focus on short term cost minimization 

to enable the upfront investment needed for MBE implementation. Make these 

requirements visible in the RFP.

B.3.4 Conduct an ROI analysis substantiating MBE value and communicate the results to PMs 

and PEOs.

B.3.5 Conduct single digital master file demonstration that validates the short term low cost 

implementation of cost saving MBE processes.

B.3.6 Require Defense Acquisition University (DAU) training for all acquisition professionals, 

PMs and PEOs on the value of MBE.

B.3.7 Provide pervasive enterprise level training across the supply chain for MBE 

implementation.

B.4 The inability to provide adequately annotated models. There is no clear guidance to define what 

a fully annotated model should be at each level of TDP maturity and for each purpose.

B4.1 Achieve a clear definition of and standards to support a fully annotated model across 

government and industry including long term archiving (LOTAR).

B.4.2 Develop and provide clear guidance on the implementation of the applicable standards.

B.4.3 Identify TDP content - and specifically annotation requirements at each level of maturity 

in the product realization process.

B.4.4 Develop a standard for annotation for different product types based on part 

classification.

B.4.5 Define the annotation standards to the lowest common interoperability standards. 

Complete AP203 and AP233 and MBE compatibility index levels and mandate 

compatibility in the contract.

B.5 Tools do not interoperate, limiting the ability to exchange information with other users for 

effective collaboration. 
40

B.5.1 Evaluate the current interoperability capabilities and identify the gaps.

B.5.2 Provide incentives for MBE tool providers to incorporate interoperability standards 

specifically addressing gaps.

B.5.3 Develop a validated translation process for delivering TDP information to the 

government. Establish an independent validation authority (could be design check 

software).

B.5.4 Extend the STEP standards to fully address interoperability requirements.

B.5.5 Accelerate standards development to the point that standards parallel technical 

capability.

B.5.6 Create international partnerships to leverage and assure consistency of interoperability 

standards.

B.5.7 Develop a system similar to SPC mandating the sampling of TDP packages for 

interoperability of information for contractual compliance.

B.5.8 Provide a government system with a validated neutral format to manage access to and 

distribute the TDP data.

B.6 The inability to assure through validation and verification the accuracy and completeness of the 

model. There is no enforcement of the provision of validated TDPs.

B.6.1 Apply existing standards and tools to achieve mutual understanding of TDP content 

between design sources and production sources. (NAS 3500)

B.6.2 Extend existing standards and tools to assure that they adequately address all 

information like provisioning data, acquisition needs, and quality (metadata).

B.6.3 Develop a practice and process for the complete configuration management of MBE TD. 

(Practices exist for TDP but not for MBE TDP).

B.6.4 Develop tools to validate the accuracy of the model and provide needed training to the 

acquisition community.

B.7 Characteristic level accountability – traceability of requirements through product design and 

manufacturing at the level at which they make sense and can be measured/consumed.

 There is no definition of what manufacturing planning data is required in the 

TDP. 

 The need to include narrative documents along with the geometric data in the 

TDP is not well served.

 There is no definition of requirements or methodologies for inspection or QA of 

minimally dimensioned MBE models.

B.7.1 Evaluate the tools and methods that exist and define gaps. Perform benchmark studies 

to identify and establish best practices.

B.7.2 Establish TDP manufacturing (including the extended enterprise) use cases that 

communicate exactly what the government needs. Include narrative documents with 

geometric data.
41

B.7.3 Develop a compliance matrix that maps the manufacturing planning requirements to 

the TDP.

B.8 The multitude of IT certification requirements across DoD is a barrier for adopting MBE tools.

The DoD enterprise IT strategy does not support MBE tools well.

B.8.1 Determine the appropriate chain of command for IT certification in order to harmonize 

requirements with MBE implementation

B.8.2 Establish a process to assure that certification of net worthiness is built into the plan for 

every program.

B.8.3 Highlight the cost of failures in not providing a timely solution to program needs (IT 

installation requirements, risk analysis, net worthiness certification)

B.8.4 Understand the approval process at the installation level

B.8.5 Achieve an MBE presence and voice in IT strategy. This will be accomplished by 

participation in forums and meetings.

B.8.6 Obtain proper authority from OSD mandating MBE implementation and mandating 

processes to support that implementation.

B.8.7 Incorporate MBE enablement into gold standard processes within the government to 

expedite the ability to conduct MBE

B.9 The migration of legacy models into new systems 

B.9.1 Develop business rules that define the amount of legacy information that must be 

provided to support each contract. (reasonable requirements defined by category of 

procurement)

B.9.2 Establish decision support systems based on business rules that guide the acquisition 

decisions regarding legacy data.

B.9.3 Provide line items for procurement of legacy data that is required by new systems 

contracts

B.9.4 Provide a robust tool set that supports the migration of 2D models to 3D models 

including the capture of relevant information and the migration of non-annotated 3D 

models to be compliant with new requirements.

B.10 There is no requirement to deliver an as-built TDP, including 3D geometry, to the government 

appropriate for the contract.

B.10.1 Provide clear definition including use cases that guide decisions about when as-built 

TDPs are required and the content that is required.

B.10.2 Define a framework that communicates the data content and the form of that data.

B.10.3 Provide tools that support the automated capture of needed as-built information and 

provide mechanisms to assure compatibility of the available data with the requirements 

of the contract.

B.10.4 Clarify data right issues associated with the as-built TDP and document general findings. 

(Understanding the specifics will be negotiated with each contract)
42

B.10.5 Provide tools that support the capture of configured product structure and the ability to 

maintain the as-built TDP.

B.10.6 Provide the capability to automatically reconcile as-built with the as-designed and as 

planned

B.11 Emerging tools support a portion of the need set, but they support pieces of the solution and 

are not working toward a comprehensive solution to the TDP vision.

B.11.1 Identify population of supporting tools in context of those issues above that have cited 

tools as part of their solution.

B.11.2 Raise the visibility of the DEDMWG activity to the level required to achieve the critical 

support, and enrich that activity to address all encompassing solutions.

B.11.3 Develop and distribute the DEDMWG strategic plan as a guidance document to industry.

B.11.4 Provide incentives to the technology vendor communities to work together toward the 

vision to provide comprehensive interoperable solutions.

PPD Team Balloted Prioritized Solutions:

The following is a listing of the PPD team consolidated top fifteen solutions as they were presented on 

the ballot for voting at the end of the workshop.

B.1.4 Create a comprehensive description of the data required for the TDP.

B.4.0 Provide adequately annotated models.

B.4.3 Identify TDP content - and specifically annotation requirements at each level of maturity in the 

product realization process.

B.4.1 Achieve a clear definition of and standards to support a fully annotated model across 

government and industry including LOTAR.

B.4.4 Develop a standard for annotation for different product types based on part classification.

B.5.4 Extend the STEP standards to fully address interoperability requirements.

B.5.6 Create international partnerships to leverage and assure consistency of interoperability 

standards.

B.7.2 Establish manufacturing (including the extended enterprise) use cases that communicate exactly 

what the government needs in a TDP. Include narrative documents with geometric data. 

B.7.1 Evaluate tools and methods that exist and define gaps. Benchmark to identify and establish best 

practices.

B.9.4 Provide a robust tool set that supports the migration of 2D models to 3D models including the 

capture of relevant information and the migration of non-annotated 3D models to be compliant 

with new requirements

B.2.3 Define best practices and standards for MBE and mechanisms for enforcing them 

B.5.3 Develop a validated translation process for delivering TDP information to the government. 

Establish an independent validation authority (could be design check software)

B.11.3 Develop and distribute the DEDMWG strategic plan as a guidance document to industry.
43

B.8.5 Achieve an MBE presence and voice in IT strategy. This will be accomplished by participation in 

forums and meetings.

B.3.4 Conduct an ROI analysis substantiation MBE value and communicate to PMs and PEOs.

(consensus)
44

3.3 Group C – Provisioning, Logistics, and Sustainment

People who need the TDP to contain the information required to sustain their acquisition though out its 

life time participated in this breakout group. This is the area of use that first comes to mind when 

thinking of TDP users. If the TDP contains inadequate descriptions of form, fit, and function then users 

and supporters of the equipment during the use cycle have a difficult and expensive time ahead of 

them. 

For the purposes of scope and “framing,” the PL&S team aligned with the current Defense Acquisition 

Management System20 overlaid with the PL&S Scope focus highlighted in Figure 4

Figure 4 Figure 5.3.2 PL&S Team Scope of Coverage versus Acquisition Life Cycle Phases

As an acquisition program is initiated, key PL&S needs are identified, developed in conjunction with the 

overall phased development of a program and are fully defined and in-place by the Operations & 

Support phase. A key to successful PL&S - fully prepared, efficient, and cost effective - is its early 

involvement (at the beginning) in a program.

Additionally, the Acquisition life cycle phases are not to scale with respect to overall program cost. As 

shown in Figure 4, depending upon the source/system, Operations & Support may be between 65 to 

80% of the life cycle cost and are largely determined in the early phases.21 PL&S actions and needs are 

intimately linked to the early phases of design and are also driven by early considerations of the 

eventual full life cycle of the system. Figure 5 graphically makes the point that the Operations and 

Support portions of the live-cycle contribute 65% to 85% of the total life cycle costs. Obviously anything 

that can be done earlier in the life-cycle that impacts the efficiency this portion will have a large leverage

factor.

 

20 Department of Defense Instruction 5000.02, December 8, 2008; from 

http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf

21 http://www.acq.osd.mil/sse/briefs/GEIA_ETM_07_DesigningforSustainmentwith_SE_Hardy.pdf
45

The PL&S team was well versed in routine nomenclature and proceeded into assessing the PL&S current 

state. However, the following nomenclature was added post workshop to enhance the readers 

understanding of the terms and perspectives used by the PL&S team.

Working Definitions:

22

Logistics - (DoD) Planning and executing the movement and support of forces. It includes those aspects 

of military operations that deal with: a. design and development, acquisition, storage, movement, 

distribution, maintenance, evacuation, and disposition of materiel; b. movement, evacuation, and 

hospitalization of personnel; c. acquisition or construction, maintenance, operation, and disposition of 

facilities; and d. acquisition or furnishing of services.

Production Logistics - (DoD) That part of logistics concerning research, design, development, 

manufacture, and acceptance of materiel. In consequence, production logistics includes: standardization 

and interoperability, contracting, quality assurance, initial provisioning, transportability, reliability and 

defect analysis, safety standards, specifications and production processes, trials and testing (including 

provision of necessary facilities), equipment documentation, configuration control, and modifications.

Provisioning - (Army) A management process for determining and acquiring the range and quantity of 

support items necessary to operate and maintain an end item of materiel for an initial period of service. 

Specific types of provisioning are as follows: Initial provisioning: first-time provisioning of a new end 

item; follow-on provisioning: subsequent provisioning of the same end item from the same contractor; 

re-provisioning: subsequent provisioning of the same end item from a different contractor.23

 

22 Unless otherwise indicated; the definition source is: Joint Publication 1-02, DoD Dictionary of Military and 

Associated Terms, as amended through 31October 2009 located at http://www.dtic.mil/doctrine/dod_dictionary/

23 From Army Regulation 700–18, Logistics; Provisioning of U.S. Army Equipment, Headquarters Department of the 

Army Washington, DC, 20 September 2009

(Note: (although depicted with the prior 5000.01 life cycle phases the notional % ‘split’ is the 

same for the O&S phas

Figure 5 Relative Cost of a Program to Life Cycle Phases
46

Initial Provisioning - (DoD) The process of determining the range and quantity of items (i.e., spares and 

repair parts, special tools, test equipment, and support equipment) required to support and maintain an 

item for an initial period of service. Its phases include the identification of items of supply, the 

establishment of data for catalog, technical manual, and allowance list preparation, and the preparation 

of instructions to assure delivery of necessary support items with related end articles.

Sustainment - (DoD) The provision of logistics and personnel services required to maintain and prolong 

operations until successful mission accomplishment.

3.3.1 Deficiencies or Barriers

To better focus discussion, the PL&S team decided to address Provisioning and Logistics from a ‘prefielded’ perspective, i.e., the time period in the life cycle BEFORE materials/items are put into actual 

field use. Sustainment on the other hand was addressed from a ‘post-fielded’ perspective, i.e., the time 

period in the life cycle AFTER materials/items are put into actual field use.

The following narrative provides insight to the major Deficiencies and/or Barriers along with Emerging 

Best Practices found by the group. A ‘bullet’ view of key points is also provided in Table 3.

Provisioning (pre-fielding)

The PL&S team perceived a lack of representation and upfront involvement of all key stakeholders in the 

conceptual phase for the Integrated Project team (IPT) data call as a significant deficiency. This also 

extended to a lack of prime contractor support people not as involved as they should be upfront. This 

participation is essential in addressing another area of concern: inadequate identification of 

requirements upfront. Although improving personnel involvement can be addressed, another frequent 

barrier it the lack of adequate contractual language - resulting in not getting the right requirements in 

the contract. 

The clarity of TDP contents for provisioning needs improvement as identified by the example that in 

many cases the Engineering Data or Supplemental Data for Provisioning (EDFP/SDFP) was not provided 

or was insufficient. Better awareness is needed about how the Source Maintainability and Recoverability 

(SMR) code analysis drives the requirement for the TDP. Likewise, improvements to generating the 

Logistics Support Analysis Record (LSAR) were identified. The LSAR is essentially a Provisioning Bill of 

Material (PBOM) that helps generate the data that feeds the Provisioning Master Record (PMR).

However, this key piece of information is manually entered - while it could and should be automatically 

derived from the Engineering Bill of Material (EBOM). For new future systems the desire would be to get 

it from the Product Life-cycle Management (PLM) system.

Several data concerns were identified as problematic. Often, there is embedded proprietary data that 

can’t be provided in the TDP. Data received from a Prime contractor may lack all OEM data or not 

contain OEM data at all – due to OEM restriction concerning the information. Metadata about the 

product is not searchable and therefore the true contents are difficult to ascertain and use. Mislabeling 

of data found in TDP also contributes to data completeness and quality concerns.

Another key deficiency is the lack of resource manpower to thoroughly review a TDP coupled with a lack 

of training in using the data that’s received and lack of knowledge in understanding the data elements 

and content. By example - training to know what is stock listed and what is not is important to assessing 

and determining provisioning requirements.

The PL&S team also identified some emerging ‘best’ practices in the provisioning area. Some prime 

contractors are adopting automatically derived Bills Of Materials (BOMs) – thus providing a view of the 

same baseline BOM data and can also see the spare parts that will be needed. In another best practice, 
47

the DLA has incorporated updates to the provisioning processes and practices for DLA to participate as a 

key stakeholder from the beginning of a weapons systems program. One example of DLA inclusion is 

found in the Air Force’s Integrated Life Cycle Management (ILCM) guidelines, policies, and procedures.

24

Another example is in an ARMY regulation which now “requires provisioning personnel and materiel 

managers to be members of the weapons system integrated product team.”

25

Logistics (pre-fielding)

Upon examining the logistics area, the PL&S team highlighted the problems of disjointed or fragmented 

processes: A flowchart of the processes would help to better understand what data might be available 

or should be available and when in the overall system lifecycle that data should be made available in a 

TDP. Problems are further compounded with logistics products that are not integrated (e.g., technical 

publications are not linked to TDP and model data), thus contribute to a disjointed data feed, use, and 

dissemination process. 

As found in the provisioning discussion, there is a strong need for clarity on TDP contents supporting

logistics within DoD Services and Prime contractors. There is lack of clarity on what constitutes the 

“model.” At times, there is improper requirement determination as supplied by the Services. Often 

there are inaccurate data feeding advanced planning and scheduling – systemic inaccuracies due to nonintegrated stovepipe systems – which may contain conflicting and redundant data. Another data 

complication is that once model data comes from a PLM system, you lose important associations from 

within that PLM system. Data incompleteness may result from a shift in support philosophy. For 

example, the assumed maintenance philosophy in pre-fielding may differ from the actual practice in 

post fielding and may result in not having the data. 

The number of Non-descriptive National Stock Number (NSNs) is a deficiency that could be resolved 

with better TDP contents. This could move all NSNs to Type 1 (fully described) and greatly enhance the 

efficacy of NSNs for logistics management.

The PL&S team identified several emerging ‘best’ practices in the Logistics area. There are currently

enough information standards in existence to define TDPs that are valuable although some are not fully 

matured. Three-D (3D) technical publication capabilities are emerging that will be compliant with 

S1000D.

26 There is strong advancement and momentum on Model Based enterprise (MBE) concepts and 

 

24 AIR FORCE INSTRUCTION 63-101, ACQUISITION AND SUSTAINMENT LIFE CYCLE MANAGEMENT, 17 APRIL 2009; 

found at http://www.af.mil/shared/media/epubs/AFI63-101.pdf “3.97. Weapon System Support Program (WSSP). 

AF participation in this DLA managed program is key to receiving the appropriate level of support to AF weapon 

systems from DLA. The AF identifies all weapon systems that use DLA consumables, how important the system is to 

the AF mission, the National Stock Numbers (NSNs) assigned to each weapon system and how critical each NSN is 

to a weapon system. DLA uses this information to plan, program, and budget for support to weapon systems. This 

program applies to all organic and contractor supported weapon systems that utilize DLA supported items, 

including classified systems. The implementation guidance for this program is contained in AFMAN 23-110, Volume 

1, Part 1. Each PM with systems that use DLA NSNs shall fulfill the Weapon System Support Program (WSSP) 

responsibilities. These responsibilities begin prior to the first provisioning conference and end when DLA parts are 

no longer required to support the weapon system and the weapon system is removed from the WSSP database.”

25 Army Regulation 700–18, Provisioning of U.S. Army Equipment, 20 September 2009 found at: 

http://www.army.mil/usapa/epubs/pdf/r700_18.pdf

26 From http://www.s1000d.net/: S1000D is an international specification for the procurement and production of technical 

publications. While this definition appears to restrict its use to technical publications, it has been found through application 

that the principles of the specification can also be applied to non-technical publications.
48

practical application and TDP maturity through the use of CAD neutral 3D viewing tools. Awareness is 

increasing across DoD at high levels as evidenced by the Quadrennial Defense Review (QDR) emphasis 

on requiring and acquiring technical data and a legislative proposal to better define form, fit and 

function.

Sustainment (post fielding)

As the PL&S team continued discussion into the Sustainment area, data deficiencies become even more 

apparent. Fundamentally, all too often, there is insufficient data for re-procurement, re-competition, 

demilitarization, disposal, and end-of-life actions. All too often, depots and support organizations are 

stuck with legacy data that may not be entirely correct. The real questions is “What do we do with it?”

Additional data complications arise when over the life of a system suppliers and their data disappear -

resulting in Diminishing Manufacturing Sources and Material Shortages (DMSMS).

27 Likewise, the 

unexpected lengthening of product life cycle - over the original plan - introduces additional data 

requirements that were not anticipated during the initial systems start-up. Use of NSNs for these legacy 

systems may be difficult since what’s required for Type 1 (fully described NSN) may be less than what’s 

fully available (metadata-wise). And, in a dynamic information environment, how can you accommodate 

adding new information into a legacy TDP to support NSN Type 1 description needs? 

There are problems with Warfighters’ access to accurate and sufficient data. Getting the data to the 

Warfighter and their support organizations is problematic with both the type of data being received and 

ability to get to the field. Key hurdles involve lack of systems interoperability and translation problems in 

conveying data. There are a plethora of legacy tools, software, and equipment. Additionally, the support 

workforce often does not have expertise in using tools and may not have needed software. Problems 

with using modern software applications were amplified by authorization hurdles and delays due to 

inconsistent and restrictive Directorate Office Information Management (DOIM) policies for deploying 

network based applications.

One barrier to moving toward a more model based environment and model supported TDPs involved 

the increased burden on small vendors. If a part is to be bid competitively, then the model must be 

made available to all vendors including the small ones. But in many cases, an elegant model based 

technical solution may not be possible due to the inability of small vendors to process or perhaps even 

view the models. Currently, prime contractors provide both 2D drawings and 3D models. Since the 

government will not provide a 3D viewer, the burden falls on the vendor to make the upfront capital 

investment.

Problems with inefficient data processing and business processes were also identified. One example is 

the time lag between request and procurement in the QDR (Quality Deficiency Report) process and 

Form 33928 collaboration between the Services and DLA. Another is that the process of change 

notification to DLA is broken regarding Time Compliance Technical Orders /Modification Work Orders

29

, 

(TCTO/MWO).

 

27 Defined as: "The loss or impending loss of manufacturers of items or suppliers of items or raw materials." From 

Department of Defense regulation 4140.1-R, DoD Supply Chain Management Regulation

28 DLA Form 339 is the vehicle used to provide technical and engineering support necessary for the procurement 

and manufacture of spare parts required to support equipment, due to diminished manufacturer sources or 

obsolescence.

29 TCTO five categories: Immediate action, Urgent action, Routine action, record, interim. (e.g. a TCTO of 

‘Immediate’ is a kit of instructions/parts to resolve a safety condition which could result in fatal/serious injury to 
49

It is difficult to keep a sustainment BOM current due to poor configuration management control - how 

do you keep the configuration current if you don’t communicate changes? By example - prime

contractors deliver “as delivered” data but the Services may modify for an “as-used” configuration. 

Without configuration management data is lost between the two. Another combination business 

process and data configuration example was the case of a common part used by multiple Services with 

each assigning NSNs resulting in multiple NSNs for same part.

Many of these problems were attributed to a lack of authoritative source and control resulting in 

multiple copies of TDPs being out-of-sync. Without a single authoritative source or at least one system 

that pulls it together, the result is multiple services with different manuals with fundamentally the same 

data. Also, since not all metadata is captured in searchable formats including rather extensive use of 

comment text fields and non-electronic documentation, the ability to quickly find data, assess for 

completeness, make consistent interpretations, and perform consistent transmissions is compromised.

While some emerging practices were identified for sustainment by the PL&S team, in one case the lack 

of adoption by DoD and agreement on whether or not a practice was ‘best’ served to highlight there is 

still much opportunity for better understanding and improvements. Boeing, for its commercial 

customers, has a single point data access portal yet when offered to the military, the response was each 

Service required its own product thus highlighting the problem of stovepipe perspectives. Also, there is 

the case of the legacy. The highly revered and effective Browning M2 .50 caliber, machine gun has been 

produced for the US Military since 1933. Reverse engineering was applied to create a data model to be 

used to enhance/improve/replace old data for design and manufacturing. Yet while this got the job 

done, it was questioned as “Is this really an emerging best practice?” or rather a creative and effective 

way to overcome the data gaps and lack of complete and quality data practices typically seen with 

legacy systems. This lack of vision is seen as a deficiency.

Table 3 Current state table for provisioning, logistics, and sustainment.

Current State of Provisioning, Logistics, and Sustainment

Deficiencies or Barriers Emerging Best Practice

Sub Category Provisioning (pre-fielding)

 Lack of representation in conceptual phase Integrated 

Project team (IPT) data call of all key stakeholders – lack 

of upfront involvement – Prime support people are also 

not involved as they should be upfront

 Requirements identified inadequately upfront

 Inadequate contractual language - not getting the right 

requirements in the contract

 Need clarity on TDP contents for provisioning

 The Engineering Data or Supplemental Data For 

Provisioning (EDFP/SDFP) was not provided or was 

insufficient (many causes).

 Source Maintainability and Recoverability (SMR) code 

analysis drives the requirement for the TDP– needs to be 

 DLA has incorporated updates to 

provisioning processes and 

practices as policy/procedure for 

DLA to participate upfront as a 

key stakeholder ‘from the 

beginning’ of a weapons systems 

program:

o Air Force - As part of the 

Integrated Life Cycle 

Management (ILCM) 

guidelines, policies and 

procedures for the Air Force 

(AF).

 

people or valuable prop; ‘Urgent’ is to resolve a potentially hazardous condition that could result in injury to 

personnel or damage to property); MWO is used to record details of work done and the certificates of tradesmen.
50

Current State of Provisioning, Logistics, and Sustainment

Deficiencies or Barriers Emerging Best Practice

better awareness of this driver.

 Logistics Support Analysis Record (LSAR) – Provisioning Bill 

of Material (PBOM) - is a key piece of information that is 

manually entered - it should be derived from the 

Engineering Bill of Material (EBOM (master design BOM). 

It generates the data that feeds the Provisioning Master 

Record (PMR). For new future systems the desire would 

be to get from the Product Life-cycle Management (PLM) 

system.

 Knowing what is stock listed and what is not.

 Embedded proprietary data that can’t be accessed in the 

TDP.

 Data from Prime may lack or not contain OEM data – OEM 

restricts information.

 Metadata about the product is not searchable.

 Mislabeling of data found in TDP.

 Lack of resource manpower to thoroughly review a TDP

 Lack of training in using the data that’s received and lack 

of knowledge in understanding the data elements and 

content.

o Army - “Requires provisioning 

personnel and materiel 

managers to be members of 

the weapons system 

integrated product team.”

 Primes are adopting derived Bills 

Of Materials (BOMs) – a view of 

the same data and can see the 

spares.

Sub Category Logistics (pre-fielding)

 Disjointed or fragmented processes.

 Need clarity on TDP contents for logistics – on both sides, 

DoD Services/DLA and Prime.

 Clarity on what constitutes the “model” – e.g. CAD solid 

with an associated document.

 Improper requirements determination supplied by the 

Services.

 Inaccurate data to feed advanced planning and 

scheduling – systemic inaccuracies due to non-integrated 

stovepipe systems – may contain conflicting/redundant 

data.

 Once ‘model data’ comes from a PLM system, you lose 

associations from within that PLM system.

 The assumed maintenance philosophy in pre-fielding 

may differ than actual practice in post fielding and results 

in not having the data.

 Logistics products are not integrated – technical 

publications are not linked.

 Non-descriptive National Stock Number (NSNs) – a better 

TDP could move all NSNs to Type 1 (fully described).

 Enough information standards 

are in existence to define TDPs 

that are valuable – some exist 

but are not fully matured.

 3D technical publication –

emerging – will be compliant 

with S1000D.

 Quadrennial Defense Review 

(QDR) - emphasis on requiring 

and acquiring technical data.

 Legislative proposal to better 

define form, fit and function.

 Advancement and momentum on 

Model Based enterprise MBE and 

TDP.

 Maturity of CAD neutral 3D 

viewing tools.
51

Current State of Provisioning, Logistics, and Sustainment

Deficiencies or Barriers Emerging Best Practice

Sub Category Sustainment (post fielding)

 Insufficient data for re-procurement, re-competition, 

demilitarization, disposal, end-of-life.

 What’s required for Type 1 may be less than what’s fully 

available (metadata-wise) - in a dynamic information 

environment how can you accommodate adding new 

information for Type 1 description incorporated in a TDP?

 Stuck with legacy data that may not be entirely correct –

what do we do with it? Need proactive strategic position

 Unexpected lengthening of product life cycle – introduces 

additional data requirements.

 Suppliers and their data disappear - Diminishing 

Manufacturing Sources and Material Shortages (DMSMS) 

 Type of data being received and ability to get to the field –

media not getting to the field – problems with Warfighter 

access to accurate and sufficient data.

 Interoperability, translation problems in conveying data 

 Plethora of legacy tools, software and equipment (Note: 

the Long Term Archiving and Retention (LOTAR) standards 

effort is working).

 Workforce does not have expertise in using tools, may not 

have software.

 Directorate Office Information Management (DOIM) –

authorization hurdles/delays.

 If a competitive part, must make model available to small 

vendors, therefore an elegant technical solution may not 

be possible (inability of small vendors to process models).

 Currently provide 2D and 3D but 2D is the master and 

language says government will not provide 3D viewer –

burden is on the vendor.

 Time lag between request and procurement – QDR 

(Quality Deficiency Report) process and Form 339 

collaboration between the Services and DLA.

 Sustainment BOM is not kept current because of poor 

configuration management control - how do you keep 

the configuration current if you don’t communicate 

changes?– Primes deliver “as delivered” data but Services 

may modify for an “as-used” configuration ...thus loss of 

configuration management between the two.

 Lack of TDPs at Depot (assumed mfg team should handle).

 Process of Time Compliance Technical Orders /

 Boeing, for it’s commercial 

customers, has a single point 

access portal yet when offered to 

military the response is each 

Service has it’s own product.

 50 caliber – reverse engineering 

or took old data to create data 

model – Boeing term, “convert on 

demand” Gets the job done, but is 

this really an emerging best

practice?
52

Current State of Provisioning, Logistics, and Sustainment

Deficiencies or Barriers Emerging Best Practice

Modification Work Orders, (TCTO/MWO) notification of a 

change to DLA is broken.

 Lack of authoritative source and control resulting in 

multiple copies of TDPs that are out of sync.

 Lack of a single authoritative source or at least one 

system that pulls it together – e.g.’ same aircraft, multiple 

Services with different manuals, yet it’s fundamentally the 

same data.

 Common part used by multiple Services but assign unique 

NSN resulting in multiple NSNs for same part.

 Not all metadata is captured in searchable formats -

extensive use of comment text fields and non-electronic 

documentation.

3.3.2 Vision

In the future, a universal policy will be in place and followed to assure all 

stakeholders are involved in conceptual upfront data calls and the TDP 

requirements are clearly identified for all users in the system life cycle. All 

contractual rights to data are fully exercised to define and assure delivery 

of a TDP with ‘full and complete rights data’ in the form of a fully 

annotated and certified model. The TDP configuration is managed to 

assure data is accessible electronically to all who need access and from an 

authoritative source. The user community is well trained and capable 

with access and tools to search all metadata. TDP data is integrated with 

technical manuals, derived from bills-of-materials, and seamlessly feeds 

into other systems and uses.

This vision is built upon the following elements developed by the PL&S team:

 A clear and universal policy (DoD 5000 series) is followed - where all stakeholders are involved in 

the conceptual upfront data call, and clearly identifies the TDP requirements for all users;

 All rights are exercised; 

 All TDP requirements are clearly stated as contracted deliverables, are delivered, and are 

maintained;

 The right/complete content is in place; 

 All TDP needs for PL&S are contained in and supported by a fully annotated and certified model

 Certified TDP – Who, How, & When is clearly defined and understood

 The TDP is complete enough to sufficiently support maintenance activities - supports a full kit 

consisting of: automated work order, parts, tools and technical data;

 An authoritative source is in place;
53

 Whoever needs the data can get to the authoritative source;

 Technical data is distributed electronically to all users; and all users have the capability to use it;

 Fully integrated TDPs, technical manuals, BOMs, etc.; and

 Metadata is fully searchable.

3.3.3 Issues and Solutions

The Provisioning, Logistics, & Sustainment Team identified and further developed eight30 major PL&S 

Issues dealing with TDPs and listed below. The complete table of Issues and all solutions generated is 

shown in Appendix A-3. 

 Lack Of Complete Definition Of TDP

 Weak Contracting And TDP Requirements Definition –

 Need Attention To TDP/Model Certification And Validation

 Poor Data Content For Life Cycle Support –

 Lack Of Clear Authoritative Source –

 Inability To Reuse And Leverage Data –

 Need Improved NSN Descriptions From TDPs –

 Data Availability And Utilization

 Impacts Of Aging And Lengthening Of Life Cycle

 Workforce Readiness And Resources – (This Issue Belongs In Policy & Management)

Eight of these iIssues and their high-priority solutions are discussed in the following section, followed by 

a listing of the team’s consolidated top eleven solutions as they were presented on the ballot for voting 

at the end of the workshop.

Section format 

C.x Issue 

C.x.y Solution

C.1 Need for complete and detailed standard definition of TDP across all Services: Need to evolve to 

standard references for contracting purposes. Includes uniform and standard nomenclature 

with terms and their definitions. Need to clarify what constitutes model based support for TDP.

C.1.1 Develop and publish DoD TDP standards and related documents, e.g. Data Item 

Descriptions (DIDs)

C.1.2 Work towards an international standard – leverage existing standards work and new 

DoD standard

 

30 Note: A total of 10 were identified, but one was thought to be within the purview of the Policy and Management 

team and the other was not developed further due to more focus on ‘up-front’ issues. Both issues are contained in 

this narrative section.
54

C.2 Lack of upfront involvement and inadequate contract language: There is a lack of upfront 

involvement across the stakeholder community. All stakeholders need to define the 

requirements and the contract needs to reflect the requirements. Inadequate contractual 

language is not getting the right PL&S requirements in the contract. 

C.2.1 Expand use of Automated tools – SYSPARS/SMART-T to assist in developing program and 

contract documents.

C.2.2 Institutionalize involvement policies across Services – clarify and promote the need with 

strong business cases

C.2.3 Develop appropriate contract language and clauses – tied to standard

C.2.4 Assess execution activity- to confirm delivery of TDP

C.3 Need to address the definition, contents, and management of TDP certification and validation: 

Who, how and when – oversees the delivery and acceptance of a TDP

C.3.1 Define who, how and when in conjunction with policy development – the “how” also 

driven by standard: “who” and “when” can start without a standard

C.4 TDPs often don’t contain all the information users need throughout the lifecycle: May be 

mislabeled, incomplete, inaccurate, conflicting, redundant and/or not searchable. Model data is 

disconnected from source system.

C.4.1 Develop a set of assessment rules for creating modernized data to support legacy 

weapons system needs

C.4.2 Develop a tool kit/environment for cost effectively data modernization

C.4.3 Identify cost effective tools and methods for developing, acquiring legacy part data –

2D, 3D, whatever fits the need

C.5 Lack of authoritative source and control of the TDP: Multiple copies of TDPs that are out of 

sync, as delivered and as used, are not configuration managed. There are multiple sources and 

each thinks they are THE authoritative source. Due to data manipulation to meet mission 

requirements, the data is modified and is not fed back to the originating/originating source. 

Thus, it’s out of sync, redundant, multiple systems. Within some Services there is a lack of a 

modern repository environment. Who controls and who is the authoritative source for a 

common part? How do we know/assure that the most current TDP is up to date?

C.5.1 Develop requirements to utilize Global Combat Support Systems (GCSS) efforts 

(Enterprise Requirements Planning - ERPs) within and across the Services to facilitate 

Product Lifecycle Management (PLM) 

C.5.2 Develop and establish a policy for an official master authoritative data source for each 

TDP 

C.5.3 Identify current potential authoritative sources

C.6 Lack of ability to reuse and leverage product data: To derive other data products such as tech 

manuals, BOMs, to support all the subsequent as delivered, as used, as maintained, as designed, 

etc. needs across the life cycle.

C.6.1 Define modern repository requirements and architecture options, use of existing ERPs, 

JEDMICS, others including new commercial solutions. Note: there are multiple 
55

implementation options, but one with promise is primes-to-DoD mirroring. Leverage 

prime capability (tie into definition of data requirements)

C.6.2 Develop/discover standards based tools that take advantage of data viewing and 

exchange

C.6.3 Develop and prove out capability to link TDPs to tech documents and other deliverables

C.7 Need to make it easier for parts reuse and interchangeability How can the data from a model 

supported TDP be defined, acquired and utilized to improve NSN full descriptions?

C.7.1 Continue to push for parts management and leverage in progress Services and DLA 

activities

C.8 Inadequate and insufficient data access, formats, availability - poor data access, inconsistent 

formatting and overall lack of availability hinder broad based use across all the user domains. 

Users need to be able to access the authoritative source in a form that they can readily use.

C.8.1 Leverage authoritative source assessment and development work. 

C.8.2 Develop and approve mechanisms that enable role based access to TDPs. 

C.8.3 Drive development of data formats – PLCS (AP-239)

C.8.4 Provide low cost readers to some classes of users 

PL&S Team Balloted Prioritized Solutions:

The following list contains the PL&S team’s consolidated top eleven solutions as they were presented on 

the ballot for voting at the end of the workshop.

C.1.1 Develop and publish DoD TDP standard and related documents.

C.2.1 Expand use of Automated tools – SYSPARS/SMART-T.

C.2.2 Institutionalize involvement policies across Services.

C.2.3 Develop appropriate contract language and clauses - tied to standard.

C.2.4 Assess execution activity - to confirm delivery of TDP.

C.3.1 Define who, how, and when in conjunction with policy development.

C.5.1 Develop requirements to utilize Global Combat Support Systems (GCSS) efforts.

C.5.2 Develop and establish a policy for an official master authoritative data source for each TDP.

C.6.1 Define modern repository requirements and architecture options.

C.6.3 Develop and prove out capability to link TDPs to tech documents and other deliverables.

C.7.1 Continue to push for parts management and leverage in progress Services and DLA activities.
56

3.4 Group D – Policy Management

Studies31,

32 and numerous reports indicate that DoD should strengthen policies for acquiring technical 

data needed to support weapons systems. They have found that even when there is a clear requirement 

for assessing the sustainment plans for a system the requirements lack sufficient detail to assure 

adequacy of the data. 

Figure 6 A summary of the document hierarchy that governs the typical DoD acquisition process.

The policies governing the acquisition process are many and varied as depicted in Figure 6. 

The program manager is the key individual responsible the final choice of what defines the contract 

deliverables. This position is often filled by individuals for fairly short portions of their careers and thus 

they often focus upon benefiting the Warfighter in the near term more than acquiring sufficient data for 

long term sustainment of the acquire item. However, SE Hardy33 reports that 65% to 80% of the lifetime 

cost of a weapons system occurs during operations and sustainment and a dollar spent reducing 

sustainment costs is 2 to 4 times more effective in reducing overall cost than if invested to reduce cost 

elsewhere. To encourage the program acquisition manager to support the need to acquire adequate 

technical data for sustainment may require addressing the governing policies, directives, and 

instructions.

This group enabled people who establish the business infrastructure governing protection and 

compliance in the acquisition process to influence the data content and form in a TDP since their 

 

31

 GAO-06-839 DoD Should Strengthen Policies for Assessing Technical data Needs to Support Weapon Systems

32

 GAO-04-715 Opportunities to Enhance the Implementation of Performance-Based Logistics

33

 http://www.acq.osd.mil/sse/briefs/GEIA_ETM_07_DesigningforSustainmentwith_SE_Hardy.pdf
57

business, security, commercial, and compliance rules will dictate how the model based enterprise share 

much of this data.

3.4.1 Deficiencies or Barriers

The members of the Policy Management breakout group identified twenty specific deficiencies or 

barriers that are perceived to prevent or hinder effective formulating, disseminating, or implementing 

policies that would require 3D-model based technical data packages (TDPs). The entire list of these 

deficiencies and barriers is shown in Table 4

The deficiencies/barriers and emerging best practices listed above can be consolidated into four moregeneral categories:

 Management, accountability, and culture;

 Data format, configuration control, obtaining the appropriate data in the appropriate 

format, and long-term data retention;

 Cost and funding constraints, and lack of empowerment; and

 Conflicting and inconsistent policies and regulations regarding TDPs.

Management, Accountability, and Culture

The Policy Management Group noted that short-term management cycles of active leadership make it 

difficult to establish a TDP consistent policy within an organization because a typical DoD program 

manager stays in the position on average three to five years, while the life of a program is generally 

much longer. Because of these frequent rotations of job function, there is a lack of accountability for 

ensuring the adequate and appropriate TDPs are procured and maintained.

Although MIL Standard 31000 defines what a TDP comprises, there is too much flexibility at the point of 

execution (across program offices), which exacerbates the lack of accountability for failure to obtain 

technical data. The group noted that there is a “rice bowl” (a.k.a. “stove pipe”) structure in which the 

unwritten rule is that “it’s every program manager for himself.” It is difficult to overcome a culture of 

historical practices and processes that have existed for the past 60 years (the “we’ve always done it that 

way” syndrome).

The DFARS 252.227-7013 defines and describes DoD rights in non-commercial technical data in general 

terms. The group noted that enforcement of those data rights is inconsistent and sometimes does not 

occur. The lack of a mandatory acquisition milestone gate was cited as another reason that appropriate 

TDPs are not being procured.

Data Format, Configuration, Control, Appropriate Data, and Data Retention

Although MIL Standard 31000 defines the elements of a TDP, the standard does not adequately address 

configuration history. As modifications and in-production changes occur throughout the life of a major 

program, the TDP should also be modified to reflect the as-built configuration of the product. 

Disseminating and managing the TDPs across the product life cycle becomes a major challenge. 

Obsolescence of equipment during the life of a program can also affect the adequacy of a TDP. In some 

cases a TDP that was adequate and appropriate at the time of procurement becomes unusable because 

the hardware and/or software that is required to read and process the information becomes obsolete.

Cost/Funding Constraints and Lack of Empowerment

The group observed that virtually no one who is empowered to make policy decisions has a full 

understanding the importance of appropriate, model-centric TDP’s that are available throughout the 

entire program life cycle. Because funding for major DoD programs is always limited and there is always 
58

pressure to reduce costs, the cost of TDPs frequently come under scrutiny. When called upon to make a 

business case for the cost of a TPD, the program manager often has no effective life cycle cost models or 

other tools to develop and defend a business decision. The group noted that some more-recent policies 

include objectives to consider life cycle costs.

Conflicting and Inconsistent Policies and Regulations Regarding TDPs

The acquisition of intellectual property and other data rights is not uniformly or adequately enforced 

across the DoD. The flow down of requirements (e.g. the definition of technical data) is inconsistent 

across the service branches. Although DoDI 5000.02 contains several references to technical data, it 

does not definitively define technical data requirements. There are also other policy, directive, and 

instruction conflicts – for example, from the Director of Information Management (DOIM) – that inhibits

the implementation of needed and effective tools.

Table 4 Current state table for policy management

Current State Table for Policy Management

Deficiencies or Barriers Emerging Best Practice

 Short-term cycles of active leadership leads to 

focus on short term results.

 Culture – The inertia of historical practices and 

processes (the way we have been doing it for 

the past 20-30 years) must be overcome.

 Rice bowl (stove pipe structure) – span of 

responsibility is too narrow for a major 

systematic change like basing a TDP on 3D 

models.

 Organizational readiness – to what degree is the 

organization prepared? Going from 2D to 3D 

requires technical upgrades and training to all 

impacted organizations.

 Lack of accountability (often because of job 

function rotations). Once the acquisition 

manager has rotated to his next assignment he 

is no longer accountable for the success of his 

acquisition, i.e. during its’ operation and 

sustainability phase.

 Too much flexibility at the point of execution 

(across the program offices), therefore leaving 

no accountability for failure to obtain tech data

 Lack of an acquisition milestone gate

requirement has allowed failure in procuring 

adequate technical data 

 Life cycle cost models fail to adequately include 

the operations and sustainment phase during 

initial design, development, and production.

 Other policies/regulations conflict and inhibit 

the procurement of needed and effective tools, 

e.g. Directory of Information Management 

 Objectives to consider lifecycle costs being 

included in policies.

 LOTAR (Long-term archival and retrieval of 

data – Develops technology and NAS 

standards (owned by AIA) ASD (European 

equivalent).

 SYSPAR (Army) and SMART-T (Navy) are 

examples of expert assistance tools.

 PLM systems, with an interoperable layer, 

are an emerging solution that allows us to 

gather the data that feeds in.
59

Current State Table for Policy Management

Deficiencies or Barriers Emerging Best Practice

(DOIM) requirements for software security are 

sometime inconsistent and prevent integration 

and inhibit desired functionality (software, etc.).

 No one empowered to make policy decisions 

understands the entire life cycle.

 Enforcement of existing data rights is not 

occurring. (e.g. 252.227-7013 Rights in Technical 

Data – Non-commercial Data)

 Acquisition of IP and other data rights not 

uniformly or adequately enforced.

 Flow down of requirements is inconsistent 

across the service branches, e.g. DoD 5000.02 

does not define tech data requirements.

 MIL-STD-31000 defines what a TDP comprises 

but is not complete.

 Policy development not address in a way that 

drives industry and government in such a way 

that we get the TDP we need.

 Long term retention of data that accounts for 

systems obsolescence needed. Electronic data 

must be stored in a way that guarantees its 

readability throughout the product’s life.

 DoD requires a policy updates for the long-term 

retention of weapon systems’ data in whatever 

format require.

 The present MIL-STD-31000 TDP definition 

doesn’t adequately address configuration 

history.

 Money requirements. 3D models are perceived 

as expensive and thus detract from the 

acquisition’s ability to purchase more of the 

real product.

 There is no standard business case that PM’s 

can use to incorporate provisioning and 

sustainment costs. “It’s every PM for himself.”

3.4.2 Vision

Policies are in place to drive the DoD ownership of the technical data package 

containing all the critical data necessary to maintain an operating weapons 

system in a war theater environment.

The Policy Management breakout group enumerated the visionary elements of a policy that would 

support the goal of obtaining and maintaining model-centric 3D technical data packages. There was 
60

general agreement that procurement policy should be more definitive in requiring model-centric, 3D 

technical data packages. This is needed in order to minimize the flexibility of individual program 

managers to exclude such packages, and to ensure that the program managers are held accountable for 

obtaining appropriate technical data packages. 

Policy should support the inclusion of gates in acquisition milestones that would require the assessment 

of technical data to ensure that requested/provided data packages are appropriate to support 3D 

model-centric data requirements. There is a need to educate acquisitions and logistics personnel so that 

they fully understand and control existing data rights, and understand the value of technical data 

packages across the product life cycle. Policy should support the need for the Defense Logistics 

Information Service (DLIS) to have provisioning data before systems are deployed.

Policy should also ensure consistency of flow down requirements terminology, and it should not limit 

innovation and competition in the marketplace. Policy should support the exchange of data among all 

service branches in a neutral format, and it should support the implementation and utilization of 

commercial standards when and where appropriate. The group observed that policy should be written 

in such a way that it remains timeless, so as to remain priceless.

Specific vision elements included: 

 Policies are more definitive to minimize the flexibility of the PM.

 There will be gates at the acquisition milestones to assess technical data.

 Gaining the ownership of the technical data.

 There will be accountability of the PM for the responsibility of obtaining technical data.

 Full understanding of the value of the technical data across the life cycle. 

 DLIS (Defense Logistics Information Service – sub-agency of DLA) will have the provisioning data at 

the right time (before systems are deployed).

 Doesn’t limit innovation and competition in the marketplace.

 Consistency of flow down requirements terminology

 Every branch of service exchanges data in a neutral format.

 Policy is written in such a way that it remains timeless, so as to remain priceless.

 Implement and utilize commercial standards when and where appropriate.

 Agnostic viewer software is readily available and free.

 Existing data rights are understood and controlled.

3.4.3 Issues and Solutions

After identifying and discussing the deficiencies, barriers, and emerging best practices that relate to the 

implementation and management of policies that significantly impact TDPs, the Policy Management 

breakout group used the information to formulate fifteen significant issues for further discussion as 

listed below. There is no single entity accountable for technical data policy within OSD.

 Decision makers and policy makers who have the ability to mandate what should be done 

do not do so... fully appreciate total life cycle costs.
61

 Short term goals/objectives/drivers within program offices do not optimize life cycle 

sustainment costs. (The PM is being rewarded for short term successes rather than long 

term capabilities/requirements. Furthermore, the PM is not accountable to stakeholders 

and not held responsible for long term shortcomings.) Short term management cycles 

accentuate lack of accountability.

 The de facto process does not include a timely provisioning process to include the Defense 

Logistics Information Service (DLIS). 

 Current data rights are not uniformly or adequately understood and exercised.

 There is a lack of common terms, definitions, and industry standards within DoD policy and 

contractual flow-down documents with respect to technical data.

 Explicit direction on TDP content and delivery (CDRLs) is not given to the contractor.

 Fidelity and robustness of technical data contractually requested often does not provide 

what is really needed for sustainment. 

 The process of receiving data does not include a rigorous feedback loop for validating that 

the requested information has been received. The tech data procurement and receiving 

people are not communicating effectively.

 Parts demand data is not captured and provided to the DoD on contractor logistics support / 

performance-based logistics (CLS/PBL) contracts. Risk mitigation plans and requirements are 

not included in the language.

 Software OEMs don’t fully support data interoperability standards.

 Engineering Data Managers are “disappearing” and along with them the knowledge of what 

a TDP should include.

 Providers (program management and procurement personnel) to the data users (DLA parts 

providers, codifiers of the info, packaging people, depots, warfighter) are not educated in 

the technical data and data-rights environment.

 AS-9102 (First Article Inspection Report) is not currently required to be included as a part of 

the TDP.

 Industry knowledge of LOTAR (AN-9300 standards) practices is incomplete.

The complete list of fifteen issues and all of their associated solutions are tabulated in Appendix A-4. The 

top 10 issues and their associated solutions are discussed below. The 10 high priority solutions placed 

on the large group’s voting ballot are highlighted in yellow.

Section format 

D.x Issue 

D.x.y Solution

D.1 There is no single entity accountable for technical data policy within OSD. The requirements to 

acquire a TDP as part of an acquisition are scattered throughout the policies, instructions, 

manuals, FARS and DFARS to which an acquisition manager must comply. They are not 

consistent and sometimes only peripherally related to the TDP. 

D.1.1 Need to revisit DoD 5000.02 to better address TDP policy. 
62

D.1.2 Require a technical data engineering data management plan (EDMP) evaluation at each 

milestone review by an oversight board. 

D.1.3 Develop an oversight board that contains the data stakeholders.

D.1.4 Ensure that the life cycle support plan (LCSP) includes the cost and value requirements 

of TDP. 

D.2 Decision makers and policy makers who have the ability to mandate what should be done do 

not do so. Acquisition managers need to fully appreciate total life cycle costs. High level 

managers do not seem to fully appreciate that the largest portion of the life-cycle cost of a 

system is accrued during its operational phase and acquisition managers should pay to acquire 

information that will reduce overall cost.

D.2.1 Review the training program so that technical data is understood.

D.2.2 Implement accountability requirements associated with LCSPs.

D.3 Short term goals/objectives/drivers within program offices do not optimize life cycle 

sustainment costs. The PM is being rewarded for short term successes rather than long term 

capabilities/requirements. Furthermore, the PM is not accountable to stakeholders and not held 

responsible for long term shortcomings. Short term management cycles accentuate lack of 

accountability.

D.3.1 Create a rating associated with LCSP for the weapons system that is irrespective of the 

program manager.

D.4 The de facto process does not include a timely provisioning process to include the Defense 

Logistics Information Service (DLIS). The current stage gate process for major acquisitions does 

not include DLIS representatives in the early-on critical reviews and decision gates. They often 

aren’t invited until much later in the process where changes are much more difficult to effect.

D.4.1 A stronger policy statement is needed to ensure participation. Revise DoDI 5000.02 

and/or the DAG.

D.4.2 Ensure that an objective assessment of provisioning actions occurs during the 

acquisition milestone process. 

D.4.3 Enforce the requirement for DLIS participation at milestone review “B” and beyond. 

D.4.4 Establish/ensure a system to address modification updates affecting provisioning 

groups.

D.4.5 Include DLIS partnership/participation with the MILSVC in the SOW-generation process.

D.5 Current data rights are not uniformly or adequately understood and exercised. The government 

has certain rights to data associated with articles it procures. The rights are not fully understood 

by all acquisition managers and thus not acquired during the normal acquisition process. This is 

especially true if the vendor “pushes” back or disagrees. This is a normal part of negotiating a 

contract but only experienced acquisition personnel fully understand what is required to get 

what the government is paying for.

D.5.1 Add more resource Engineering Data Management Officers (EDMO) to the degree 

required to exercise technical data rights adequately. 

D.5.2 Provide/require training for all participants in the acquisition process.
63

D.5.3 Revise DoD 5000.02 to include Redstone Arsenal (Dayne Beam) recommended changes 

regarding GAO 06839 (Data Rights) report.

D.6 There is a lack of common terms, definitions, and industry standards within DoD policy and 

contractual flow-down documents with respect to technical data. Each service has its’ own data 

dictionary and technical definitions. Each is defined with the services’ particular flavor and thus 

different between the services. In time this can lead to substantial differences in these 

definitions and interpretation problems especially on joint service projects. 

D.6.1 Develop an authoritative glossary of terms and include it as a standard source document 

in an updated Defense Acquisition Guidebook.

D.6.2 Evaluate existing industry standards to be used as references for authoritative 

definitions.

D.7 Explicit direction on TDP content and delivery (CDRLs) is not given to the contractor. Vendors 

have become very good at giving the government exactly what was asked for in a contract and 

nothing more. Calling for a TDP is not sufficient. It must be defined explicitly and sufficiently 

before we can get all that we need.

D.7.1 Update MIL STD 31000 to have more explicit information on TDP content and delivery 

requirements.

D.7.2 Establish a team to advise policy makers regarding technical data format delivery.

D.7.3 Require that model-based TDPs specifying native-format files must also include 

validated neutral-format files (e.g. Pro-E and STEP-APs).

D.8 Fidelity and robustness of technical data contractually requested often does not provide what is 

really needed for sustainment. The current documents specifying the content and format of a 

TDP are insufficient and can fail to require important critical information 

D.8.1 Support the enhancement of ASME Y14.41 and other relevant standards. 

D.8.2 Ensure that all relevant contractual “boiler plate” references (both industry and military) 

are identified and included in requirements documents.

D.8.3 Review DOT FAA Order 8110.4 as an example of best practice for how to define the 

constituents of the TDP and engage with the AIA EMC (Engineering Management 

Committee) to provide guidance on TDP definitions.

D.9 The process of receiving data does not include a rigorous feedback loop for validating that the 

requested information has been received. The tech data procurement and receiving people are 

not communicating effectively.This issue has to do with evaluating the TDP received as a 

completion of a CDRL. The current process for validating that the TDP is sufficient does not 

guarantee that it really is. There is no standard method for assuring its validity

D.9.1 Ensure that in-process reviews are part of contractual requirements.

D.9.2 Ensure that Integrated Product Teams (IPTs) have procedures that define roles and 

responsibilities with respect to TDP life cycle support; if not, create them.

D.9.3 Enhance existing tools such as Smart-T and Sys-Par to assist in implementation of policy, 

and ensure that the tools are DoD wide. (Intelligent Specification Assistant)
64

D.10 Parts demand data is not captured and provided to the DoD on contractor logistics support / 

performance-based logistics (CLS/PBL) contracts. Risk mitigation plans and requirements are not 

included in the language.

D.10.1 Demand data should be provided regardless of sustainment/procurement method.

D.10.2 Configuration data should always be provided regardless of sustainment/procurement 

method.

D.10.3 Include exit-strategy in CLS/PBL contracts to mitigate risks.

D.10.4 Review the Quadrennial Defense Review (QDR) solution for form, fit, and function 

definition to ensure that it is adequate, and take action as necessary.

Policy Team Balloted Prioritized Solutions:

The Policy Team’s listing of its top ten solutions as presented on the voting ballot at the end of the 

workshop follow:

D.3.1 Create a rating associated with LCSP (life cycle support plan) for the weapons system that is 

independent of the program manager. Such a rating could be used in the evaluation of the 

program manager’s performance.

D.4.2 Ensure that an objective assessment of provisioning actions occurs during the acquisition 

milestone process, and enforce the requirement for Defense Logistics Information Service (DLIS) 

participation. 

D.6.1 Develop an authoritative glossary of terms and include it as a standard source document in an 

updated Defense Acquisition Guidebook.

D.1.1 Revise DODI 5000.02 to better address TDP policy. In addition, a stronger policy statement is 

needed to ensure all stakeholder participation.(also D.4.1)

D.5.3 Revise DODI 5000.02 to include Redstone Arsenal (Dayne Beam) recommended changes 

regarding GAO 06839 (Data Rights) report. This would enhance the acquisition of data rights 

that must be acquired to effectively use the data contained in the TDP.

D.7.1 Update MIL STD 31000 to have more explicit information on TDP content and delivery all 

requirements.

D.8.3 Review DOT FAA Order 8110.4 as an example of best practice for data definition, and engage 

with the AIA EMC (Engineering Management Committee) to provide guidance on TDP 

definitions. 

D.10.1 Replacement parts history (e.g. reliability and maintainability) data should be provided 

regardless of sustainment and procurement method. This assumes that some sort of central 

repository is available to archive the information.

D.10.2 Configuration data should always be provided regardless of sustainment or procurement 

method. 

D.10.3 Include exit-strategy (e.g. an option for acquiring logistics/technical data) in contractor logistics 

support/performance-based logistics (CLS/PBL) contracts to mitigate risks. 
65

4 Full Group Prioritization and Resulting Nuggets

Following the small group sessions the whole assembly returned to the large room for each group to 

present their top, approximately 10 solutions. They were all asked to view these presentations from a 

high level and judge the importance of the individual solutions from that strategic view. The results are 

shown below in Figure 7. The unique identifier for each of the solutions is shown in Table 5.

Figure 7 Large Group ranking by importance and urgency

Table 5 List of high priority solutions from each small group.

Unique 

Identifier

Title

A.1.1 Establish a check-list of Data requirements at Data Call.

A.2.4 Establish training, certification, and knowledge capture to address declining workforce 

issues for Acquisition Data Management professionals.

0

5

10

15

20

25

30

35

B.1.4B.4.0

A.9.1

A.5.1, A.5.3, A.1.7

A.4.2

C.6.1C.6.3

A.2.4

D.1.1

C.2.1C.1.1

A.7.1

B.5.3

C.2.3

B.5.4

D.6.1D.7.1

B.3.4B.2.3

C.7.1

B.7.2

A.10.1

A.3.3

D.5.3

C.5.2

D.3.1D.4.2

D.10.3

B.12.3B.10.4

A.1.1

C.2.2C.3.1

D.10.2

A.3.2

B.8.5

C.2.4

D.10.1

A.8.1

D.8.3

C.5.1

Complete TDP Requriements

Improve directions, Instructions, and 

Policies Improve Technologies

Address Declining Numbers of Acquisitions Data Management Professional s

Break Point
66

Unique 

Identifier

Title

A.3.2 Establish funding and identify expertise between services to develop and implement 

an automated tool for the acquisition of TDPs. Plus - A.7.2 Expand SYSPARS to 

incorporate an automated tool to develop TDP requirements (CDRL, SOWs, 

worksheets).

A.3.3 Reconvene an OSD advisory group to identify and promote critical needs create a 

uniform standard for conducting business for TDPs requirements (A.2.3).

A.4.2 Accountability of decisions made by PM that extends beyond tenure for the acquisition 

(investigate UK example).

A.5.1, A.5.3, 

A.1.7

Mandated participation of all stakeholders/SMEs at Data Call and throughout the 

program, including IP Attorney experienced in data acquisition contractual issues.

A.7.1 Revise MIL-STD-31000 to consolidate requirements for the three TDP levels currently 

defined as separate (conceptual, developmental, and production)

A.8.1 Apply TDP requirements and related decisions must be evaluated to make sure 

contractor dependence is not increased. Apply early and maintain through-out 

contract.

A.9.1 Require native, neutral, and viewable formats for the entire supply chain. Ensure that 

transportable, shareable, usable, clearly identifiable formats are established at Data 

Call.

A.10.1 Require all programs to adjudicate and validate all of contractor data rights assertions. 

DFARS requirement today, seen as an option.

B.1.4 Create a comprehensive description of the data required for the TDP.

B.2.3 Define best practices and standards for MBE and mechanisms for enforcing them.

B.3.4 Conduct an ROI analysis substantiation MBE value and communicate to PMs and PEOs. 

(consensus).

B.4.0 Provide adequately annotated models.

B.5.3 Develop a validated translation process for delivering TDP information to the 

government. Establish an independent validation authority (could be design check 

software).

B.5.4 Extend the STEP standards to fully address interoperability requirements.

B.7.2 Establish manufacturing (including the extended enterprise) use cases that 

communicate exactly what the government needs in a TDP and why. Include narrative 

documents with geometric data.

B.8.5 Achieve an MBE presence and voice in IT strategy. This will be accomplished by 

participation in forums and meetings.

B.10.4 Provide a robust tool set that supports the migration of 2D models to 3D models 

including the capture of relevant information and the migration of un-annotated 3D 

models to be compliant with new requirements.
67

Unique 

Identifier

Title

B.12.3 Develop and distribute the DEDMWG strategic plan as a guidance document to 

industry.

C.1.1 Develop and publish DoD TDP standard and related documents.

C.2.1 Expand use of Automated tools – SYSPARS/SMART-T.

C.2.2 Institutionalize involvement policies across Services.

C.2.3 Develop appropriate contract language and clauses – tied to standard.

C.2.4 Assess execution activity - to confirm delivery of TDP.

C.3.1 Define who, how, and when in conjunction with policy development.

C.5.1 Develop requirements to utilize Global Combat Support Systems (GCSS) efforts.

C.5.2 Develop and establish a policy for an official master authoritative data source for each 

TDP.

C.6.1 Define modern repository requirements and architecture options.

C.6.3 Develop and prove out capability to link TDPs to tech documents and other 

deliverables.

C.7.1 Continue to push for parts management and leverage in progress Services and DLA 

activities.

D.1.1 Need to revisit DoD 5000.02 to better address TDP policy. In addition, a stronger policy 

statement is needed to ensure all stakeholder participation. Revise DoD I5000.02 

and/or the DAG (D.4.1).

D.3.1 Create a rating associated with LCSP (life cycle support plan) for the weapons system 

that is irrespective of the program manager.

D.4.2 Ensure that an objective assessment of provisioning actions occurs during the 

acquisition milestone process, and enforce the requirement for Defense Logistics 

Information Service (DLIS) participation.

D.5.3 Revise DoD 5000.02 to include Redstone Arsenal (Dayne Beam) recommended changes 

regarding GAO 06839 (Data Rights) report.

D.6.1 Develop an authoritative glossary of terms and include it as a standard source 

document in an updated Defense Acquisition Guidebook.

D.7.1 Update MIL STD 31000 to have more explicit information on TDP content and delivery 

all requirements.

D.8.3 Review DOT FAA Order 8110.4 as an example of best practice for data definition*, and 

engage with the AIA EMC (Engineering Management Committee) to provide guidance 

on TDP definitions. *(Defines the constituents of the TDP.)

D.10.1 Replacement parts history (e.g. reliability and maintainability) data should be provided 

regardless of sustainment/procurement method.
68

Unique 

Identifier

Title

D.10.2 Configuration data should always be provided regardless of sustainment/procurement 

method.

D.10.3 Include exit-strategy (e.g. an option for acquiring logistics/technical data) in contractor 

logistics support/performance-based logistics (CLS/PBL) contracts to mitigate risks.

4.1 Analysis

An analysis of these top 41 solutions reveals that there are at least four types of solutions 

recommended. Twenty-one of these solutions dealt with a need for improvements in directives, 

instructions, and/or policies. Three of these were ranked in the top 13 in the final balloting. These 

solutions called for stronger and clearer directions regarding the acquisition of technical data packages

and included somehow increasing the importance of acquiring the TDP to the acquisition manager. 

Seven called for better definition of technical data package’s required content and the migration of that 

required content into the model based environment. Four of these made it into the top 13 solutions. 

Twelve solutions proposed improving some sort of technical capability. Five of these solutions made it 

into the top 13. Most of these dealt with the need for architecture, infrastructure, and other capabilities 

that enable model collaboration and data exchange. Finally, the single solution addressing the issue of a 

declining workforce of experienced acquisition data management professionals ranked 6th overall.

Grouped according to these four categories the best of the best solutions are listed below. 

TDP Definition

1. Create a comprehensive description of the data required for the TDP (B.1.4).

2. Develop and publish DoD TDP standard and related documents (C.1.1).

3. Revise MIL-STD-31000 to consolidate requirements for the three TDP levels currently 

defined as separately (A.7.1).

4. Develop a validated translation process for delivering TDP information to the government. 

Establish an independent validation authority (B.5.3).

Improved direction, instructions, or policies 

1. Mandate participation of all stakeholders / SMEs at Data Call and throughout the program, 

including IP attorney experienced in data acquisition contractual issues. (A.5.1, A.5.3, A.1.7).

2. Make accountability of decisions made by PM extend beyond tenure for acquisition, i.e. UK 

example (A.4.2).

3. Revisit DODI 5000.02 to better address TDP policy. In addition, a stronger policy statement is 

needed to ensure all stakeholder participation. Revise DoDI 5000.02 and/or the DAG (D.1.1 

& D.4.1).

Technology Development

1. Require native, neutral, and viewable formats for the entire supply chain. Ensure that 

transportable, shareable, usable, clearly identifiable formats are established at Data Call.

2. Define modern repository requirements and architecture options (C.6.1).
69

3. Develop and prove out capability to link TDPs to tech documents and other deliverables 

(C.6.3).

4. Provide adequately annotated models.

5. Expand use of automated tools, i.e. SYSPARS & SMART-T (C.2.1).

Diminishing Experts

1. Establish training, certification, and knowledge capture to address declining workforce 

issues for acquisition data management professionals.
70

APPENDICES
71

A-1 Group A. Acquisition Issues and Solutions Table

Yellow highlighted below means these items given the highest priority by the group.

ID Issue/Need Description

A.1 Limited enforcement of DFARS, e.g. requirement for separately priced data from hardware (e.g. 

TDP/TM).

ID Solution 

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.1.1

Establish a check-list at project start-up itemizing established contract 

requirements for data and data rights, and have it signed by contractor 

that they agree.

0 2

A.1.2 Periodic mandatory compliance and verification through out the lifecycle. 

A.1.3 Add performance against project check-list to CPARS check-list. Allow 

OEM to correct non-compliance.

A.1.4 Report to GAO/IG for enforcement of DFARS clause (rights of data, 

separate price of data).

A.1.5 Require a General Officer signature when out of compliance. 0 5

A.1.6 System that assists navigation to specific DFARS clauses, not just title 

and number.

A.1.7 Include as a stakeholder an IP Attorney experienced in data acquisition 

contractual issues.

0 3

ID Issue/Need Description

A.2

Lack of career path and training for Acquisition Data Management personnel (includes 

Engineering Data Management officers) and other stakeholders for the understanding and 

establishment of TDP requirements. 

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.2.1

Establish a cross-functional DoD/Engineering Data Management working 

group to offer training, identify training resources, bring awareness, 

brainstorm, and encourage standardization across DoD; group should 

meet at least semi-annually.

0 5

A.2.2 Promote awareness and communicate via DAU DM Community of 

Practice. https://acc.dau.mil/dm
72

A.2.3

Publicize “horror stories” and exemplars showing the cost of ineffective 

TDP acquisitions practices, to increase awareness of the values and 

benefits of increased capability and redirection of cost. Raise 

awareness/make visible GAO reports concerning TDP impact.

0 2

A.2.4 Establish a career field and multi-level certification criteria in DAU for 

Acquisition Data Management professionals. 0 5

A.2.5 Establish and maintain capability inventory showing current and 

projected levels of expertise in Acquisition Data Management.

A.2.6

Perform a Desktop Study to assess job requirements and staffing needed 

to effectively perform Acquisition Data Management. Use results to both 

classify and determine staffing requirements.

0 5

ID Issue/Need Description

A.3 Diminishing supply of TDP knowledge/expertise for Technical Data Management and other 

stakeholders.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.3.1

Establish a searchable knowledge base repository with links to 

standards, regulations, policies, directives, instructions, and guidance, 

and with an intuitive interface customizable to the user’s needs. This 

may be an extension of existing tools.

0 5

A.3.2 Establish funding and identify expertise between services to develop and 

implement an automated tool to assist the acquisition of TDPs. 0 2

A.3.3

Reconvene an OSD advisory group to identify and promote critical needs 

and to create a uniform standard for conducting business for TDPs 

requirements.

0 2

A.3.4 Establish a system to capture and disseminate the knowledge and 

expertise of existing Acquisition Data Management professionals. 0 5

ID Issue/Need Description

A.4

Lack of accountability and enforcement by Contracting Officers (KO) and PMs for TDPs. The 

length of acquisition cycle exceeds the length of PM involvement (PM in office for 2 years; 

makes short-term decisions).

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.4.1 Establish a governance structure to clearly define decisions needed and 

authorities to make them and verify/document that they have been 0 5
73

made.

A.4.2 Accountability for acquisition decisions made by PM that extends 

beyond his/her tenure (investigate U.K. example). 0 5

ID Issue/Need Description

A.5 Lack of all stakeholder involvement in establishing requirements for TDPs

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.5.1 Mandated participation of all stakeholders/SMEs at Data Call and 

throughout program. 0 3

A.5.2 Engineering Management Data plan identifies all stakeholders.

A.5.3 Include as a stakeholder an IP Attorney experienced in data acquisition 

contractual issues.

0 3

ID Issue/Need Description

A.6

Decisions related to Contracted Logistic Support (CLS) or PBL; argument too often used to 

remove TDP requirement in early procurements. Later modifications result in custom versions. 

No defined exit strategies in contract when previous decisions are altered – must also alter TDP 

decisions.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.6.1

At Data Call, establish requirement for the exit strategy in contract, i.e. 

data access at scheduled intervals with clearly defined physical delivery 

requirements.

0 2

A.6.2 Establish requirements for data in specified formats in SOW/CDRL 

regardless of ACAT category. 0 2

ID Issue/Need Description

A.7

Standards are not concise and complete; lack of guidance for obtaining/navigating standards. 

MIL-STD-31000 has too many options/disconnects opportunities for special procurement items 

(e.g. DIDs – special, commercial, developmental, tooling, etc). For example, completion of DD1423; need to know where to go to get appropriate requirements.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.7.1 Revise MIL-STD-31000 to consolidate requirements for the three TDP 0 1
74

levels currently defined as separate (conceptual, developmental, and 

production)

A.7.2 Expand SYSPARS to incorporate an automated tool to assist developing 

TDP requirements (CDRL, SOWs, worksheets) 0 2

A.7.3 Create a standards knowledge base for navigating and linking standards 

and other relevant guidance. 0 5

ID Issue/Need Description

A.8 Current TDP practices and decisions result in increased vendor dependence and ever increasing 

costs.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.8.1

Apply TDP requirements and evaluate all related decisions to make sure 

contractor dependence is not increased. Do this early and maintain 

throughout contract.

1 3

A.8.2 Establish metrics to represent the level of contractor dependency in an 

acquisition, including the ability to track changes to TDP requirements.

ID Issue/Need Description

A.9 Lack of standard delivered TDP formats and interfaces causes excess cost and complexity.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.9.1

Require native, neutral, and viewable formats for the entire supply 

chain. Ensure that transportable, shareable, usable, clearly identifiable 

formats are established at Data Call.

1 2

A.9.2 Standardize metadata requirements within the TDP across DoD.

ID Issue/Need Description

A.10 We don’t adjudicate OEM assertions of proprietary or other data rights restrictions even though 

the burden of proof is on the OEM (since NDAA 07).

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.10.1 Require all programs to adjudicate and validate all of contractor data 

rights assertions. It is a DFARS requirement today, but seen as an option. 0 3

ID Issue/Need Description
75

A.11 No systematic processes/validation tools for 2D or 3D/MBD.

ID

Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Year 0, 

1, 2 ...

Duratio

n Years

A.11.1 Update 20-year old guidance data.

A.11.2 Use DAU DMCoP group to identify and share Best Practices within DoD.

A.11.3 Develop a formal verification/validation process used by all DoD entities. 0 2
76

A-2 Group B. Production, Planning, and Design Table

Yellow highlighted below means these items received the highest number of group votes.

Grey highlighted below means these items were considered by the group to be important

ID Issue/Need Description

B.1 The requirements and the data to develop a TDP are not available

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.1.1 Evaluate existing standards to define the degree to which they address the 

need S S

B.1.2 Evaluate and evolve coordinated contractual language to incorporate MBE 

in the TDP (it must include all stakeholders in the procurement process) S

evaluate 

(S)

evolve 

(L)

B.1.3 Create government regulations mandating the enforcement of a TDP that 

supports MBE M L+

B.1.4 Create a comprehensive description of the data required for the TDP. S S

B.1.5 Create responsibility and accountability including a plan of action to 

implement the TDP requirements M M

B.1.6 Conduct pilot to evaluate the effectiveness and utility of the TDP structure 

and process M M

ID Issue/Need Description

B.2 A lack of MBE technology to meet requirements

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.2.1 Develop a comprehensive plan for MBE S M

B.2.2 Conduct benchmarking studies develop a desired architecture and identify 

the gaps M M

B.2.3 Define best practices and standards for MBE and mechanisms for enforcing 

them M M
77

B.2.4 Create a roadmap to fill the gaps M M

B.2.5 Create champions, secure funding and implement the plan (include 

incentives for industry implementation) M M

B.2.6 Create contractual language that enforces requirements M+ L

B.2.7 Create a continual process of management of the plan and its 

implementation. M S

ID Issue/Need Description

B.3

The acquisition professionals, PMs, and PEOs do not properly perceive the value of MBE over the 

lifecycle. The value of the TDP is understood in some areas and not understood in others but is not 

usually a priority.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.3.1 Provide separate funding for the PM to embrace and implement MBE. S M

B.3.2 Embed MBOs (management by objective) that include total cost of 

ownership in the PM fitness report (annual review) M M

B.3.3

Contract based on total lifecycle costs instead of focus on short term cost 

minimization to enable the upfront investment needed for MBE 

implementation. Requirements in RFP.

L L

B.3.4 Conduct an ROI analysis substantiation MBE value and communicate to PMs 

and PEOs. S S

B.3.5 Conduct single digital master file demonstration that validates the short 

term low cost implementation of cost saving MBE processes. S M

B.3.6 Require DAU training for all acquisition professionals, PMs and PEOs on the 

value of MBE M M

B.3.7 Provide pervasive enterprise level training across the supply chain for MBE 

implementation S L

ID Issue/Need Description

B.4 The inability to provide adequately annotated models. There is no clear guidance to define what a 

fully annotated model should be at each level of TDP maturity and for each purpose.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B4.1 Achieve a clear definition of and standards to support a fully annotated 

model across government and industry including LOTAR. S M
78

B.4.2 Develop and provide clear guidance on the implementation of the applicable 

standards. M S

B.4.3 Identify TDP content - and specifically annotation requirements at each level 

of maturity in the product realization process. S M

B.4.4 Develop a standard for annotation for different product types based on part 

classification. S M

B.4.5

Define the annotation standards to the lowest common interoperability 

standards. 

 Complete AP203 and AP233 and MBE compatibility index levels and 

mandate compatibility in the contract.

S S

ID Issue/Need Description

B.5 Tools do not interoperate limiting the ability to exchange information for effective collaboration.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.5.1 Evaluate the current interoperability capabilities and identify the gaps. S S

B.5.2 Provide incentives for MBE tool providers to incorporate interoperability 

standards specifically addressing gaps. M L

B.5.3

Develop a validated translation process for delivering TDP information to the 

government. Establish an independent validation authority (could be design 

check software)

M M

B.5.4 Extend the STEP standards to fully address interoperability requirements. S L

B.5.5 Accelerate standards development to the point that standards parallel 

technical capability. S S

B.5.6 Create international partnerships to leverage and assure consistency of 

interoperability standards. S M

B.5.7 Develop a system similar to SPC mandating the sampling of TDP packages for 

interoperability of information for contractual compliance. M L

B.5.8 Provide a government system with a validated neutral format to manage 

access to and distribute the TDP data M L

ID Issue/Need Description

B.6 The inability to assure through validation and verification the accuracy and completeness of the 

model. There is no enforcement of the provision of validated TDPs.

ID Solution (add Metric for Success for “Top” Solutions) Timing
79

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.6.1 Apply existing standards and tools to achieve mutual understanding of TDP 

content between design sources and production sources. (NAS 3500) S S

B.6.2

Extend existing standards and tools to assure that they adequately address 

all information like provisioning data, acquisition needs, and quality 

(metadata)

S M

B.6.3 Develop a practice and process for the complete configuration management 

of MBE TD. (practices exist for TDP but not for MBE TDP) S M+

B.6.4 Develop tools to validate the accuracy of the model and provide needed 

training to the acquisition community S M

ID Issue/Need Description

B.7

Character Characteristic level accountability – traceability of requirements through product design 

and manufacturing at the level at which they make sense and can be measured/consumed.

There is no definition of what manufacturing planning data is required in the TDP. 

The need to include narrative documents along with the geometric data in the TDP is not well 

served.

There is no definition of requirements or methodologies for inspection or QA of minimally 

dimensioned MBE models.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duratio

n Years

B.7.1 Evaluate tools and methods that exist and define gaps. Benchmark to 

identify and establish best practices.

B.7.2

Establish manufacturing (including the extended enterprise) use cases that 

communicate exactly what the government needs in a TDP and why. Include 

narrative documents with geometric data.

B.7.3 Develop a compliance matrix that maps the manufacturing planning 

requirements to the TDP.

ID Issue/Need Description

B.8

Multitude of IT certification requirements across DoD is a barrier for adopting MBE tools.

The DoD enterprise IT strategy does not link with MBE tools (both DoD and corporate IT strategies

ID Solution (add Metric for Success for “Top” Solutions) Timing
80

Start 

Years

0, 1, 2 ...

Duration 

Years

B.8.1 Determine the appropriate chain of command for IT certification in order to 

harmonize requirements with MBE implementation

B.8.2 Establish a process to assure that certification of net worthiness is built into 

the plan for every program.

B.8.3

Highlight the cost of failures in not providing a timely solution to program 

needs (IT installation requirements, risk analysis, net worthiness 

certification)

B.8.4 Understand the approval process at the installation level

B.8.5 Achieve an MBE presence and voice in IT strategy. This will be 

accomplished by participation in forums and meetings.

B.8.6 Obtain proper authority from OSD mandating MBE implementation and 

mandating processes to support that implementation.

B.8.7 Incorporate MBE enablement into gold standard processes within the 

government to expedite the ability to conduct MBE 

ID Issue/Need Description

B.9 The migration of legacy models into new systems 

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duration 

Years

B.9.1

Develop business rules that define the amount of legacy information that 

must be provided to support each contract. (reasonable requirements 

defined by category of procurement)

B.9.2 Establish decision support systems based on business rules that guide the 

acquisition decisions regarding legacy data.

B.9.3 Provide line items for procurement of legacy data that is required by new 

systems contracts

B.9.4

Provide a robust tool set that supports the migration of 2D models to 3D 

models including the capture of relevant information and the migration of 

un-annotated 3D models to be compliant with new requirements.

ID Issue/Need Description

B.10 There is no requirement to deliver an as-built TDP, including 3D geometry, to the government 

appropriate for the contract.

ID Solution (add Metric for Success for “Top” Solutions) Timing
81

Start 

Years

0, 1, 2 ...

Duration 

Years

B.10.1 Provide clear definition including use cases that guide decisions about when 

as-built TDPs are required and the content that is required.

B.10.2 Define a framework that communicates the data content and the form of 

that data.

B.10.3

Provide tools that support the automated capture of needed as-built 

information and provide mechanisms to assure compatibility of the available 

data with the requirements of the contract.

B.10.4

Clarify data right issues associated with the as-built TDP and document 

general findings. (Understanding the specifics will be negotiated with each 

contract)

B.10.5 Provide tools that support the capture of configured product structure and 

the ability to maintain the as-built TDP.

B.10.6 Provide the capability to automatically reconcile as-built with the asdesigned and as planned 

ID Issue/Need Description

B.11 Emerging tools support a portion of the needed set, but they support pieces of the solution and are 

not working toward a comprehensive solution to the TDP vision.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duration 

Years

B.11.1 Identify population of supporting tools in context of those issues above 

that have cited tools as part of their solution

B.11.2

Raise the visibility of the DEDMWG activity to the level required to achieve 

the critical support, and enrich that activity to address all encompassing 

solutions

B.11.3 Develop and distribute the DEDMWG strategic plan as a guidance 

document to industry.

B.11.4 Provide incentives to the technology vendor community to work together 

against the vision to provide4 comprehensive interoperable solutions.
82

A-3 Group C. Provisioning, Logistics, and Sustainment Table

Of the twenty-one (21) solutions developed, eleven (11) were rated as High Priority and are shaded 

yellow. Additionally, each solution was further developed with start year and duration information. The 

High Priority Solutions were presented to the full TDP Summit/Workshop participants for voting along 

with High Priority Solutions from the other TDP teams.

ID Issue/Need Description

C.1 Need for complete and detailed standard definition of TDP across all Services: Need to evolve to 

standard references for contracting purposes. Includes uniform and standard nomenclature with 

terms and their definitions. Need to clarify what constitutes model based support for TDP.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.1.1 Develop and publish DoD TDP standards and related documents, e.g. 

Data Item Descriptions (DIDs) 0 2

C.1.2 Work towards an international standard – leverage existing standards 

work and new DoD standard 0 5

ID Issue/Need Description

C.2 Lack of upfront involvement and inadequate contract language: There is a lack of upfront 

involvement across the stakeholder community. All stakeholders need to define the requirements 

and the contract needs to reflect the requirements. Inadequate contractual language is not getting 

the right PL&S requirements in the contract. 

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.2.1 Expand use of Automated tools – SYSPARS/SMART-T to assist in 

developing program and contract documents. 

0 2

C.2.2 Institutionalize involvement policies across Services – clarify and 

promote the need with strong business cases 0 2

C.2.3 Develop appropriate contract language and clauses – tied to standard 0 2

C.2.4 Assess execution activity- to confirm delivery of TDP 1 By TDP

ID Issue/Need Description

C.3 Need to address the definition, contents, and management of TDP certification and validation: 

Who, how and when – oversees the delivery and acceptance of a TDP

ID Solution (add Metric for Success for “Top” Solutions) Timing
83

Start Year

0, 1, 2 ...

Duration 

Years

C.3.1 Define who, how and when in conjunction with policy development –

the “how” also driven by standard: “who” and “when” can start without 

a standard

0 2

ID Issue/Need Description

C.4 TDPs often don’t contain all the information users need throughout the lifecycle: May be 

mislabeled, incomplete, inaccurate, conflicting, redundant and/or not searchable. Model data is 

disconnected from source system.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.4.1 Develop a set of assessment rules for creating modernized data to 

support legacy weapons system needs 0 1

C.4.2 Develop a tool kit/environment for cost effectively data modernization 0 10 phased

C.4.3 Identify cost effective tools and methods for developing, acquiring legacy 

part data – 2D, 3D, whatever fits the need 0

Continuous

3-5 yr 

cycles

ID Issue/Need Description

C.5 Lack of authoritative source and control of the TDP: Multiple copies of TDPs that are out of sync, as 

delivered and as used, are not configuration managed. There are multiple sources and each thinks 

they are THE authoritative source. Due to data manipulation to meet mission requirements, the 

data is modified and is not fed back to the originating/originating source. Thus, it’s out of sync, 

redundant, multiple systems. Within some Services there is a lack of a modern repository 

environment. Who controls and who is the authoritative source for a common part? How do we 

know/assure that the most current TDP is up to date?

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.5.1 Develop requirements to utilize Global Combat Support Systems (GCSS) 

efforts (Enterprise Requirements Planning - ERPs) within and across the 

Services to facilitate Product Lifecycle Management (PLM) 

0

Ongoing

5 yr min

C.5.2 Develop and establish a policy for an official master authoritative data 

source for each TDP 0 2 

C.5.3 Identify current potential authoritative sources 0 1

ID Issue/Need Description

C.6 Lack of ability to reuse and leverage product data: To derive other data products such as tech 
84

manuals, BOMs, to support all the subsequent as delivered, as used, as maintained, as designed, 

etc. needs across the life cycle.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.6.1 Define modern repository requirements and architecture options, use 

of existing ERPs, JEDMICS, others including new commercial solutions. 

Note: there are multiple implementation options, but one with promise 

is primes-to-DoD mirroring. Leverage prime capability (tie into definition 

of data requirements)

0 2

C.6.2 Develop/discover standards based tools that take advantage of data 

viewing and exchange

0

2

1– Discover

4 - Develop

C.6.3 Develop and prove out capability to link TDPs to tech documents and 

other deliverables 0 1-1/2

ID Issue/Need Description

C.7 Need to make it easier for parts reuse and interchangeability How can the data from a model 

supported TDP be defined, acquired and utilized to improve NSN full descriptions?

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.7.1 Continue to push for parts management and leverage in progress 

Services and DLA activities 0 continuous

ID Issue/Need Description

C.8 Inadequate and insufficient data access, formats, availability - poor data access, inconsistent 

formatting and overall lack of availability hinder broad based use across all the user domains. Users 

need to be able to access the authoritative source in a form that they can readily use.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Year

0, 1, 2 ...

Duration 

Years

C.8.1 Leverage authoritative source assessment and development work. 0 2

C.8.2 Develop and approve mechanisms that enable role based access to TDPs. 0 2-1/2

C.8.3 Drive development of data formats – PLCS (AP-239) 0 1-1/2

C.8.4 Provide low cost readers to some classes of users 0 continuous
85

A-4 Group D. Policy Management Table

This group felt that all policies changes could be started immediately but estimating the required 

duration was fruitless since the process is fraught with negotiations and compromises. Thus they elected 

to spend no time attempting to fill out the “Timing” portions of this table.

Solutions highlighted in yellow were taken forward into the large group prioritization process.

ID Issue/Need Description

D.1 There is no single entity accountable for technical data policy within OSD.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start 

Years

0, 1, 2 ...

Duration

Years

D.1.1 Need to revisit DoD 5000.02 to better address TDP policy. 

D.1.2 Require a technical data engineering data management plan (EDMP) 

evaluation at each milestone review by an oversight board. 

D.1.3 Develop an oversight board that contains the data stakeholders.

D.1.4 Ensure that the life cycle support plan (LCSP) includes the cost and value 

requirements of TDP. 

ID Issue/Need Description

D.2 Decision makers and policy makers who have the ability to mandate what should be done do not do 

so... fully appreciate total life cycle costs.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 ...

Duration

Years

D.2.1 Review the training program so that technical data is understood.

D.2.2 Implement accountability requirements associated with LCSPs.

ID Issue/Need Description

D.3 Short term goals/objectives/drivers within program offices do not optimize life cycle sustainment 

costs. (The PM is being rewarded for short term successes rather than long term 

capabilities/requirements. Furthermore, the PM is not accountable to stakeholders and not held 

responsible for long term shortcomings.) Short term management cycles accentuate lack of 

accountability.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

Duration

Years
86

0, 1, 2 ...

D.3.1 Create a rating associated with LCSP for the weapons system that is 

irrespective of the program manager.

ID Issue/Need Description

D.4 The de facto process does not include a timely provisioning process to include the Defense Logistics 

Information Service (DLIS). 

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 ...

Duration

Years

D.4.1 A stronger policy statement is needed to ensure participation. Revise DoD 

I5000.02 and/or the DAG.

D.4.2 Ensure that an objective assessment of provisioning actions occurs during 

the acquisition milestone process. 

D.4.3 Enforce the requirement for DLIS participation at milestone review “B” and 

beyond. 

D.4.4 Establish/ensure a system to address modification updates affecting 

provisioning groups.

D.4.5 Include DLIS partnership/participation with the MILSVC in the SOWgeneration process.

ID Issue/Need Description

D.5 Current data rights are not uniformly or adequately understood and exercised.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 ...

Duration

Years

D.5.1 Add more resource Engineering Data Management Officers (EDMO) to the 

degree required to exercise technical data rights adequately. 

D.5.2 Provide/require training for all participants in the acquisition process.

D.5.3 Revise DoD 5000.02 to include Redstone Arsenal (Dayne Beam) 

recommended changes regarding GAO 06839 (Data Rights) report.

ID Issue/Need Description

D.6 There is a lack of common terms, definitions, and industry standards within DoD policy and 

contractual flow-down documents with respect to technical data.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start Duration
87

Years

0, 1, 2 ...

Years

D.6.1 Develop an authoritative glossary of terms and include it as a standard 

source document in an updated Defense Acquisition Guidebook.

D.6.2 Evaluate existing industry standards to be used as references for 

authoritative definitions.

ID Issue/Need Description

D.7 Explicit direction on TDP content and delivery (CDRLs) is not given to the contractor.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 ...

Duration

Years

D.7.1 Update MIL STD 31000 to have more explicit information on TDP content 

and delivery requirements.

D.7.2 Establish a team to advise policy makers regarding technical data format 

delivery.

D.7.3 Require that model-based TDPs specifying native-format files must also 

include validated neutral-format files (e.g. Pro-E and STEP-APs).

ID Issue/Need Description

D.8 Fidelity and robustness of technical data contractually requested often does not provide what is 

really needed for sustainment. 

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 ...

Duration

Years

D.8.1 Support the enhancement of ASME Y14.41 and other relevant standards. 

D.8.2 Ensure that all relevant contractual “boiler plate” references (both industry 

and military) are identified and included in requirements documents.

D.8.3 Review DOT FAA Order 8110.4 as an example of best practice for data 

definition*, and engage with the AIA EMC (Engineering Management 

Committee) to provide guidance on TDP definitions.

*(Defines the constituents of the TDP.)

ID Issue/Need Description

D.9 The process of receiving data does not include a rigorous feedback loop for validating that the 
88

requested information has been received. The tech data procurement and receiving people are not 

communicating effectively.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years

D.9.1 Ensure that in-process reviews are part of contractual requirements.

D.9.2 Ensure that Integrated Product Teams (IPTs) have procedures that define 

roles and responsibilities with respect to TDP life cycle support; if not, create 

them.

D.9.3 Enhance existing tools such as Smart-T and Sys-Par to assist in 

implementation of policy, and ensure that the tools are DoD wide. (Intelligent 

Specification Assistant)

ID Issue/Need Description

D.10 Parts demand data is not captured and provided to the DoD on contractor logistics support / 

performance-based logistics (CLS/PBL) contracts. Risk mitigation plans and requirements are not 

included in the language.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years

D.10.1 Demand data should be provided regardless of sustainment/procurement 

method.

D.10.2 Configuration data should always be provided regardless of 

sustainment/procurement method.

D.10.3 Include exit-strategy in CLS/PBL contracts to mitigate risks.

D.10.4 Review the Quadrennial Defense Review (QDR) solution for form, fit, and 

function definition to ensure that it is adequate, and take action as necessary.

ID Issue/Need Description (Use only for coping and pasting new table)

D.11 Software OEMs don’t fully support data interoperability standards.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years
89

ID Issue/Need Description (Use only for coping and pasting new table)

D.12 Engineering Data Managers are “disappearing” and along with them the knowledge of what a TDP 

should include.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years

ID Issue/Need Description (Use only for coping and pasting new table)

D.13 Providers (program management and procurement personnel) to the data users (DLA parts 

providers, codifiers of the info, packaging people, depots, warfighter) are not educated in the 

technical data and data-rights environment.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years

ID Issue/Need Description (Use only for coping and pasting new table)

D.14 AS-9102 (First Article Inspection Report) is not currently required to be included as a part of the 

TDP.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duration

Years

ID Issue/Need Description (Use only for coping and pasting new table)

D.15 Industry knowledge of LOTAR (AN-9300 standards) practices is incomplete.

ID Solution (add Metric for Success for “Top” Solutions)

Timing

Start

Years

0, 1, 2 

...

Duratio

n

Years
90

A-5 Summit Agenda

MBE Summit Agenda

15-Dec-09

0800 – 0810 Welcoming Remarks and Admin Issues - Simon Frechette, NIST

0810 – 0830 NIST Overview – Dr. Howard Harary, (NIST)

0830 – 0850 OSD Direction for MBE - Ms. Adele Ratcliff, (OSD)

0850 – 0910 Introduce Summit Goal and Objectives – Paul Huang, ARL

OSD ManTech Project Update:

0910 – 0940 TDP Definition - Paul Huang, (ARL)

0940 – 1015 Certification of 3D Models - Simon Frechette, (NIST)

1015 – 1030 Break

1030 – 1100 Contracting for TDP within MBE - Ric Norton, (DLIS)

1100 – 1130 Intelligent Specification Assistant- SYSPAR/Smart-T - Jim Colson (LOGSA) 

Rick Wagoner (NAVSEA)

Ric Norton (DLIS)

1130 – 1200 OSD Organic Facilities (Depot/Shipyard/ALC): MBE Data Reuse Capability

Rich Eckenrode, (BAE)

1200 – 1300 Working Lunch (Open Discussion)

1300 – 1330 MBE Provisioning Demo at DLA/DLIS A-10 & MRAP Ric Norton & 

Tim Haidl, (DLIS/DAPS)

1330 – 1400 Single Digital Master File Connectivity Demonstration

Steve Luckowski, (ARDEC)

1400 – 1430 DoD National Supply Chain Model Pau Villanova,(ARDEC)

Army ManTech Projects:

1400 – 1425 Supply Chain Assessment Report Roy Whittenburg,(BAE)

1425 – 1445 S1000D Technical Pilot MRAP Publication Julie Miller/

Roy Whittenburg

1445 – 1500 Break

1500 – 1530 Adobe Quick Print and Visualization Enhancement Roy Whittenburg (BAE)

1530 - 1630 Digital Depot - Rich Eckenrode (BAE)
91

Jack Martin (RRAD)

Eric Burkholder (LEAD)

1630 - 1700 MBE Success Story MRAP Egress Trainer Rich Eckenrode, (BAE)

16-Dec-09

0800 – 0830 Advanced PMI Projects at NIST Vijay Srinivasan, (NIST)

0830 – 0900 Advance PMI Standards Development Simon Frechette, (NIST)

0900 – 0930 Overview of Navy Shipbuilding TDP / MBE related activities Ben Kassel, (NAVSEA)

0930 – 1000 Model-Based CAD Design at Sandia National Laboratories Rick Harris, (SNL)

1000 – 1015 Break

1015 – 1035 NIST MEP Overview David Stieren (NIST MEP)

1035 – 1135 OSD MBE/TDP Technology and Policy Strategies Rob Steele (IMTI)

Roy Whittenburg (BAE)

1135 – 1145 Lunch Break

1145 – 1300 Discussion of Technology and Policy Gaps and Opportunities (Working Lunch)

Conclusion of MBE Summit

TDP Summit Agenda

16-Dec-09

1330 – 1345 Welcoming Remarks and Introductions

1345 – 1400 DEDMWG Website Demo

1400 – 1415 Workshop Methodology and Instructions

1415 – 1730 Small Groups (Current State, Vision, Issues, Solutions)

A) Acquisition

B) Production, Planning and Design (PP&D)

C) Provisioning, Logistics and Sustainment (PL&S)

D) Policy Management

1730 Adjourn for the day

17-Dec-09

0800 – 1130 Small Groups Meetings A-D (continuation)

1130 - 1230 Working Lunch in Breakout Groups

1230 1330 Small Groups Meeting A-D Review of Groups’ Solutions and Prioritization

1330 – 1400 Break

1400 – 1500 All groups presents: Vision & Top 10 Issues/Solutions (10 min/each)

1500 – 1530 Review of groups issues and prioritization
92

1500 – 1600 Path forward, MBE Strategies review, and Concluding Remarks

1600 Adjourn
93

A-6 Participants

Breakouts 21 33 16 14

fName lName Activity/Company Acq PP&D PL&S Policy

Eric Adams ARDEC Army 1

Kent Alexander Siemens PLM 1

Dave Baum Raytheon 1

Tina Bigler USCG HQ/EIS Army TARDEC 1

Bob Brown Delmia 1

Eric Burkholder LEAD 1

Alan R Carlson Raytheon 1

Otha Carter JMTC-RIA 1

Pad Cherukuri TARDEC/EBG 1

John Christensen contractor to OSD 1

Mike Clare Boeing Research & Technology 1

James Colson LOGSA 1

T. Patrick Coulehan TechniGraphics, Inc. 1

Mike Cowperthwai

t

PEO Aviation 1

Dave Crouse HQ AFMC 1

Nancy Darnell TARDEC/EBG 1

Ashley Davis DSCR-VABB 1

Steve Deflitch DSN Innovations 1

James DeLaPorte GulfStream 1

Denise Duncan LMI 1

Rich Eckenrode BAE 1 1

Paul Embry Lockheed Martin 1

Simon Frechette NIST 1

Stanley P Fuelscher BAE Systems 1

Herman (Gary) Gaines Navy 1

John Gamoa BAE Systems 1

Suhair Ghannam TARDEC 1
94

Tom Giesler IMTI 1

Marilyn Giles IMTI 1

Gary Grant Warner Robins AFB 1

Gerry Graves SCRA 1

Rene Graves IMTI 1

John Gray ITI 1

Tim Haidl DLIS 1

Daniel K Harn Raytheon Missile Systems (RMS) 1

Rick Harris Sandia National Labs 1

George Haskin BAE systems 1

Tony Hernandez Sandia National Lab 1

Paul Huang Army Research Lab (ARL) 1 1

Mark Hubbart DLIS 1 1

Sara Jordan IMTI 1

Al Kapinos TARDEC/EBG 1

Bruce Kaplan LMI 1

Ben Kassel NSWCCD 1

Sharon Kemmerer NIST 1

John Kreider RDAR-EIS-CS/Small Caliber Systems 

Branch 1

Montana Mallett NIST - MEP 1

Debra Ann Martin Defense Logistics Agency (DLA) 1

Sam McSpadden IMTI 1

Bob Morris Renaissance Services, Inc. 1

Charlie Neal IMTI 1

Richard Neal IMTI 1

Doug Neilson ARL 1

Mark Nielsen PTC 1 1

Ric Norton DLIS-KPD 1 1

Henry (Hank) Oakes OASIS Systems Inc. 1 1

Matthew Payne Naval Air Systems Command 1 1

Nainesh Rathod Imaginestics, LLC 1
95

Gary Reece AFMC 516 1

Jeff Rembold PTC 1

Walter Roy Army Research Lab (ARL) 1

Dr. Andreas Schreiber PROSTEP INC. 1

Natalie Seiling DLA 1

Carl Sens GDLS 1

Dan Skabialka AMRDEC Spares 1

Rob Steele IMTI 1

David Stieren NIST 1

Charlie Stirk CostVision Inc. 1

Liz Sumrell FRC-East 1

Gary Sunderland NAVAIR 1 1

Jose Tapia ARDEC 1

Ken Tashiro Elysium Defense 1

Siyuan Tu LMI 1

Paul Villanova Picatinny Arsenal ARDEC 1

Rick Wagoner NSWC PHD Detachment Louisville 1

Greg Wetsig Northrup Grumman 1 1

Roy Whittenburg BAE 1
96

A-7 Wiring Diagrams

This sections contains a depictions of the hierarchy of the governing directives, instructions, guidance, 

and handbooks for the DoD acquisition process. These charts are rather notional and incomplete but do 

give a sense of how the program manager goes about satisfying the program requirements dealing with 

an acquisition.

• Public Law 109-364 in ‘§802 calls for acquisitions to “(e) provide for technical data rights 

needed to sustain such systems and subsystems over their life cycle.”

• DIRECTION and INSTRUCTIONS from DoD and Services required the program manager (or 

acquisition manager) to “address”, “consider”, or “ensure” the life-cycle of the product as he 

makes the purchase.

• GAO-06-839 found that very little oversight is mandated as to the sufficiency of the 

consideration but some of the newer DoD documents do have a requirement to review the 

sufficiency of the data.

• To help specify the contract deliverables the program manager is provided with many Data Item 

Descriptions (DID), Military, Industry, and International standards to include by reference in the 

contract data requirements list (CDRL). But again, there is nothing that says that they MUST use 

either this one or that one. 
97

The words “technical data package” are not used consistently. Sometimes it is Engineering Data, or 

Technical data.
98

Each service has documentation covering directives, instructions, and manuals that generally follow the 

DoD level documents but with specific structure unique to that service. Each service is currently 

updating their individual policies.
99
100

DLA provisions the services with required supplies and spare or replacement parts. They are subject to 

the same requirements in their acquisition process but are hampered in purchasing by the current lack 

of technical data on many of the systems they must provision.