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
• 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
Generalist definition: MILSTD 31000
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
Power of the antenna, range,
• Must-haves
speed
– Key Performance Parameters
– Operational Requirements (ORDs)
– Contract language
• Schematics and technical data are
language
Stretch variables, unique
developmental
items
More
specific requirements
not key
IOC,
Bothbut
ORDs
andtocontract
acceptance
language
are in the PM
tradespace
in contract
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
RFP
Proposal
Contract
Work
Did NOT
Did NOT
Specify TDP
Specify TDP
No milestone payment for TDP
Specify complete
No milestone for complete
Specify rights
Reserve buyer IP rights?
Specify format
Specify format?
(STEP/3D/layers,
Electronic portal submittal?
Native, netutral) TDP is omitted?
Approval of format, content ?
TDP not a payable?
Vendor data rights?
No standard delivery?
Multiple Opportunities for Failure
RFP
Proposal
Contract
Work
Did NOT
Did NOT
Specify TDP
Specify TDP
No milestone payment for
TDP gets cut
Budget
Specify complete
No milestone for complete
Specify rights
Reserve buyer IP Quantity
rights? procured gets cut
Specify format
Specify format?
Price per unit goes up
(STEP/3D/layers
Electronic portal submittal?
Requirements
increase from
Native, neutral) TDP is omitted?
Approval of format,
content ?
external interface
TDP not a payable?
Requirements increase
Vendor data rights?
through user specification
No standard delivery?
Suddenly PM is trading
PM Tradespace
Vendor: If we invest in
this test opportunity, we
think we can improve
accuracy by 12%... Let’s
substitute that for
milestone 12…
Price
time
power
accuracy
Multiple Opportunities for Failure
RFP
Proposal
Contract
Work
Specify TDP
Milestone payment
Milestone for
completeness
Reserve buyer rights
Format
Electronic portal submittal
TDP omitted?
with approval of format,
TDP not a payment?
content
Specify TDP
Specify complete
Specify rights
Specify format
STEP/3D/layers
Data rights changed?
Nonstandard delivery?
Delivery
Ability to read, review?
Check property rights
Data signoff
Is this the final design?
Is it complete?
Resubmits may be
complete but property
rights may be reserved
Traded away IP?
New contract?
Hidden Dangers
• The least reliable or worst performing part will be the one being reworked 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
Case Study: Bio Sensor
• 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
• 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
Back up Material
Best Practices
TECH DATA THROUGH THE
LIFECYCLE
• 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.
Materiel
Solution
Analysis
A
Materiel
Development
Decision
Technical Data Management
Best 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
29
Technology
Development
PDR
Technical Data Management
Best Practices
• 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 Management
Best 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
B
Engineering and Manufacturing
Development
System Capability and
Integrated System
Manufacturing Process
Design
Demonstration
Post-PDR
Assessment
Post-CDR
PDR CDR
Assessment
Technical Data Management
Best 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
Production and
Deployment
Full-Rate
Production
LRIP
& Deployment
Technical Data Management
Best Practices
FRP Decision
Review
• 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
Full-Rate
Production
LRIP
& Deployment
Technical Data Management
Best Practices
FRP Decision
Review
• Final Weapon system Product Configuration Baseline
• Materiel In-Service information (IUID, “as produced”
configuration information)
Operations &
Sustainment
Lifecycle Sustainment
Technical Data Management
Best Practices
Disposal
• Materiel In-Service information (system
maintenance and reliability information,
system Condition-Based Maintenance
(CBM) data, “as maintained” unit
configuration information)
• Disposal information
Contact: Virginia Stouffer
Senior Research Fellow
vstouffer@lmi.org
703-917-7167