top of page

Case Study: A Knowledge Documentation Process of a Retiring Employee


A hand reaching out to a stack of files

Over the past year, we have presented various aspects of the employee knowledge preservation project (knowledge preservation through learning meetings, job entry files, knowledge transfer through semi-structured interviews, and more). One of the frequent requests is for a case description of a retiring employee's knowledge preservation process from start to finish. The case that will be described to you is taken from a retiree knowledge preservation project that has been taking place in the Israel Aerospace Industries for the past two years. For privacy and commercial confidentiality, only details necessary for understanding the situation and the actors involved will be presented in this case description.


Background

The knowledge preservation project was carried out in one of Israel Aerospace Industries' divisions and revolved around a veteran and professional employee who served as a central source of information for the rest of the unit (about 15 people) regarding troubleshooting in the unit's field of operation. The employee was due to retire within 3-4 months. When the project began, he was no longer in an official position but acted as an advisory figure whom unit members consulted in particularly complex cases.


Participating factors:

  • The retiring employee

  • The retiree's replacement

  • Direct manager

  • Unit head

  • An administrative representative from the unit

  • Knowledge manager of Israel Aerospace Industries

  • Process facilitator from the consulting company


Process Description:


Choosing the Retiree

Due to the high number of employees planned to retire from the company in the coming years due to age, some of whom are experts with critical knowledge, a strategic decision was made in Israel Aerospace Industries to identify these employees and perform knowledge preservation activities with them and in coordination with the VP of Human Resources, human resources personnel in the company's plants identified these retiring experts in consultation with engineering managers and business entities in each of the company's plants/divisions. In most cases, a suitable professional ("successor") was appointed to overlap with the expert with critical knowledge, sometimes for several years.


Kickoff Meeting and Expectation Alignment

This meeting served as the "opening shot" of the project and included several significant elements. First, a presentation of the theoretical model we would work with, including its various stages. This presentation included a general explanation of the process, a description of the tasks for each sub-stage, and a description of expected outcomes. Since it was challenging for participants to connect with a theoretical model, we tried to emphasize case stories and examples of similar projects done both within the organization itself and in other organizations. Another element was focusing on the expectations of each factor in the process. We asked the participants what they expected from the process and what would be considered a desirable outcome. The answers we received were diverse: the direct manager was a bit worried and didn't feel he fully understood how "you will extract the knowledge from the employee's head" but still noted that "I'm interested to see what you'll do," the unit manager wanted to know that the process would be functional, quick, and value-adding, while the retiree himself humbly wondered what he had to give. After understanding all participants' expectations, we clarified further, mainly expanding on the technique being performed and discussing the project's ability to address their expectations adequately. After summarizing the main points at this stage, we reduced the meeting to the presence of the retiree, his replacement, the organizational knowledge manager, and the process executor from the consulting company. In this smaller forum, intended to provide a more intimate feeling, we checked if there were additional things that may not have been said at the management level but could affect the project. Fortunately, no relevant issues arose, so we mapped the required knowledge. Already at this stage, the retiree and his replacement were able to define that they wanted to focus on defining "exotic" non-routine problems and presenting possible causes for these problems (each problem could stem from several factors). At the end of the meeting, the retiree and his replacement were left with "homework" in which they were required to document their areas of knowledge and prioritize which knowledge they would recommend preserving based on predefined criteria (importance of knowledge, extent of knowledge presence among other unit members, etc.).


Mapping Meetings

At this stage, several consecutive meetings were scheduled with the retiree and his replacement, the retiree's direct manager, and the unit manager. Within this short set of focused meetings, the initial direction the retiree wanted to take was confirmed, and it was decided that the project would focus on establishing a repository of possible problems in several content areas defined as more critical than others for the process. It's interesting to note that already, at this stage, there was consensus among all participants that this direction would give them the most significant added value. During the mapping meetings, participants were asked several vital questions. What? What knowledge needs to be preserved, and who? Who are the employees who will benefit from and are expected to use it, and why? Why is it essential to maintain this knowledge and not others, and How? How would we like to see the knowledge presented (questions and answers, process description, etc.)?


Mapping Summary Meeting

In this meeting, we essentially summarized our courses of action. The summary presentation included reference to the type of knowledge, how to document it, commitment regarding the scope of activity, structuring of the main content worlds, target audience, and initial assumptions regarding implementation techniques we would adopt.


Documentation Meetings

To ensure we were maximizing the project's potential, it was decided that in each documentation meeting, the retiree (to transfer the knowledge), his replacement (to absorb the transferred knowledge and ask questions about it, thereby stimulating the retiree to expand on the topic), and the process executor (to document the transferred knowledge) would be present. The retiree prepared in advance for the meetings. In each one, we documented between one to several problems (the topic we chose to focus on) that the retiree had thought about beforehand. After the first meeting, where we documented all the text, including the replacement's questions, we prepared a template to pour the information into. This template was validated in follow-up meetings with the retiree and changed as needed. This template included references to the problem data, possible causes, and the rationale behind the employee's decisions following problem identification. At a later stage and during the meetings, a need arose for several additional types of knowledge that we decided to document, including several auxiliary tables and a repository of unique emphases for one of our content worlds.


One of the most beautiful examples was in the second meeting, where the retiree happily presented a handwritten document from 1983 describing a unique technique that was performed, which we attached to one of the problems described. During the process, which lasted about 15 meetings of two to three hours each, we held a midpoint meeting with all concerned parties where we presented the products built so far and verified that we were "on the right track."


"The Great Crisis"

Shortly after we reached the midpoint, the retiree began subtly indicating that the project was not at the top of his priorities. Signs of this included, for example, showing impatience when required to explain processes in depth, saying, "We've done enough for today" even though the meetings were scheduled for longer than performed, etc. Although nothing was said formally, we felt we were receiving "distress signals" and tried to gently reflect to the retiree the feelings he was conveying to us and try to understand their source. Meanwhile, we consulted with the unit head, who had a close relationship with the retiree. Eventually, we discovered that the behavior stemmed from a feeling that the significant things had already been transferred and "it's a waste to spend more time on less important things." We decided to "go with the flow" of the retiree, so we defined a shorter deadline for completing the project, with his direct manager joining us in the follow-up meetings. It was precisely the dialogue with the manager, mainly intended for validating the products, that yielded fruitful work and suggestions for additional knowledge and information to be documented that arose during the process.


Building a Site / "Activity Support Knowledge Base" and Implementation and Maintenance Plan

Toward the end of the project, we worked with the unit's IT people to build a site, which we call an "Activity Support Knowledge Base" (Performance Support Knowledge-base) that would allow us to input the accumulated knowledge, and we defined an implementation and maintenance plan for the knowledge with the unit. Our basic assumption was that although the retiree is leaving the unit, the repository of possible problems is still vast. Therefore, we must continue documenting unique issues unit employees encounter in the template we created for them. To do this, we wrote the implementation plan, which recommended anchoring the topic in the procedure, highlighting the "problem of the month" in internal meetings, and more.


And Today?

A central topic of the unit is the collection and documentation of materials that are currently scattered and some not even documented. This will be performed soon.

In another technological topic, the central engineering organization will write a standard that includes the unit's extensive experience and knowledge.

The knowledge base is the current source of information for the list of materials used by the unit.

To ensure that the knowledge base is used and maintained, relevant unit personnel meet quarterly with the company's knowledge manager.


 

Want to learn more about knowledge retention?

Here are some articles you might find interesting:

9 views0 comments

Yorumlar


bottom of page