Navigating the Pitfalls of Acquiring Technical Data

Virginia Stouffer

vstouffer@lmi.org

Topics

• Acquiring technical data• Costs of failing to manage data in acquisition• Examples from case studies• Intellectual property

Which Tech Data Are We Talking About

Generalist definition: MILSTD 31000

• Defn: A technical description of an item adequate for supporting an acquisition strategy, production, and 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, patterns, performance requirements, quality assurance provisions, software documentation and packaging details.

• See also NIST/ISO AP232, 214, 232, 239

Tech Data

Picture courtesy of wikimedia commons

Acquiring Technical Data

• In a large, complex acquisition, technical data is rarely rated the most important deliverable

• Must-haves– Key Performance Parameters– Operational Requirements (ORDs)– Contract language

• Schematics and technical data are in contract language

Acquiring Technical Data

• In a large, complex acquisition, technical data is rarely rated the most important deliverable

• Must-haves– Key Performance Parameters– Operational Requirements (ORDs)– Contract language

• Schematics and technical data are in contract language

Power of the antenna, range, speed

Power of the antenna, range, speedStretch variables, unique

developmental itemsStretch variables, unique

developmental itemsMore specific requirements but not key to IOC,

acceptance

More specific requirements but not key to IOC,

acceptanceBoth ORDs and contract language are in the PM

tradespace

Both ORDs and contract language are in the PM

tradespace

Peril of Data Acquisition

• So, what happens?• Many government agencies do not do an adequate job

of obtaining technical data during acquisition– Fail to plan to obtain technical data– Fail to secure intellectual property rights– Trade away the right to technical data

• Becomes a problem in maintenance• Cost of getting data after contract ranges from

exorbitant to impossible• How does this happen?

Multiple Opportunities for Failure

Did NOTSpecify TDPSpecify completeSpecify rightsSpecify format(STEP/3D/layers,Native, netutral) TDP is omitted?

TDP not a payable?Vendor data rights?No standard delivery?

Did NOTSpecify TDPNo milestone payment for TDPNo milestone for completeReserve buyer IP rights?Specify format?Electronic portal submittal?Approval of format, content ?

Multiple Opportunities for Failure

Did NOTSpecify TDPSpecify completeSpecify rightsSpecify format(STEP/3D/layersNative, neutral) TDP is omitted?

TDP not a payable?Vendor data rights?No standard delivery?

Did NOTSpecify TDPNo milestone payment for TDPNo milestone for completeReserve buyer IP rights?Specify format?Electronic portal submittal?Approval of format, content ?

Budget gets cut

Quantity procured gets cut

Price per unit goes up

Requirements increase from external interface

Requirements increase through user specification

Suddenly PM is trading

Budget gets cut

Quantity procured gets cut

Price per unit goes up

Requirements increase from external interface

Requirements increase through user specification

Suddenly PM is trading

PM Tradespace

Price

time

power

accuracy

Vendor: If we invest in this test opportunity, we

think we can improve accuracy by 12%... Let’s

substitute that for milestone 12…

Traded away IP?New contract?

Multiple Opportunities for Failure

Specify TDPSpecify completeSpecify rightsSpecify formatSTEP/3D/layers

TDP omitted?TDP not a payment?Data rights changed?Nonstandard delivery?

Specify TDPMilestone paymentMilestone for completenessReserve buyer rightsFormatElectronic portal submittal with approval of format, content

Ability to read, review?Check property rightsData signoffIs this the final design?Is it complete?Resubmits may be complete but property rights may be reserved

Hidden Dangers

• The least reliable or worst performing part will be the one being re-

worked to the end of the contract

• The TDP will be complete but for that part

• That part will also be the one with the most maintenance calls and

parts needs

• Late changes to the part, especially after the contract ends (eg

bridge contract) will tend to not have IP preserved

Hidden Dangers

• Be wary of contractor provisions for the government to provide a

software version upgrade as layers get lost in version upgrades

• Subcontractors may not be obligated to deliver technical data

• COTS parts may not have tech data

?

Representative Costs of Re-Acquiring Tech Data

• Cost of going back for a limited-rights tech data package after acquisition can be expensive– Hardware Specifications = 10% of total contract cost– Detailed software test results = 0.5% of acquisition– Complete technical data package with specifications and

requirements database = 100% of cost of acquisition

• An unlimited government-rights TDP cannot be obtained after acquisition for any amount short of a new acquisition

Representative Costs of Re-Acquiring Tech Data

• Obtaining it also will include tremendous amounts of contracting officer time as the contract must be extended again and again for delivery of the TDP

• It becomes a war of attrition between the procuring contract officer and the vendor attorney– Odds are stacked against a government COR

Fix the Problem

• Short Term– Acquisition milestones– Data manager position on procurement team pre-ORD– Data manager signs deliverables– Ability to evaluate tech data

• Long term– Long term change in ownership presumption (Budget act

2007)– Data management training – Data management career path– Repository for tech data for transition to O&S

Summary TDP Best Practices in Acquisition

• Including a complete TDP needs to be a graded KPP (an absolute requirement) of the acquisition– Vendors may respond with a SOW that omits TDP

and graders miss it unless it’s required• Completeness of TDP needs to have its own

milestone payment– The one part that causes the most trouble during

manufacturing will be the one that is missing from the TDP, because it is being re-worked until the last minute

– It will also be the one part that causes the most trouble during O&S, because it can never be fixed properly without detailed data

• Need a data management functional head on every acquisition

Planning for Operations

• Why do we care? $$$• Don’t fail to plan…

– Must have equipment and personnel to accept the TDP

– Specify which STEP Std (machine vs platform)

– Transition from TDP to machine code if applicable

– Embedding references embeds the possibility for your document to reference

missing or erroneous information

– Support information (hand tighten, torque turns) may be layered… may be

hard to find

– TDP – IETM links not widespread

Operational Data Management

• What to keep?– Native, neutral, forever flat formats– Operations, parts, technical manual,

technical drawings– Anything related to use, maintenance or

upgrade counts as technical– Examine future users, eg secondary

market– Different standard than managerial,

scientific data

• How long to keep?– Two year review cycle– List of keep/dispose review questions– Longer than you think

• Buyer of a biological sensor asked for RFP language• Planning manufacturer performance based logistics

– Availability report– Readings per hour, per day reporting– No individual machine reporting

• Manufacturer refuses to divulge

repair time, parts history –

“costs too much to collect data”

Case Study: Bio Sensor

Case Study: Bio Sensor

• Primary answer: collect the acquisition technical data of the sensor collector

• Secondary answer: when updating parts, need the TDP from the manufacturer– Life cycle of the box is 5 years– “We won’t need the technical data”– Parts roll/obsolescence implications

• Tertiary answer: tech data keeps the maintenance contract contestable

• Horror story: what their competitor failed to do

Case Study: Avionics

• Sophisticated avionics in commercial transport is maintained on a PBL basis by independent vendors

– Operator doesn’t care what vintage the wx radar is as long as it works

– Vendors maintain the box on a “parts roll” basis

– Obsolescence pushes maintenance cost up (think Windows rot)

– When service calls get too numerous on a box, they replace it with the next generation

– Occasionally a major upgrade requires customer investment • “Where’s the USB connect?”

– A parts roll is therefore an opportunity to replace your vendor with a lower cost maintenance vendor

• Standardized connectors, large market make it possible

INTELLECTUAL PROPERTY

Intellectual Property and Markings

• Anything delivered marked “Proprietary” by the vendor – Can be used by the government organically– Can be used for government repairs– Cannot be re-released by a government client– Cannot be released to buy a new (duplicate) part/system– Cannot be shown to support contractors without an NDA

Intellectual Property and Markings

• Even if contract specifies the information is not proprietary, if the vendor marks it “proprietary” … then it is… forever

• Point of push back is delivery• Need an educated set of eyes accepting the deliverable

– With sufficient time– With the right tools

Derivative Intellectual Property

• If you have a technical details of items from multiple vendors, all marked proprietary

• You can average or sample technical details and release them

• As long as no one source or sources can be identified from what you have released

• Example: range of tolerances as general detail• Example: average strength of signal • Example: 1 to 4 amplifiers• May be useful in future feasibility studies or in

developing price points

TECH DATA THROUGH THE LIFECYCLE

Back up Material

Best Practices

• There are Program Data Management requirements throughout the a system’s lifecycle – As materiel concepts are defined, developed, designed,

manufactured, deployed and maintained, the focus of the products placed under data management changes.

29

Technical Data ManagementBest Practices

• Design of the DM function – Begins before the RFP

• For OEMs, the DM process can be a profit center• For customer, knowing how Technical Data Management will be

supported at RFP issuance means a stronger RFP• In DoD, having a robust DM Strategy that talks to both data rights

and how those data will be managed to ensure long-term usability

– Begins before a PMO is established• Some “program” DM is needed in this phase even though the

program won’t exist for a while: – Documentation of each potential materiel solution considered

Materiel Solution Analysis

Materiel Development Decision

A

• Repository established and items / information from prior phase put under DM: • CONOPS and AoA• Technology Development Strategy• EA and Solutions Architecture …

• Put Data and Configuration Management processes and staffing in place• Clear hand-offs and exchanges with CM• Documented processes and responsibilities for CM & DM• Recruit for DM--bachelor’s degree including Library or

Computer Science courses • Well-defined career path for DM

Technology Development

PDR

Technical Data ManagementBest Practices

• Maintain product definition information associated with each design/technology considered.

• Develop plans for lifecycle sustainment for each candidate technology

• Allocated Configuration Baseline--total weapon system and major component level specifications, drawings and interfaces--placed under configuration control and in data management system

Technology Development

PDR

Technical Data ManagementBest Practices

• Weapon system Product Configuration Baseline (PCB) and EM&D documentation placed under DM:– Design information (drawings, specifications, CAD models,

engineering studies, engineering analyses, trade studies) – Requirements documents – Manufacturing information (manufacturing process

planning) – Logistics Management Information – Test & QA information (test reports, test plans) – Configuration Control information (ECPs, Waivers, ERRs)

– Use Bill of Information construct to collect the above artifacts into needed collections

Post-PDRAssessment

CDR

Integrated System Design

Post-CDRAssessment

System Capability and Manufacturing Process Demonstration

B Technical Data ManagementBest Practices

• Manufacturing information (required for organic manufacturing or rebuild activities)– manufacturing process plans, work instructions,

statistical process control metrics, process capability studies

• Adjustments to the Weapon system Product Configuration Baseline as a result of LRIP or production activities. – Configuration Control information (ECPs,

Waivers, ERRs)

Production and Deployment

LRIPFull-Rate Production & Deployment

FRP Decision Review

Technical Data ManagementBest Practices

• Final Weapon system Product Configuration Baseline

• Materiel In-Service information (IUID, “as produced” configuration information)

Production and Deployment

LRIPFull-Rate Production & Deployment

FRP Decision Review

Technical Data ManagementBest Practices

Operations & Sustainment

Disposal

Lifecycle Sustainment

• Materiel In-Service information (system maintenance and reliability information, system Condition-Based Maintenance (CBM) data, “as maintained” unit configuration information)

• Disposal information

Technical Data ManagementBest Practices

Contact: Virginia Stouffer

Senior Research Fellow

vstouffer@lmi.org

703-917-7167