“So, how is this different from knowledge management?”
As I discuss a knowledge transfer (KT) methodology it’s not a question that gets asked a whole lot; but when it is it tends to sidetrack the meeting or presentation. The questioner is almost always someone who’s lived through the adoption of a knowledge management system in the recent past and is concerned that KT is merely a new name to an old failure. They, understandably, have a concern akin to, “Fool me once – shame on you. Fool me twice – shame on me.” They don’t want to be set up to fail yet again because KM has left a lingering bad taste in their organizational mouth.
I propose that there IS a difference between their experience of a classic KM tool or system and a knowledge transfer methodology today.
The classic KM approach was mostly about buying and deploying a single, massive, enterprise-wide system where everyone would just naturally see its value. Folks would dive right in and input their information and knowledge and experience; and others would then quickly and efficiently search for this knowledge to use on their jobs. But it never worked out that way.
Although a KM system was deployed, there was little if any change management … and there was precious little accountability in its use. Its value was not well presented; and even if value statements were promoted in the organization they were seen as hollow managerial platitudes.
In part, the problem was that KM had been viewed as an open-ended, one-size-fits-all approach (which does have an appeal to large organizations in that it gives the impression of unity and uniformity).
Knowledge transfer, however, starts off with a different set of problems to tackle. Because it has a different starting point, it is handled differently … therefore KT is different from KM.
In my working with clients, knowledge transfer is more specific and tactical. Perhaps a function is being outsourced to a third-party vendor; or a function is moving from one geographic location to another onshore; or two or more functions are being consolidated. Therefore, KT work is more project-oriented and focused on achieving a defined result – reducing cost, increasing efficiency, removing redundancy, and so on.
Knowledge transfer presumes that there is knowledge-holder, or originator/owner, and there is an end-user, or recipient of the knowledge. Whereas KM was rather generically applied across an organization and is systems oriented, KT is more tactical and person-to-person or group-to-group oriented. (Granted, there is a movement afoot of “KM 2.0,” which is not so much the classic KM approach but closer in nature to what I describe as knowledge transfer … that’ll be a subject for a different post, however).
There is an irony in this … in that a knowledge transfer process (at some point) should include a knowledge management stage. In other words, KM has to be rolled into KT in order for the knowledge to be successfully transferred, kept up-to-date and be searchable/retrievable by the intended recipients.
It comes as no surprise to me (but apparently it is surprising to others) that KT and KM are not exclusive of each other … and KM is not to be dismissed as “old school” or useless. Okay – so, KM was not well implemented or managed when it first caught on as the next big thing. So what?!? It doesn’t mean that it itself is worthless. Indeed, KT without KM is no more effective or useful.
I’m pulling together a presentation on KT and KM – not so much on distinguishing their differences and similarities … but more about an understanding of how the two interact with and depend on each other …