The default approach to managing knowledge which many companies use, is to keep knowledge in people’s heads, and to move the knowledge where it is needed by moving the people, not by transferring the knowledge.
In this old model, knowledge is owned and held by the experts and the experienced people. Knowledge is imported to projects by assigning experienced people as members of the project team.
Knowledge is transferred from site to site by transferring staff, and by using company experts who fly around the world from project to project, solving problems.
This is a very traditional model, but it has many major failings, and cannot be considered to be effective knowledge management.
Imagine if you managed your finances in this way! Imagine if the only way to fund a project was to transfer a rich person onto the project team, or to fly individual millionaires around the world to inject funds into the projects they liked!
The major drawbacks of this default ‘knowledge in the heads’ approach are as follows:
- Experienced people can only be on one project at a time, whereas knowledge management can spread that experience to many projects.
- Knowledge cannot be transferred until people are available for transfer.
- Experts who fly in and fly out often do not gain a good appreciation of how things are done, and where the good practices lie. In particular, teams in projects may hide their failings from the company experts, in order to be seen in a good light.
- The burn-out potential for these experts is very high.
- Knowledge can become almost ‘fossilised’ in the heads of the experts, who can end up applying the solutions of yesterday to the problems of today
- Even experts forget things over time. The human brain is a very poor long-term knowledge store
- When the expert leaves, retires, has a heart attack, or is recruited by the competition, the knowledge goes with them.
It is like early Hollywood movie scenes with the US Cavalry riding over the horizon to save the wagon train at the last minute. Knowledge management, however, would make sure that the wagon train did not get into trouble in the first place. As one experienced engineer said recently, ‘If you could fly off to some problem project, save the day and be a hero, or sit behind your desk and capture knowledge, what would you do?’
However if that engineer's knowledge had been more widely available, perhaps the project would not have become a problem in the first place.
Don't keep the knowledge in a few heads, spread it through the organisation instead.
2 comments:
I'm wondering if as the "experienced engineer" says the real problem is to take time to capture knowledge or at the other end of the time required for the wagon train people to learn this knowledge and reach the competency level sufficient to be autonomous and solve the problem. It could be tried every day: You've got a problem ? read this book (300pages), gain practice, experience and you're done. What if they don't have time (it's urgent), they don't know how to learn by themselves.
IMHO the probelm is not to capture knowledge but to turn it into something easy to digest, readily relatable, fast to apply. To tag it, place it in a searchable place is nice but more is needed like: chunking, progress tracking, assessment, automated checklist for applicability.That's what I'm working on.
You are right, Bruno - "capture" is only one part of the equation, "package and structure" is another. And a lot of knowledge can be transferred within the community of practice without ever being captured in the first place.
Post a Comment