When integrating knowledge management in an organisation the approach should be more along the lines of an intervention than an edict. The aim is to influence rather than dictate.
One can only increase the tendency and thereby the propensity for certain outcomes, but we shouldn’t say, “I am going to make this happen tomorrow.” That approach is never successful. Stephen likened the role of a knowledge manager to that of a gardener—a person who grows and tends a tree—not the person who’s building a bridge or a wall.
Picking up on this metaphor in The Knowledge Managers Handbook3:
People often think of knowledge as being organic. An ecosystem or a garden is a pretty good metaphor for the world of knowledge in an organisation. Knowledge is something that grows and develops. It can be replicated and seeded. It is not something solid and static like a car or a factory or a coin that can be grasped and controlled and physically managed … it needs to be nurtured and tended.
Marketing and communications are two areas where knowledge management can learn about how to approach implementation because they have a bottom line incentive to get this right for their organisations. To understand consumer behaviour and how people think when they decide to buy or not to buy, gives us a pragmatic insight into individuals and organisations. While much of that has been empirically validated, an interdisciplinary exchange with knowledge management has been lacking.
Stephen pointed out that he hopes that knowledge management will start integrating all these relevant disciplines into our thinking, so that when we contemplate a problem we bring in a holistic view from the disciplines that deal with people and systems, and work out how we can solve a problem. If we can build a stronger outcomes focus, then we can start delivering real outcomes for people in a way that makes a difference to them.
Breaking this down into a three-step analysis we need to ask:
- What system are we influencing?
- What changes do we want to see?
- Is there any evidence for using one approach over the other?
When we look at our knowledge toolbox we shouldn’t reach automatically, for example, to lessons learned because we’ve used them in the past and liked them. We need to understand the reason why, and then deploy the toolbox for a purpose. There should always be a business problem you’re trying to solve when you deploy a tool. If everything is done with the purpose of solving a particular business problem, and deploying a particular solution towards that outcome, then it makes it much easier to justify the value of what we do.
References and notes: