When I tell people I am dealing with Knowledge Management, I normally get one of these three reactions:
Wide eyes: What the hell are you talking about?
Appalled eyes: How the hell can you work voluntarily on this?
Pitiful eyes: Why the hell do you join a sinking ship?
While Nr 1 and 2 are easy to deal with (they either never got in contact with KM- or in a way one shouldn’t get in contact with it), Nr 3 is a more difficult one. Because it is justified to ask if KM isn’t dead already.
There was the time when everybody had to do KM. Which in most cases meant document management (please tag your documents according to this taxonomy here and store it in the folder according to these rules here and be sure the document has the structure given here) or implementation of After Action Reviews or World Cafes (please block two of your precious working hours to sit with us discussing what may be useful one day after you left the company or are retired). Accordingly, and that’s where reaction 2 occurs, people got very bored by those consultants learning their organization how to improve. And management did not see the effects expected. So KM faded….
Tom Davenport, one of the “Big Ones” of KM, lists in his LinkedIn article more reasons for the ship to sink:
- It was too hard to change behavior
- Everything devolved to technology
- The technology that organizations wanted to employ was Microsoft’s SharePoint
- There was often too much knowledge to sort through
- Google also helped kill KM
- KM never incorporated knowledge derived from data and analytics
He concludes: Any chance that this idea (of KM) will come back? I don’t think so.
Kaboom…. Even the gurus don’t believe in it anymore… But although all those points are relevant, isn’t something else even more blamable?
By looking at KM strategies, we often see big projects, carefully planned, with defined outcomes. Designed within project management tools including process owners, aims, activities. And, I am sure, monthly reports.
But knowledge is human, and it’s management is dependent on human interaction, human needs, human motivation. It is not a process or a production chain.
And- it is AGILE. What you need to know today is not the same you need to know tomorrow. What sounds perfect for one group may not work for the other unit. What started to be useful at one point may not be useful anymore later.
So why not look at software development again? How does this sound:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Want to read more? Agile Software Development
And want to know how it’s done?
It’s done in a self-organising, trustfulness team. Uuh, sounds familiar, not?
It’s done with face-to-face communication. Heard about this before, not?
And: it is done iterative. Small steps are taken. The product is evaluated frequently, the requirements are re-defined frequently, the customer ( aka the users) are included frequently, and the whole team supports a flexible mindset and planning.
And that’s how management of knowledge should be executed too. Start with something small; talk to people about their needs and about their experiences with what you implemented so far; redesign according to what you heard; let people evaluate again; expand to the next level; talk to people; redesign; evaluate; expand; talk; redesign; evaluate; expand…
So follow Davenport: If another notion that’s related to yours comes along and gains popularity, don’t shun it, embrace it. Implement an agile approach to your knowledge management!
Picture taken from https://pritamsen.wordpress.com/tag/agile-software-development/