Article Series | Preserve Technical Knowledge: Accessible Documentation

Article Series | Preserve Technical Knowledge: Accessible Documentation

Article Series | Preserve Technical Knowledge: Accessible Documentation

  • Posted by Chris Justice and Melissa Nickel
  • On June 5, 2020

How R&D leaders can preserve core technical knowledge amidst changing teams and external partnerships

It’s surprisingly easy (and alarmingly common) for medical device companies to lose critical R&D know-how for their products, erasing competitive advantages that took many years and millions of dollars to develop. As a partner to a diverse set of R&D groups, we at Engenious Design have encountered good and bad practices that R&D groups employ to preserve core technical knowledge. This article is the first in a series on proven practices that medical device R&D leaders can implement to hold competitive advantages and hard-won product knowledge in-house, despite key employee turnover or core knowledge acquisition from third parties.

The Problem

In the medical device industry, annual team turnover averages 17% [1], with site consolidation, acquisitions, external R&D partners and staff movement further complicating efforts to retain the “secret sauce” that makes complex medical devices work. Team turnover challenges are compounded by the increasing technical complexity of modern medical devices, making it a struggle for R&D groups to maintain critical know-how (and know-why).

We’ve seen a lot over our years working with top-20 multinational medical device companies and start-ups. This is the first article in a series meant to share tools we have developed and best practices observed from our time working with different organizations.

The Solutions

Each of the articles in this series will consider a different tool or practice for knowledge transfer; this article is focused on accessible documentation. Investments made in a few key areas of accessible documentation provide the biggest return on investment: Product Architecture Block Diagram, Technical Theory of Operations, and Technical Reports. The details of how these are implemented make all the difference between knowledge-capture and knowledge-loss; in this article, we share details we find helpful. Future articles will focus on other solutions that further help to capture product technical knowledge.

Product Architecture Block Diagram

For a birdseye view of a technology system of any complexity, we find it valuable and efficient to create a simple Product Architecture Block Diagram, which is augmented with descriptive text where helpful to convey how the system is architected.

Alt Text

A block diagram illustrates the major subsystems and interfaces between subsystems. It’s like the shopping center map with the “you are here” marker – for a complex technical system. In some cases, the block diagram may be comprised of multiple pages, with a summary block diagram upfront to orient the reader, and more detailed block diagrams for subsystems.

When first designing a system, we find it helpful to quickly draft an architecture block diagram as a design conversation-starter. These illustrations help everyone on a team quickly find and address architectural issues; the resulting diagrams are also an excellent way to quickly communicate design intent to other engineers as part of knowledge transfer.

Technical Theory of Operations

Few R&D leaders would discount the importance of documentation, but we find certain types of documents to be the most effective at capturing critical know-how. In particular, we see technical theories of operation to be the most efficient mechanism to capture this elusive know-how. Where human biology and clinical practice meet engineering, it’s not always obvious at first what will work.

If a product architecture diagram is a birdseye view, the Technical Theory of Operation is the more-detailed technical narrative that describes how each subsystem works, illustrating important concepts with math or analysis. In some cases, Theory of Operations will reference conclusions from Technical Reports where helpful. The Theory of Operations is one of the most effective tools to provide knowledge transfer, and one of the least used. The Theory of Operations is not as detailed as CAD drawings, Schematics, or Source Code but provides a condensed description of how the detailed design works.

While a theory of operation can’t be provided to a machine shop to order dimensionally-accurate parts, a theory of operations helps capture the underlying engineering rationale and the math that makes complex technology systems work. Countless hours are invested in discovering effective methods to accomplish product goals, with many promising dead-ends explored, and some accidental discovery of non-obvious factors. The theory of operations is where all this knowledge should be captured – what works and what didn’t. The theory of operations describes how a product works and why it works. It doesn’t provide part prints for fabrication, but it’s the product’s technical handbook, written for an audience of other engineers. We like to say that a well-written theory of operations includes enough breadcrumb trails for someone else to fully understand the nuances of how to recreate the technology in question. Contact us for more details on what makes a great theory of operations – we can help!

For knowledge transfer to be effective, the knowledge itself needs to be accurate. There is no point in capturing and disseminating a poorly understood technology. Experience has taught us the importance of holding incremental systematic technical reviews, in real-time, during technology development. Technical decisions must be based on data that results from systematic testing, often employing the scientific method to confirm or adjust theories of operation.

Technical Report

To put simple disciplines around test data and to facilitate a review, we have adopted a Technical Report format that starts with a summary of conclusions, then documents the test protocols and equipment used, and finally the raw data and resulting analysis that inform our conclusions. This pyramid style of technical writing provides easy access to the conclusions (upfront), with supporting data for those who want more background.

Alt Text

Our process was informed by the thorough guidance document provided by the FDA to recommend content and format to describe relevant information that should be included in test report summaries, test protocols, and complete test reports for non-clinical bench performance testing

Conclusion

Documentation is critical to sustainable research & development efforts. However, not just any documentation will suffice. Make sure that your organization is investing in the right documentation.

Roadmap of Where We’re Going!

Future articles in this series will discuss how to utilize Checklists, Phase Reviews, Software Release Memos, Coding Standards, Documented Requirements, Tests, Results, Risk Analysis and Risk Mitigations, Design History Files, Decision Registers and Issue Tracking Tools. Stay tuned for a few more articles in this series that will visit more lessons learned!

Sources

1 Radford Trends Reports for medical device and diagnostics companies, Q3 2013, Q3 2014 and Q3 2015

ABOUT THE AUTHOR(S)

Chris has accumulated many lessons-learned from 20 years of medical device design. Chris is principal and co-founder of Engenious Design, a medical device design firm that works with complex electro-mechanical & embedded software systems that are developed from scratch, acquired, and multi-generation products.

Operations Lead at | engenio.us

Melissa focuses on all aspects of business operations at Engenious Design. She is a strategic problem solver with a sense of urgency, productivity and positivity. Melissa’s passion for pursuing innovative solutions pairs well with her background in product development project management and current position coordinating collaborative teams of expert designers and engineers working on medical devices and advanced technology products.