This month’s question
How can you effectively transfer decades worth of knowledge from an engineer who is about to retire and make it accessible and user-friendly for newer generations? This is less about standard work and process documentation, and more about product knowledge.
The organization’s documents should be updated to capture the engineer’s knowledge. It’s possible to make a searchable database, but people might not realize they have a situation that requires them to search the database.
Suppose, for example, two parts typically are assembled using two bolts and this is sufficient—unless the product will be used in a high-vibration environment, in which case three bolts must be used. The younger engineers can’t be expected to search the database every time they do something, and they may be unaware there is a situation in which the standard solution will fail. The organization already should have quality and engineering-related documents, and these should be updated with the experienced engineer’s knowledge.
The first step is to capture the knowledge. I recommend using an affinity diagram to do this. An affinity diagram is used to support brainstorming and help cluster comparable ideas.1 Give the engineer notecards to write down bits of knowledge, and someone with knowledge of affinity diagrams should act as a facilitator.
After the engineer runs out of ideas, sort the cards into categories. Next, enter the content of the notecards into a spreadsheet with the knowledge in one column and the category in another. Add additional columns labeled document, responsible, due date and status. Filter the spreadsheet by category and determine what document is the appropriate place to store the knowledge. Enter the document name in the document column and assign someone responsibility for updating the document.
A due date by which the document is updated also should be assigned—ideally well before the engineer leaves the organization in case there are any questions when the documents are updated. The status of each action also should be tracked to ensure it is completed. At this point, the organization will have a spreadsheet with the engineer’s knowledge and an action plan for ensuring the knowledge is appropriately stored.
Knowledge related to a process should go into a work instruction, procedure or processes instruction. The name of the document doesn’t matter—getting the knowledge into the appropriate document is what counts. Engineering-related knowledge should go into design rules or design guidelines. A design failure mode and effects analysis (DFMEA) template may be appropriate if the knowledge pertains to the prevention or detection of design-related failures. A DFMEA of the earlier example should require the engineer to identify the customer’s operating conditions. In the earlier example, if the operating conditions are unknown or involve high vibration, use of a third mounting bolt should be specified.
Updating a design validation plan and report also may be appropriate to ensure knowledge pertaining to testing isn’t lost.
If the organization doesn’t have the types of documents described earlier, or something equivalent to them, it may be time to start creating them.
- Grace Duffy, Scott A. Laman, Pradip Mehta, Govind Ramu, Natalia Scriabina and Keith Wagoner, “Beyond the Basics,” Quality Progress, April 2012, pp. 18-29.
This response was written by Matthew Barsalou, extramural researcher, Poznan University of Technology.