Imparting knowledge through storytelling, Part 2

This is the second installment of a two-part series in which author Tom Reamy discusses the need for organizations to create a "knowledge architecture" that captures the knowledge transmitted through storytelling.

By Tom Reamy

As Peter Orton of the IBM IBM Story Project put it, “One of the most important yet least appreciated facts about story is that perceivers tend to remember a story in terms of categories of information states as propositions, interpretations and summaries rather than remembering the way the story is actually presented or its surface features.”

So I would argue that stories can be deconstructed, captured, indexed, analyzed and retrieved and that the sum total of all that activity, if done well, would be to enhance, not kill, the magic and power of storytelling in the corporate world. The only real danger would be from an attempt to substitute the indexed, deconstructed story for the living, breathing, evolving story.

The outcome of all that analytical activity would be a library of stories structured and indexed to facilitate retrieval. The library can be used to compare stories or extract general common elements. We can create an abstract or summary of the story that will enable people to decide if that is a story they want to read/view/hear.

For example, someone searching for help on how to deal with customers with certain needs might launch a search within a knowledge retrieval system. A search result could return a list of links to documents and Web sites, a set of related documents (and how they are related) and some links to stories that illustrate how to deal with different kinds of customers.

Another use of a library of stories can be seen from the example of case law. Stories, especially stories that contain best practices and other lessons, can be used both formally and informally, as part of a real-life education and training initiative. Just as lawyers study specific cases to gain both general knowledge and specific real-world knowledge, so stories can be used to train sales reps or customer service reps or whomever.

There is, however, a unique aspect to a library of stories that information libraries don’t have. Stories are fun and interesting to human brains, and a library of stories becomes an educational tool just by its very existence. If it is set up right, people will browse and read/view/hear just for the fun of it—and they will learn lessons and culture as they have fun.

Another reason for capturing and deconstructing stories and creating libraries is the growing virtualization of businesses. As communities become more virtual, they will need stored and indexed stories to overcome their separation in space and time. Adding a collection of captured stories to a virtual community can enhance those communities and make them more powerful and effective.

Libraries of community stories not only enhance those communities directly, the act of creating a community library can reveal the rules and values of our formal and informal communities. We are then in a position to use that knowledge to support those communities better and to better understand how to maximize the value of those communities within our organization.

How do we capture stories?

If we accept that we should capture and deconstruct stories, the question then becomes, how to do it—how should we represent stories, both in terms of capturing active stories in their native habitat, communities, and how to go about creating effective stories that can function as a resource for all communities.

There are many ways to capture stories, some better than others. For example, stories are often referred to as water cooler stories, so one method might be to install audio and video bugs at every water cooler to capture everything that is said. I can only think of a few dozen reasons why that might be a bad idea--nobody has water coolers any more, the job of winnowing out the interesting stories from the chaff of self-puffery would be roughly comparable to a job monitoring the infinite number of monkeys typing on an infinite number of typewriters to produce the works of Shakespeare, all our employees would either stop talking or quit, we would be liable for the most interesting lawsuits, etc., etc.

OK, so that is one way not to do it. Some ways to do it are:

First, we need a central group to administer, metatag and facilitate story capture. That group could be an intranet team, a corporate communication team or a dedicated knowledge management team. It could include members from all three, plus people from our library and/or training and education. Some activities of the group could include adding metadata, maintaining a library of stories, teaching story skills, publicizing the role of the story library and facilitating the story capture process.

Another essential component is to create a reward system for submitting stories to a central repository of stories mapped to the communities within which they are generated, and publish the whole process on the intranet. In that case, the whole process includes authorship and rewards, as well as the stories themselves. The process should take place within a highly visible storytelling medium—corporate magazines, recognition and awards, monetary and otherwise.

Capturing stories also means representing the content of stories in a variety of ways. For example, stories could be submitted in text format, but it would work much better if they could be done verbally. People will tell stories for hours, but ask them to write them down and 15 minutes seems very long. Until we have speaker-independent voice recognition, that would mean having a person and/or camera on the listening end.

In addition, there are at least two very different ways of using multimedia to capture the richness of stories. The first is to create a movie that captures the story and/or exemplifies the story in a way that goes beyond simply a talking head telling a story.

Those movies could be anything from edited actual stories (talking heads with music, visuals and animation) to mini-movies that present the story. A variation might be filmed scenarios or case studies.

We might want to use human actors for some stories, or we could generate a stable of animated characters that could be used and reused. Another option would be to offer the chance to star in a movie as a reward for submitting the story of the month with, of course, the option for the shy to bow out.

That might sound extravagant but with the development of Web technology, Web cams, relatively cheap and easy-to-use equipment and software, and advances in animation, a company could put together an internal team or hire external contractors for not much more than existing corporate communications teams.

A second way of using multimedia to represent stories is to create a multimedia representation of the elements of the story and their relationship.

One reason stories are so powerful is that they contain so much in such a small amount of packaging. To try to capture all the multidimensionality of stories in simple text would expand the story-reading experience to mind-numbing size, not to mention academic jargon overload. One way around that is to represent the multidimensionality with a multidimensional multimedia. For example, a hyperbolic tree representation of the relationships between elements of the story could be combined with sound and video effects as the reader/user explores the story.

Other than as a way to find employment for out of work video artists, why would we go to the trouble of adding all those elements to a story that can be told face to face in three minutes? Two reasons come to mind: virtual communities and the design of the human brain. Of the two, I find the latter reason the more compelling. Quite simply, our brains are designed to work better when more than one sensory channel is activated by incoming stimuli.

So, if that multimedia presentation activates more parts of the brain, two things happen, people can pay attention better and they can remember better. Those seem like good reasons to me--as long as we remember that not all stories can be so treated--and the economic payback spot will vary from company to company and over time.

Knowledge architecture--metadata for stories

Regardless of how stories are captured, stored and represented, in order for anyone to find them again we need to develop a reference or indexing system based on metadata of some sort. Just as with the case of representing stories, an index or metadata schema for stories needs to be much more than a simple library reference system. The metadata schema has to be as rich and multidimensional as its subject matter.

However, a good place to start for any metadata system is still with the basics, in this case, the Dublin Core. While the Dublin Core is a good starting place, it is ultimately both too much and too little for a metadata schema for stories.

Many of the Dublin core elements are geared toward the necessary metadata we need to create a well indexed reference library, but they don't support retrieval as well as they should except perhaps for professional librarians and searchers.

But for informal communities, and real-time searching, that is, searching in support of job activities and procedures, it is not the right set.

The Dublin Core is too much for authors to easily add the necessary values for such fields as Rights, and too much like bookkeeping to fill out values for fields like Format, Contributor and the like. The Dublin Core is too little, however, when it comes to actually finding items. Outside the reference library, the most important Dublin Core elements are usually title, description (or short abstract) and subject (usually referred to as keywords). For good searchers, date and author can sometimes help. However, as has been often noted, search using simple keywords is not very powerful.

In general, what is needed is additional categorization or taxonomies of content and/or a controlled vocabulary or other organized conceptual set of keywords. They are in the process of being developed either within enterprise intranet environments or by vendor companies that are offering automatic and semi-automatic categorization with built-in world knowledge expressed in predefined ontologies.