Know-how transfer – just explaining once 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?

Everything, as fast as possible

The expression “know-how transfer” suggests that knowledge can easily be handed over to another person. But it is not that simple:

• Often knowledge is only available implicitly and distributed over several people.
• The time to hand over information and the capacity to adopt it is limited.
• Knowing something does not automatically mean it is understood or can be applied.

How should you organize a handover then?

Set priorities

First and foremost: set priorities. It is an illusion to expect that all knowledge can be entirely transferred. Therefore, a better strategy is to ensure that all central topics are well covered. And remember, priorities depend on the perspective: perhaps the knowledge recipient has a different mission? Surely the recipient is the one that needs to work with the new knowledge and the one handing over is often no longer available after the transfer. Hence the handover process should always be led by the receiver, who therefore needs to know their goals.

It is a legitimate concern that entire topics may be overlooked when following this approach. To avoid large gaps, be sure to start with a high-level overview in order to understand the bigger context. Knowledge maps and user story mapping can be useful tools to support this process.

Documentation

If good documentation is available, the handover can be simplified to providing an introduction and overview of the documentation as well as explanations for undocumented topics. It is crucial, however, that the documentation is trusted and up-to-date. As a minimal structure, on-boarding checklists have proved helpful. These should not just take the form of a list of technical setup tasks, nor that of comprehensive documentation, but should rather consist of a map of the most important topics and where to find documentation. They should be small enough to manage so that they do not become outdated as quickly as (yet another) documentation.

Apply what you have learnt

Documentation provides explicit knowledge – a conscious effort to preserve and make available knowledge about a topic. Much more difficult to share is implicit knowledge, acquired from years of experience. For instance, knowing with whom to consult about various topics as the result of past interactions with persons within a network.

Typically, the absence of implicit knowledge is first noticed once it is needed – when the “real work” begins. An effective method to ensure that you have the required knowledge is to work under the supervision of the knowledge giver. In software development projects, this could include fixing bugs, implementing new features, creating and executing tests or deployment of the application. To quote Benjamin Franklin:

Tell me and I forget. Teach me and I may remember. Involve me and I will learn.

Doing practical work in the acquired codebase will immediately reveal the knowledge gaps which need to be filled. More importantly, knowledge learnt is more likely to endure if it is a result of practical work.

Continuous know-how transfer

Even if no employee exchange is planned, it is good practice to share knowledge within the team:

• Exchange sessions covering important topics in order to increase awareness within the team
• A group chat tool with good search functionality to simplify informal exchange, especially within distributed teams
• Methodologies with short feedback loops to foster exchange within the team

The above measures will help to avoid knowledge silos and, at the same time, lessen the impact when a team member leaves.

Check the success

As a knowledge receiver, make sure you understand what you receive. The transfer of knowledge is not a one-way street; ask questions and try to apply what you have learnt. A simple and very effective check to see if you have really got the point is to give a short summary of the topic to outsiders. And give some thought to the next joiner: offer feedback on how the on-boarding process can be optimized.

Without such checks, you might grasp a passive understanding of the topic without acquiring the ability to apply it in practice.

Hopefully, these suggestions will help ensure that your next project change is successful.

By Christoph Zuber