Browsed by
Month: February 2016

Knowledge transfer situations

Knowledge transfer situations

Knowledge transfer


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.


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).

Knowledge transfer

Knowledge transfer

Knowledge transfer

One of the most important part of every project is knowledge. Without appropriate knowledge we can’t make any project successfully.

Project’s life is usually much longer than the time of software production. After the process of project creation, we have to support it in its every day use.

Knowledge connected with each project could be generally divided into two parts:

  • technical
  • business

In order to create value to future users programmers would need a business knowledge, but to ensure the quality and extensibility of code they also need strong technical skills and knowledge. Each part is important. During the development we learn in both area. Our business understanding in particular scope is rising at this time. People say, that usually new employee would need 1-2 years of work in one business line to get fluency in developing new solutions and inventing new ideas related to this topic. On the contrary it would be needed almost the same level of technical expertise during project development, but on the support phase sometimes developers need to be at a higher level of details oriented skills.

As we see, knowledge management is significant part of project development. Importance of this aspect provides some risks related to management of this asset.

Human factors

Employee turnover

People are the most crucial part of whole process. In most of the projects, majority of the knowledge is kept by people arranged to them. Business understanding is not handled by single man, but only all team members knowledge combination covers full scope of business complexity. That’s why one of risks is the employee turnover. When one part of team left, it will be needed to transfer his knowledge to someone else. This is additional cost.

Many developers stays in one job no more than 1-2 years. Also many projects (software production phase) lasts about 1 year. Notice the coincidence between how long people work and how fast they getting business understanding. This is the same time period. It is not very surprising that if developer would get familiar with his every day work and it stops being a challenge for him, he need a change.

Project stages and developers interesting levels

On every system development, we can observe a few different phases:

  1. Start / design
  2. Creation / development
  3. Fixing bugs
  4. Support

This division is usable especially when we talk about developers interests. As we go further in this list, the developer’s interest level decrease. That’s happen because they have more challenging tasks and more responsible duties at the beginning. So most of them decides to leave at this moment. As the time goes on, it would be harder to find proper and willing employee to maintain the project.

Quitting/getting a job

The first situation, that needs special attention of project managers is situation when somebody left the team. If knowledge sharing won’t be an every day routine, it would cause the problem of missing part of information. So we should be aware of necessity to spread them among all team members.

Other situation is, when somebody start to work in our team. He also needs assistance and support of other to get necessary amount of knowledge to start doing something according to the accepted standards independently, with invention.

Holidays, vacations, deadlines and random events

However, not only employee changing is the problem. Temporary absence as well. When somebody is sick or go to tropical island, someone else have to replace him at this time.

Project factors

New projects

On the other hand, the project could be main beneficent of proper knowledge management. If the developers team has sufficient level of business understanding, they will work on new projects faster and more frictionless. They will less often stop their work to ask for business specifics and they could provide better quality as we let their ingenuity to come to the fore. This is beneficial for both sides: business and developers. Business could get well tailored systems which better responds to their needs and developers could avoid many mistakes as a consequence of misunderstanding.

Current work – support

Everyday work needs good knowledge sharing the same as new projects. Our team could take many advantages thanks to this.

  • speed up implementing changes or fixing bugs
  • they could make decision internally
  • they could suggest their own solutions (frequently better)

You can see that managing knowledge could be a major problem in project life cycle. The specifics of the business is one of the most valuable thing in every organisation. Therefore it needs special treatment by managers on every stage of the project and every situation connected with team members turnover.
In further posts I will show how to resolve this problems in different ways.