Storytelling and Knowledge Management: Part 4 - Documenting and Sharing Organizational Knowledge

Story telling can play a powerful role in one of the most basic tasks of knowledge management, i.e. collecting information from one team in order to support another team. In most elementary knowledge-collection processes the focus is only on collecting materials. If this application is more sophisticated then the abstracting process is more efficient as documents will be correctly described. This is an excellent first step, but it is seldom sufficient to simply capture a document and give a description. Unlike a magazine article or a book, most of the knowledge that we collect in a business setting is part of a larger project or plan. Without this contextual background the use of that document, no matter how well catalogued may be greatly reduced.

Consider the example of Hughes Space Division. The company made a strong knowledge management effort collecting and making available the designs of their engineers. They then discovered that these designs were not being re-used. Engineers involved in building multi-million dollar satellites were unwilling to use the designs of others because they did not understand the context of how the previous design had been developed. Context was required to explain the history of the designs, so engineers were encouraged to engage in dialogue in order to unlock the knowledge within their colleagues’ minds (Davenport & Prusack, Working Knowledge).

To make knowledge collection and knowledge sharing more effective, one must go beyond simply abstracting documents from explicit knowledge sources. It is necessary to provide a story of the document. One of the techniques that we have found to be extremely useful, especially in collecting team knowledge, is to build a central record that contains the story of the team. It describes the overall problem they faced, the steps they took and some of the lessons they learned. Once this story is complete, individual documents can be linked with their abstracts within a central record. This solves the problem of providing a context for these documents and the project as a whole. Here is a great opportunity for blogs.

In a project we did for Ryder, the context of documents was documented along with the documents themselves and placed within the same taxonomy. This was done through Lotus Quickplace, the team workspace that was used to support and document the activities of the team that created the document. Much of this functionality has migrated the more robust Lotus Workplace. Blogs can play a similar role. They can also help personalize this storage of stories help to organize the context for them within your personal knowledge management system.

In a project where we helped a team begin to collect their knowledge, we found that by using this story telling technique, we not only improved the positioning of the knowledge but the collection of it as well. Once team members realized they were building the story of their team, they also realized that certain key documents were missing, so these were added to the tale as well. They also worked to arrange the contributions into a consistent framework, which then made the knowledge easier to use. Finally, they revisited the newly created story and added a section explaining how they had collected and arranged the knowledge. This would help future teams understand the reasoning behind the architecture of contributions. Wikis provide a great tool for this collaborative story creation.

This idea of focusing on stories can be taken one step further. One of the more powerful knowledge management tools that we have found is the use of story tools. Story tools - or advisory support tools focus on capturing the experiences of other team members in order to make them available for the entire team.

Consider a customer service example. If a customer service representative encounters an entirely new question, they can pull up the story tool to see if any of their team members have encountered a similar question. If they find a similar question, they can then learn how that customer service representative solved the problem. If they cannot find a similar problem, then after they have researched the answer they can add their case story to the repository so that it is available to the team for future similar encounters.

This type of tool is extremely useful for repetitive team tasks since it allows the members of a team to learn from each other. The technology to build this type of tool is not extremely complex. It requires a basic repository with a fairly powerful search engine. A blog will work well here. Getting the business process correct is critical. Use of the tool, contribution to the tool and the management of those contributions all need to created. If they are not, then this is just another pretty piece of software.

Useful guidance in documenting stories can also be as simple as creating a series of structured questions on a contribution form that help to determine the plot of the story: What occurred? Why did it occur? What are the implications? How can it be improved? The use of forced choices for categorizing information provides the contributor with a framework that is aligned with the organization’s desired categories. The contributor can then create a meaningful story out of the data according to guidelines.

David DeLong describes a tool to support similar processes in Lost Knowledge: Confronting the Threat of an Aging Workforce. PHRED Solutions provides a guided approach to capturing and archiving the results of story discussions around workplace issues. Their package, APS, leads teams through the politics and personalities to the document answers the problems groups are facing. Then, they archive the best solutions in case similar issues pop up again.

Comments

[Carla Verwijs]

Hi Bill,

I like your story! Have you read the book from Yiannis Gabriel (Storytelling in organizations)? I just found it in the library and was surprised I've never seen it referred, because it's interesting stuff he writes (but I'm still reading). It's a more academic book.

Can you tell a bit more about the tools that you mention in this part of your series? When you say 'capture'(a story), did you use video, write them down, audio tape it or something else?

[Bill Ives]

Carla

Thanks for your comment and I will check out the book. The tools vary. With the exception of the PHRED Solutions listed in the post, they are standard tools that are not designed specifically for stories, generally those already used within the organization like a content management system or data base. Usually, it is simply text. However, I have been part of a program that did video recording of insurance claims adjustors using a custom tool. But this was before all the video recording devices such as video blogs and it would no longer be necessary to create a cusotm tool now. I think blogs offer a great vehicle for recording stories. The key, though, is not the tool but getting people to record and then use the stories.