Knowledge transfer

Source

As we can see, based on previous text and also our own experience, changes within the project team can be hard for team members working on the project. There are two cases:

• somebody left the team
• somebody join the team

Both are quite different. In the first case, we need to spread knowledge among the team members in limited time and produce some deliverables describing them. In the second one, the information flow goes in opposite direction. The team should provide required understanding to new guy.

If somebody left the team, there would be some different scenarios of leaving and replacing his position.

1. Leave without hiring new one
2. Leave and hire new man immediately after leaving (or after some period of time)
3. Hire somebody before leaving

Of course, last scenario is the easiest case. However, life is not as simple as we would like to, so other options also can happen and they are even more frequent. Each one of them needs special treatment.

Storing knowledge

On each case the most important part of migration is documenting all knowledge in permanent form. For example as a Word document, diagram or other type of documentation. Any of documentation form is better than none. The main principles about good knowledge documentation can be shortened to 5S rules:

• simple (understandable)
• shareable
• structured
• standardized
• stored

We must remember that every situation, that one person explains some topics to another person, should result in a persistent documented data. It might be helpful in future e.g. when somebody would join the team. That’s why every knowledge transfer should be documented and stored in accessible way.

I will describe the knowledge lacking in later text about managing knowledge.

Training

Let’s take into consideration the situation when a leaving employee can meet with a person who will replace him, so we can arrange a training situation. The same like during learning new skills. It enables to teach new developer how to work properly in this company.

Nobody can tell, how much time will be needed for passing this knowledge. It depends on its complexity, level of depth they want to talk about and of course scope of work. We can assume that for most of duties this time would vary from few days to about 2 weeks. In this time we can set up multiple training situations for different aspects and different levels of complexity.

Business knowledge

The fundamental part of every transfer should be business knowledge, which is required to better understanding parts of business environment. This kind of information can be obtained directly from business or from documentation. We can use process descriptions or current systems functional documentation. Nevertheless it is very beneficial for developers to talk with future users (eg. business). It may show the expectations and concerns about specific systems. Thanks to that understanding of other side, developers could improve application to better fulfil requirements. Moreover, when somebody look on some parts of the systems, he will know why it works in that way and what value it gives to target users.

Good method to describe business rules is to use real life use cases. For example we can characterize business process just by telling how it behave in specific situations. This could be done although by business or other team members with bigger knowledge.

Technical knowledge

Passing technical information in well managed environment is easy. The hard part begins, when we need to do this in messy managed companies.

Technical knowledge means several things (levels of complexity) for us:
– information about technology
– system architecture
– integration architecture (data flows)
– low level implementation details

First one is quite easy. It is just ability to use specific tools, libraries or languages. Generally we can assume, that we want to hire a person, who already have these abilities. If they don’t, they could learn it by themselves or with a little help from more experienced colleagues.

Next points are typical for knowledge transfer, because it requires to teach somebody something strictly specific to the organisation or the project.

Last three parts are ordered by their importance. This order should be also preserved during transfer. The most crucial is good description of system architecture and techniques used in development. New team member may go to lower level of details faster but primarily he could be consistent in style and conventions in future development.

The most effective way to transfer these 3 types of knowledge is to describe it first and then start something like workshop stage. New employee should try to do some tasks by himself. Starting from easy and going to more difficult. It is very beneficial for learning person to have some assistance at the beginning. But also it is important to slowly decrease the level of support. That gives him more responsibility and motivation. Moreover, it opens the opportunity for new employee to look on new problem from his own perspective, which can result in some improvements.

Of course each information passed in this stage should be stored electronically for purpose of future use.

Soft knowledge

This type of information are usually forgotten during all processes of knowledge transfer. It might be simple, but essential. Database of contacts with whom he would cooperate in future can be a great help for the new employee.
For sure it can save a lot of time of wrong questions or misdirected requests.

Everyday knowledge

The last part of information needed to take whole responsibility in work is a description of activities during a typical workday. For instance, how to handle bugs reported by users or direct questions from them or organizational methods to handle task or taking decisions. This is strongly related to tools used in everyday job (time tracking, reporting).