Dead or alive? Act agile!

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/

Knowing what it is that we know- using storytelling to get to our knowledge

In the management of knowledge, neither the individual nor the community is fully aware of the depth or range of its knowledge. Asking an individual what he knows in isolation from context of knowledge use just does not work. Useful knowledge is triggered by events and circumstances. So one has to re-create the events and circumstances in order to identify knowledge.

Observation of knowledge use in day-to-day business works when business cycles are short. But in long-term settings, other approaches need to be implemented.

Interviews fail as while describing the past, history will be changed to ensure the story of the past meets the requirements of the present (e.g. sale numbers).

But indirect approaches like storytelling provide the needed information. Storytelling as a pervasive technique that triggers the memory of knowledge and triggers a desire to acquire knowledge.

As an example, workshops can be undertaken where teams talk about the former cases of lost and won businesses in a relaxed atmosphere. Teams should be prevented from telling stories in a linear time sequence as their inevitably led to distortion as a pseudo-rational model was imposed on the past. Free flow stories reveal a considerable number of decisions that would not have been revealed through conventional interview, and some material is only triggered to be remembered by a powerful story from another team member.

Observers then note every decision made and consolidate them into simple flow diagrams which are then consolidated by the team members. For each decision point, the participants were asked which knowledge they used there, both explicit and tacit.

The result is an idealised model of the decision process and associated information forms and a consolidated register of knowledge assets used.

Distributing knowledge to a wider community

For effective knowledge transfer, an interaction between trainer and trainees is necessary as knowledge is contextual. By collecting anecdotes, underlying values and rules can be identified. Anecdotes can then be decomposed and reconstructed to stories that include the desired values and rules.

In distant learning, anecdotes told in the non-virtual course can be collected, decomposed and re-written with the main values, rules and characters to guide through the online learning, to create identity and the drive to bond, to entertain and – to motivate!

Based on Storytelling and other organic tools for Chief Knowledge Officers and Chief Learning Officers; David Snowden, Founder of the Cynefin Center

Which KM tool to choose

Knowledge Management can be anything that in one way or another facilitates communication, cooperation, and sharing of knowledge within and between organizations.

This opens up the field of possible knowledge management tools, methods, and techniques for anything from simple box lunches to complex and expensive enterprise knowledge management suites. There is no one KM tool, technology, or method. In KM „Anything goes!“ For this reason KM is a very creative and quickly changing field.

Chief Knowledge Officers (CKO) must know about a great variety of different kinds of solutions, IT-based, organizational, and interpersonal. Not only that, but CKOs also have to make decisions about which tool, technology or measure is the best in every different situation to implement.
From the CAS Course in Knowledge Management by IKF Luzern

It is a major principle of my work to not apply a tool just because it is a KM tool (and has a cool name), but to find the most appropriate one for every situation. A KM tool or method needs to bring exactly the outcome wished for, with the least possible effort and the smoothest possible implementation in the day-to-day business. The vast number of possibilities may seduce to choose something fancy that sounds impressing. But it is the simple tools, the ones already used in an organization, the ones people are familiar with, which are the tools to choose.

Enhancing the knowledge environment

Every organisation already has an environment in which processes exist to help people create, find, make sense of, and share knowledge. Knowledge management strives to identify and enhance that environment, and to transform it into a culture.

Modified from „Crafting a Knowledge Strategy“ by Shawn Callahan, Anecdote Pty Ltd

When starting a knowledge management project, it is of high importance to first truly analyze the current processes, (human) knowledge nodes, and cultural foundations for knowledge sharing in the organization. Based on that analysis, a few (from one to three) small projects should be chosen that reflect the haves and wished-to-haves, that can be realised in a reasonable amount of time, and that will have a visible impact for the involved employees. The implementation of these small projects will lead to the first transformations. In subsequent steps, the defined characteristics can then be applied to larger and larger projects and processes- from personal processes to business unit processes to the whole organisational structure and culture. In this transformation, some parts are implemented within weeks, but the whole framework may take years and years.

The Concept of „Ba“

The Concept of „Ba“: Building a Foundation for Knowledge Creation was written by Ikujiro Nonaka, one of the founders of the SECI- model, a major basis of knowledge management.

In order to create new knowledge within an organisation, an advocate culture needs to be implemented first. One aspect is „Ba“- a space in which relationships can be initiated and cultivated to build trust and mutual understanding and, at the end, to create knowledge. Without not only having the opportunity to but also being encouraged to spend time in such a space without the pressure of showing direct results, knowledge sharing and creation will never take place within an organization. Knowledge is bound to humans, and humans need trust to communicate and exchange.

http://home.business.utah.edu/actme/7410/Nonaka%201998.pdf