Originally published on May 9, 2017

33rd in a series of 50 Knowledge Management Components (Slide 44 in KM 102)

Repositories: structured lists and databases that allow documents and other files to be stored, searched for, and retrieved

A knowledge capture process requires a place to store what is collected. A repository is such a place, designed to be easy to use for storing and retrieving content. It can take the form of a database, a list or document library within a tool such as Microsoft SharePoint, or a collection of files within an intranet site, team space, or portal.

When creating a knowledge repository, decide on what type of content needs to be captured. Plan for storage capacity that will remain adequate even as the number of collected files increases dramatically. Define the metadata that will be required for each submitted file. Decide on a structure: hierarchical folders, different list views, faceted taxonomy navigation, or metadata-based search. Specify a contribution process. Ensure that search can be properly integrated so that contributed content can be found. Consider publishing the list of the latest submissions, providing alerts for posted material, and otherwise highlighting new content so that users are made aware of it.

Examples of repositories include project databases that capture key information on all projects, customer support knowledge bases that capture problem resolutions, and proposal libraries that provide an archive of all customer proposals.

A knowledge base is one kind of repository typically used to store answers to questions or solutions to problems enabling rapid search, retrieval, and reuse, either by help desk personnel, or directly by those needing support. A good example is Knowledge Centered Service (KCS).

In addition to providing a way for users to browse and search to find content, repositories are also useful in conjunction with threaded discussions. When a community member asks if a specific type of content is available, another member can reply with links to instances within existing repositories. This is an example of combining collection with connection; content has been collected and stored in a repository, and a connection is made between people to take advantage of that content at the time of need.


1. Where Knowledge Management Has Been and Where It Is Going — Part One by Nancy Dixon

The early thinking about how we should manage this knowledge asset, was to use technology, taking advantage of the growing capability of intranets. There was an effort to collect all the important knowledge that an organization possessed into one database. The analogy was of a warehouse or a library. People were to put knowledge in the warehouse and those that needed it could take the knowledge out and use it. And much like the contents of a real warehouse, knowledge was thought of as stable. That is, you could put knowledge in the warehouse today and get it out in six months or even two years later without any degradation of its value. In this first era of knowledge management, knowledge repositories were the strategy of choice and they contained best practices and lessons learned as well as technical documents.

Repositories were so ubiquitous that in many organizations the term “knowledge repository” was synonymous with “knowledge management.” And since IT necessarily built the repositories, KM was frequently placed under the IT department.

There was one further assumption, which was that employees would seek out the captured knowledge and use it. But of course, in many organizations people did not readily submit knowledge nor were they inclined to take it out of the warehouse. Managers determined they would have to incentivize employees to get them to use the knowledge. Lots of schemes were put in place, from offering frequent flyer points for input to requiring teams to go through the database for ideas before starting a new project — and checking a box in the project plan to prove they had looked the ideas over.

For the most part these databases, even with incentives in place, did not produce much improvement. Front line workers had little interest in putting things in or taking things out.

2. Don’t wait for knowledge to be volunteered — go ask by Nick Milton

Waiting passively for voluntary contributions is the wrong way to populate a KM repository. Knowledge can’t be conscripted, it can only be volunteered, and often it won’t be volunteered until you ask.

This is an outcome of the problem of the unknown knowns. Often people don’t don’t realize they have learned something, until they are asked about it, or have the chance to discuss it.

Sometimes you find organizations who have set up a system whereby people are required to identify lessons or new knowledge themselves, and then to add them into a knowledge repository. I am not a huge fan of volunteer systems like this; I don’t even like them for collecting innovation suggestions. I think you capture only a small proportion of the lessons this way, because people are not aware that they have learned anything, and if they are aware, they often discount the learning as “not important”. Also, self-written knowledge is often superficial, because there hasn’t been the depth of dialogue and questioning to get to the lesson.

I am not arguing for forcing people to share knowledge, but I am suggesting that you don’t wait for the volunteers to come to you. Instead you give people scheduled facilitated conversation-based opportunities where they can become aware of what they know, and which provide a safe and encouraging environment for them to volunteer the knowledge when asked.

There are many advantages to the scheduled approach. Firstly, success and failure are components of every project, and if every project is reviewed, lessons may be identified which can avoid the big mistakes later on. Secondly, if lessons identification is scheduled, it becomes a clear expectation, and the company can monitor if the expectation is being met. This expectation is common in many organizations, though the rigor with which the expectation is met seems to vary. Finally, by scheduling and facilitating the learning dialogue, you can uncover the knowledge that nobody knows they know, until they start to discuss it.

Don’t rely on people volunteering their knowledge spontaneously. Instead, set up scheduled processes which provide a request and a context for volunteering.

3. How does an organization know what it knows? by Dave Snowden

How does an organization know what it knows? That question drives a lot of interest in knowledge management. It drives a lot of spending on consultants and technology. It drives a lot of effort trying to extract the “knowledge trapped inside people’s heads” with explicated and documented content in searchable repositories.

Disconnecting knowledge from its source, in terms of people and places, will remove from that knowledge the very context which infuses it with life. Because indigenous knowledge is continuously generated and renewed in the living practices of people, archiving in isolation from practice removes its ongoing relevance.

Example: HP’s Project Profile Repository


  1. Knowledge Repository and Knowledge Management by Sunita Sijwali

18. See the section on software in Lessons Learned

Knowledge Management Author and Speaker, Founder of SIKM Leaders Community, Community Evangelist, Knowledge Manager https://sites.google.com/site/stangarfield/