Navigating the Pitfalls of Acquiring Technical Data

1. Navigating the Pitfalls of Acquiring Technical Data Virginia Stouffer vstouffer@lmi.org

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

3. 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

4. Tech Data Picture courtesy of wikimedia commons

5. 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

6. 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 Stretch variables, unique developmental items More specific requirements but not key to IOC, acceptance Both ORDs and contract language are in the PM tradespace

7. 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?

8. Multiple Opportunities for Failure Did NOT Specify TDP Specify complete Specify rights Specify format (STEP/3D/layers, Native, netutral) Did NOT Specify TDP No milestone payment for TDP No milestone for complete Reserve buyer IP rights? Specify format? Electronic portal submittal? Approval of format, content ? TDP is omitted? TDP not a payable? Vendor data rights? No standard delivery?

9. Multiple Opportunities for Failure 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 Did NOT Specify TDP Specify complete Specify rights Specify format (STEP/3D/layers Native, neutral) Did NOT Specify TDP No milestone payment for TDP No milestone for complete Reserve buyer IP rights? Specify format? Electronic portal submittal? Approval of format, content ? TDP is omitted? TDP not a payable? Vendor data rights? No standard delivery?

10. 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

11. Multiple Opportunities for Failure Specify TDP Milestone payment Milestone for completeness Reserve buyer rights Format Electronic portal submittal with approval of format, content Specify TDP Specify complete Specify rights Specify format STEP/3D/layers 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 TDP omitted? TDP not a payment? Data rights changed? Nonstandard delivery? Traded away IP? New contract?

12. 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

13. 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 ?

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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”

21. 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

22. 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

23. Intellectual property

24. 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

25. 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

26. 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

27. Back up Material Best Practices Tech Data through the lifecycle

28. 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 A • 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

30. Technical Data ManagementBest Practices Technology Development PDR • 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

31. Technical Data ManagementBest Practices Technology Development PDR • 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

32. Technical Data ManagementBest Practices B System Capability and Manufacturing Process Demonstration Integrated System Design Post-PDR Assessment Post-CDR Assessment • 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 constructto collect the above artifacts into needed collections CDR Engineering and Manufacturing Development PDR

33. Technical Data ManagementBest Practices Production and Deployment Full-Rate Production & Deployment LRIP 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)

34. Technical Data ManagementBest Practices Production and Deployment Full-Rate Production & Deployment LRIP FRP Decision Review • Final Weapon system Product Configuration Baseline • Materiel In-Service information (IUID, “as produced” configuration information)

35. Technical Data ManagementBest Practices Operations & Sustainment Lifecycle Sustainment Disposal • Materiel In-Service information (system maintenance and reliability information, system Condition-Based Maintenance (CBM) data, “as maintained” unit configuration information) • Disposal information

36. Contact: Virginia Stouffer Senior Research Fellow vstouffer@lmi.org 703-917-7167 FOR MORE INFO: