Thursday, 4 July 2013
I am going to come right out and say that I am not a big believer in Serendipity as a mainstay (or even a main component) of a Knowledge Management approach.
Serendipity means a "happy accident" or "pleasant surprise"; a fortunate mistake (according to wikipedia). Would you want to manage anything through accidents, surprises and mistakes, no matter how happy, pleasant and fortunate?
To add to the sayings "hope is not a method", perhaps we should add "accident is not a process, surprise is not a strategy". Would you manage anything else by serendipity? Imagine HR management by serendipity, or financial management.
To be fair, nobody ever suggests serendipity as being the primary cornerstone of their KM approach, and instead it tends to be suggested as part of a KM approach, involving engineering situations or office environments which promote serendipitous encounters between people who have knowledge, and people who might need it. And serendipity may be useful in the early stages of KM, before the internal systems are in place.
However my point is that in a mature Knowledge Management Framework, if people need to share or find knowledge, then serendipity should be the last resort. Instead you should be looking at building the necessary networks, embedding the necessary processes and acquiring the necessary technology to allow the encounters between people to be deliberate, routine, and part of normal business. And then support this with the Asking culture, so that if someone needs knowledge, they ask, through a channel that ensures the knowledge holders will be aware of the request. Communities of practice, for example. Don't leave the transfer to be the result of a happy accident.