This is an old model, published in 1999 (the "knowledge with shelf life" article available for free here) but one I keep coming back to, as it can really help differentiate between different knowledge transfer needs, and therefore different knowledge transfer solutions. (Quite often, one of the reasons why people "talk past each other" in KM is because they come from different contexts of knowledge transfer, and assume that the solution that works for them will also work in other contexts)
It's a question of thinking of the knowledge supplier and receiver, and how they stand in relation to each other in time and space.
In some cases, activities and projects run one after the other, in a single location, and often involving the same people (the coloured blocks int eh diagram above represent project or other activity). Here knowledge needs to be transferred through time, but not through space - something we can call "Serial transfer". For example in one organisation we worked with, a series of LNG trains (effectively giant fridges for liquefying natural gas) were built in the Niger Delta. This is a task that requires specialist knowledge and experience. For each train, the team needs to learn as much as possible from the previous train, in order that they may build them better, faster, cheaper, more safely, and more effectively. In this case, the retrospect for each train could be followed immediately by a planning session for the next train - ‘learning after’ leading straight into ‘learning before’. The knowledge could be transferred in designs, in improved procedures, through direct conversation between the staff delivering each train, and in the heads of the people who will carry on. Knowledge transfer is a matter of discussing the learning, updating the documents, and making the changes.
Another example is where the same sort of projects or activities are running at the same time, all over the world. Here we need some sort of synchronous knowledge transfer, so people can learn from each other in real-time. An example comes from a client seeking to develop distribution networks in rural parts of the developing world, facing similar challenges in rural Brazil, in rural Africa, and in the Far East. In this case, the Synchronous Transfer is facilitated by a very effective community of practice, supported by a communication infrastructure and a live on-line knowledge base. Knowledge can also be transferred tacitly, through peer assists, knowledge exchange, knowledge visits, mentoring and coaching, and online interaction.
The third case is to consider projects that happen sporadically in time and space. This is an altogether more difficult challenge. They are a series of one-offs, which happen at intervals, in different places. They might be projects like constructing a pipeline over mountains, or entering a new retail market, or acquiring another company. These are projects that happen once at any one location, and are sufficiently unusual that you don't have several happening at once. Effective knowledge transfer is crucial, as each project is a new and unusual event for the project team, and there is tremendous risk of reinventing the wheel (in fact the traditional default is to re-invent). And at the same time, knowledge transfer is a real challenge, as knowledge has to be transferred through time and through space. You can't rely on human memory (here's why), and some form of documentation is needed (even though this is tough to do well). Knowledge needs to be captured from a project team, and packaged and stored so that an unknown team, at an unknown location, at some unknown time in the future, can access it, understand it, relate to it, use it, and benefit from it. This sort of Distant Transfer of knowledge is difficult, but possible. What it needs is some way of giving the knowledge a decent shelf-life through teh construction of Knowledge Assets - the challenges of which I dealt with in the article referenced above, and which I may come to in further blog posts.
The key is to recognise the three types of transfer, recognise that your company may face all three in different places and at different times, and do not assume that the method you apply to one, will work for all three, because it won't.
Posts
No comments:
Post a Comment