Knowledge Management Series - Considering where knowledge is stored

There are many ways to start a knowledge management journey such as starting in one specific area of your organisation, focusing on a set of key stake holders or just building a business case for the value of a large scale program of work. For this series, I will focus first on where your knowledge is stored, considering the different areas and ways that information can be held. This will help you later to consider how you make use of that information to help the right people at the right time.

This is part two of the Knowledge Management series. For other parts, see links below:

So where would you find knowledge in your own organisation? Your are probably thinking of formal locations such as your Intranet, support guides, wikis and formal documentation. You may also be thinking of less structured areas such as your departmental shared drives or your Share Point Team Sites for collaboration. But what about all those conversations people have in Teams and in email, chats that take place in meetings and all that incredible experience stuck in people's heads? I bet that you can think of many times where you have read a formal document but still needed to contact the author or even someone else that you know with the experience. With even the best Knowledge Management programs, huge swathes of knowledge will still be stuck in people's heads. So what should you do?

Types of knowledge

Knowledge can be broken down into two key areas:

  • Explicit knowledge - knowledge captured for the purpose of holding knowledge
    • Structured content - e.g. Record management systems
    • Unstructured content - e.g. File shares, wikis, meeting minutes
  • Tacit knowledge - knowledge held informally that can be hard to share with others
    • Discussion forums
    • Enterprise social media
    • Emails

A third area sometimes cited is implicit knowledge which is the knowledge that is primarily in people's heads. If you think back to when you joined a new organisation or a new team, then there is always that time where you pick people's brains about what to do and how to do things. If you are lucky, then there is a page or document that lists things out but there is always that implicit knowledge not written down even if it is as simple as the best time to beat the crowds for the coffee shop.

You can think of these three areas as a scale with explicit knowledge in structured areas being the hardest to capture and maintain but the easiest to search and navigate knowledge and implicit knowledge being the hardest to find but easiest to capture.

Types of knowledge

So where is your knowledge held and what types of knowledge do you have?

Do you have formal record management or document management? The first steps to getting your knowledge into a usable state is to build out a knowledge map which helps you to capture the areas with knowledge at that point in time. It is important to realise that it will be an iterative process as you start to think about the knowledge, discover locations for that knowledge and then realise other areas of knowledge. If you are looking for more assets on knowledge maps then APQC (American Productivity & Quality Center) have a lot of tools available, some for free but most for members. Much of what I have learnt recently has come from one of their books, The New Edge in Knowledge which I would recommend even though it is a little old now.

The video below is a replay of a mapping of the Etiquette of Microsoft 365 knowledge, considering where useful knowledge could be held to learn more about etiquette insights similar to those we have captured for GreyHatBeard. You can see that I think about the main areas and then start extending that to specifics where known and building out the connected areas. It can also be useful to start considering at this point how much knowledge you have in each area and how much you would like to have.

Mapping etiquette of Microsoft 365

You may be looking at this and thinking that this is far too basic for an organisational knowledge map. That is certainly true and this lower level example would work better for an individual team or area. APQC include a set of examples of knowledge maps for enterprise, cross-functional and process/role based maps in their Getting Started with Knowledge Mapping document.

The important consideration is not about the technical systems themselves but the knowledge in them and how it is used. That is the key really - how is it used. Which brings us neatly on to the next in the series on how you can organise your knowledge.

Photo courtesy of NASA via Unsplash

NB - if you noticed that the animated gif was from a OneNote and wanted to do the same, this video has info on how I made it - OneNote Playback for Meetings – Modern Workplace Tips