Know-How Transfer - Just Explaining is not Enough

• Most projects face situations where knowledge needs to be transferred from one person to another.

• Integrating new team members quickly, with an effective and efficient know-how transfer, minimizes delays and transition costs - you can react flexibly to changing requirements and ideally specialists can contribute to several projects.

• How can you ensure that nothing of importance is being lost even in complex projects?

How can a new team efficiently take over knowledge about an application with more than half a million lines of code? In my last project we were faced with exactly this challenge, and now we have to make sure that the knowledge we have acquired will not be lost once again.

In software projects there are always situations where knowledge has to be transferred:

• New requirements: A lot of knowledge is not yet explicitly available and has to be developed with stakeholders. Daily work for business analysts and requirements engineers.
• Staff changes in an existing project: Individual employees must be replaced or newly inducted. Perhaps, as in our case, a completely different team has to take over, when there is a change of supplier? The team should still deliver value and if possible without interruption.
• Project transitions: When a product goes live, for example, or when development mode transitions into maintenance mode, information must be passed on.

From experience in my last project, in which we completely took over and revitalised a complex application, I learned quite a bit about know-how transfer and knowledge retention. Many of the following statements are certainly also applicable more generally, but the focus here should be on software development projects.

Staff changes as an example

In an ideal project, the perfectly matching team, with all the necessary knowledge and skills, is 100% available from start to finish. Handovers during the project are not necessary. Such projects hardly ever occur in the real world, however, so the person who can best manage the change of employees has an advantage. If you can quickly induct new team members, you can minimise delays and transition costs, react flexibly to new requirements and, ideally, deploy specialists over several projects.

Everything - as fast as possible

The term know-how transfer suggests that knowledge can easily be transferred from one person to another. But transferring comprehensive knowledge from one mind into another is an illusion. In practice it usually looks like this:

• A lot of knowledge is only available implicitly and is distributed among many minds.
• The capacity to acquire new knowledge in a short time is limited, but time is short and it is hardly possible to hand over every bit of knowledge. The focus therefore has to be on the important points.
• Knowing something does not necessarily mean that you also understand it, let alone are able apply it.

Tools and methods

During the know-how transfer, neither the employee imparting nor the employee acquiring it are productive, and a knowledge transfer on its own does not improve a product or mend a mistake. It is therefore clear that the transfer must be done efficiently.

In order to introduce new team members to the project as quickly as possible and to maintain the knowledge in the best possible way, we used several methods and introduced various tools:

• A knowledge base with validated knowledge. It is important that this does not end up as a graveyard for outdated change request documentation, but remains an actively maintained minimum documentation
• An onboarding and offboarding checklist for the most important setup and knowledge tasks. This allows new project members to work on many things independently. With each rotation the checklist is verified and supplemented. It therefore always remains up-to-date.

The experiences from our project coincide with a quote from Benjamin Franklin:
Tell me and I forget. Teach me and I may remember. Involve me and I will learn.

In our first working sessions to take over the application, details in the code were explained to us. We lacked contextual information and practical application, so that not many of these explanations 'stuck'. Our knowledge of the application grew rapidly as we ourselves began to work with it and explore its code. Trial and error and asking specific questions proved to be a much more effective learning strategy. In these situations, trial and error means different things, depending on one's role: implementing features and debugging work for the developers, performing (manual) testing for the testers, deploying the application (in a test environment) for the DevOps aspects, speaking with stakeholders for requirements engineers.
 

It all depends on the perspective

As a general rule, the transfer of know-how should be led by the person acquiring it: Afterwards, they must be able to work with the acquired knowledge. If, after a handover, the predecessor has in his/her view dealt with all the topics, but the successor sees nothing but question marks, the goal has not been achieved.

There is, of course, a justifiable concern that whole blocks of topics might be forgotten if the learner takes the lead in the transfer activity. In order to prevent this risk, as part of the project we created a keyword summary of the application. Not comprehensive documentation that quickly becomes outdated, but a rough overview on an A4 page of the most important topics. This gives new team members a quick overview and allows the topics in the know-how transfer to be prioritised.
 

Making implicit knowledge explicit

Checklists and concrete goals are a good way to fetch implicit knowledge from peoples' minds. It is much more difficult to pass on intuitive understanding that results from long practical experience. This includes, for example, personal networking, with the knowledge of whom I can ask for help with what kind of problem. Practical tasks are suitable for identifying where experience is helpful. The learner should be able to work with the newly acquired application as soon as possible, initially with guidance. In this way, gaps in understanding become apparent very quickly.

A prioritised overview list helps not to lose sight of the wood for the trees. Ideally, it should not be necessary to first create this overview for the know-how transfer: it should already be available in the project.

Simple visualisations are practical aids to promote mutual understanding. Simple drawings and sketched models have often helped us to clear up misunderstandings and explain complex relationships.

To regulate the transfer of know-how, we have defined simple milestones that the acquiring person can gradually achieve more independently. As an example, here are our steps in the onboarding of a new test manager:

• Can manage the application by themselves
• Overview and active use of the regression tests
• Independent testing of a new functionality
• Comprehensive application knowledge and assumption of responsibility

Continuous transfer of know-how

Even if no staff change is pending, there are still some things that can be done to ensure that knowledge is well distributed within the team:

• Knowledge-exchange sessions to make specific, central topics known to the whole team.
• ChatOps: a searchable group-chat tool with full history facilitates informal exchange within the team, especially in distributed teams.
• Cross-functional teams, where various tasks and roles are performed by different people, and development methodologies with short feedback loops: both of these features promote exchange within the team.

This helps to prevent 'knowledge silos' i.e. less knowledge depends on individual minds. A change of employee is therefore less significant.
 

Checking the level of understanding

It is worth planning a certain amount of time after the effective handover phase, during which the new person/organisation is already in charge, but the predecessor is still available to provide help. Only when we have to start working productively with the new knowledge will it become apparent whether everything really is clear.

Explaining a topic at different levels helps to consolidate what has been learned and to identify gaps in understanding. If I can summarize the project in a few sentences for colleagues not directly involved, the priorities are probably clear. And if I can explain the application to my child, I've probably understood a few things myself. Without such controls, there is a risk that the explanations may be understood passively but cannot be applied actively.

Defining the goal

The challenge is to identify implicit, undocumented knowledge and transfer it explicitly. In order that replacement personnel can work efficiently, the knowledge in the new minds must be available intuitively once again, so it becomes partly "invisible" implicit knowledge. Hopefully, however, only to the extent that a useful structure for know-how transfer is in place for the next transition.

It is not enough to address all the knowledge once. The aim is that the acquiring person can work effectively with it. To this end, it is important to know what is to be achieved with the knowledge transferred. Know-how transfer must therefore be seen in the larger context of mission preparation: it is all about preparing a person or organisation for their task. This requires a lot of knowledge, but also needed are other aspects such as a functioning working environment. But on the other hand, perhaps some detailed knowledge is not necessary. The term Mission Preparation for the whole transition phase helps to focus on the essentials.
 

Checking the degree of success

With the regard to the project mentioned at the beginning, what is its status a good year after the initial transfer of know-how? Not every detail is known yet, but we were able to bring several releases into production in a stable manner. It proved possible to change personnel in key roles such as the Software Architect or the Quality Manager without causing problems for the project. The application was stabilised, and a survey of users shows a significant increase in satisfaction.

Ultimately, this is the only measure for a successful know-how transfer: the new employees can work productively and the stakeholders are satisfied with the progress of the project.

How do you ensure that the knowledge that exists in the various projects is retained not only in people's minds, but also on a lasting basis?