The concept of the Knowledge Supermarket, and how to apply it

Your knowledge store should support people who browse as well as people who search. It should be like a shopper-friendly supermarket.

Image from wikimedia commons

Some shoppers know exactly what they want. They walk into the relevant store, ask an assistant where to find the item, and buy it. Others are open to serendipity, and prefer to browse. They don't always end up with what they went into the store to buy, but often end up with a better purchase.

You can see similar behaviour among the customers of online knowledge bases. Some know clearly what piece of knowledge, or document, they are after, and use targeted search to find it. Think "Google".

Others are not so sure where the knowledge lies, and prefer to browse. Think "Wikipedia", with its ability to follow links to find what you want. 

We need our knowledge bases to cater for both types of customer. We need good effective search for the people who know exactly what they want (implying that content needs to be well tagged), and we need a browse-friendly structured site so people can find what they need, even if they didn't know it existed.

Here a bricks-and-mortar grocery supermarket is a good model. I say "bricks and mortar" as many people find online supermarket grocery shopping to be a very different experience.

Bricks-and-mortar supermarkets rely on people browsing to the content they want so they can buy it. They also give a lot of thought to pointing the customers towards other products, which they might not have known they needed. Every aspect of a store’s layout, from the flower display near the entrance to the chocolate by the check-out is designed to stimulate "shopping serendipity".

• Flowers, fruit and vegetables at the entrance make the store smell and look good
• Quick-use "grab and go" items such as snacks and bottled water are at the entrance, for people who want to shop quickly
• Promotional items are at the aisle-ends, so are in plain sight 
• Products are grouped by type (pasta, tins, cheese, butter) to make them easier to find
• Popular high-value items are displayed at eye-level
• Often there are themed displays - a Mexican section with sauces, tacos, tortillas, refried beans for example, or an Indian section with curry spices, sauces, poppadums and Naan bread - so you can buy all you need for a single meal
• Warm colours attract people to a store, hence the warm brick exteriors. Cool colours inside encourage more contemplation and higher sales
• Loyalty cards are used to track customer activity, and to learn more about customer behaviour. 

Can we use similar principles to encourage users to browse our knowledge bases? 

We could try 

• similar approaches to colours for example, or 
• putting the high value items in the high-visibility page space, 
• promoting new knowledge where it is most visible, 
• grouping and associating content in folders or on index pages so that all knowledge related to a particular process or activity is found together (see here), 
• placing the "grab and go" items on the front page, and
•  using web metrics to understand the behaviour of our knowledge customers, so we can improve the design of the knowledge base.  

If we make our knowledge bases a little more like a grocery  supermarket, we stand a better chance of attracting and keeping the browsing customers, and helping them to find knowledge that they didn't even know they needed.

Optimising for the internal search engine

Internal company search seldom works as well as Google, because so few people optimise the findability of their content.

Image from Wikimedia commons

People often cite Google as the gold-standard in search, but partly Google works so well because of the prevalence of search-engine optimisation in the World Wide Web. Anyone who uses the web as a market place or a means of making publications available, knows about the issues of Search Engine Optimisation. And if you own a website, you probably receive 10 emails a day from people offering to improve your SEO ranking.

As far as internal sites on the Intranet are concerned, there probably is little thought given to optimising search. Metatags may be missing, document titles may be poor or unhelpful, documents may be filed in unhelpful ways (see my post on "a haystack is no place to store your needles"), and the whole issue of findability is often ignored.

I remember in the mid 90s when BP introduced their first Intranet, and the manager of BP Norway (my boss at the time) set up a BP Norway home page. It went live, and the next day we went onto the Intranet, typed in the search term "BP Norway", and .......... got no results!

It turned out that the words "BP Norway" only ever appeared in banner graphics, which had no Alt tags (I don't know if this was even possible at the time) and were therefore invisible to the search engine. Therefore this whole site had become unfindable, or search-engine-impaired.

Part of the role of the Knowledge Management team, in any organisation that makes extensive use of codified knowledge combined with search, is to educate the owners of the knowledge stores about how to ensure findability and about the need for optimising codified knowledge for the internal search engine.

Maybe in this way we will get a little closer to Google. 

How newly hired graduates search for knowledge?

How do graduates search for knowledge, and what this means for KM.

 

Image by mohamed Hassan from Pixabay

Here (summarised here and slides here) is a really interesting study about the difference between the strategies that new-hires use when seeking for information and knowledge, and the strategies their employers expect them to use.  

The study was conducted in 2012, so some comments about the digitial illiteracy of non-graduates may no longer be valid, but there is still some very interesting material there.

The study is summarised as follows

"Overall, our findings suggest a dramatic shift is occurring in the workplace related to how information is found and used.  

"We found the traditional research competencies—the use of non-digitized information sources—may be disappearing with each passing year as a new batch of college hires joins the workplace and employers make assumptions about their information competencies.  

"We found that few, if any, of the employers we interviewed said they hired college graduates solely because they could solve information problems in record time. Yes, employers recruited hires with the ability to conduct online searches. At the same time, however, other qualities also mattered.  

"In particular, employers expected hires to possess low-tech research competencies, such as the ability to make a phone call, to poke their heads into a co-worker's office to ask a question, to interpret results with a team member, or to scour a bound report. However, many fresh-from college hires sorely lacked these traditional research competencies.  

 "These low-tech information skills are essential to the workplace research since so much information in the workplace is contextual and highly individualized to the operations of the organization itself. But many of these young adults considered perusing the index of a print volume or picking up the phone to consult a colleague as outdated as using an adding machine to balance the payroll.  

"These findings, of course, warrant further investigation. But they are certainly plausible as more and more information becomes digitized, as each new crop of college graduates is more than likely to be “born digital,” and as employers continue to make hiring decision based on online information gathering proficiencies".

Most graduates in the study focus groups said "they found it difficult to solve information problems in the workplace,where unlike college, a sense of urgency pervaded and where personal contacts often reaped moreuseful results than online searches.... New Hires tend to use online searches  in preference to any other mechanism, often using cursory search". 

The report states that "Most college hires were prone to deliver the quickest answer they could find using a search engine, entering a few keywords, and scanning the first couple of pages of results, employers said, even though they needed newcomers to apply patience and persistence when solving information problems in the workplace".

Given that searching and finding are crucial components of KM, then the implications of this study for Knowledge Management are as follows.

1. Graduates need induction into the company Knowledge Management framework and how to use it, including the location of the knowledge stores, and the communities of practice, to avoid the default of cursory use of search engines.
2. If graduates default to online search, then there needs to be a knowledge base for them to find; even if it is just an index of "people to contact"
3. New graduates need, as part of their induction, to be introduced to as many people as possible, in order to start building the social networks that can replace online search.
4. They need to be inducted into the relevant communities of practice, as in the office world, 80% of the knowledge is undocumented, and will never be found through online search.

The search habits of new graduates are "search first, ask later (if at all)". Until those habits change, make sure there is something for them to find even if it is only the name of the person to ask. Make your knowledge findable, especially by new hires.

A haystack is no place to store your needles (findability in KM)

If you want people to find your needle, don't put it in a haystack. And if you want people to reuse your knowledge, but it somewhere where it can easily be found.

One of the companies we work with collects knowledge as "case studies". Currently there are over 20,000 case studies in their case study library, and finding a relevant study has been described as like finding a needle in a haystack.

My point, however, is that the needle should not have been put in the haystack in the first place.

One of the key issues in KM is findability.

 People will not use knowledge if they cannot find it. Re-use is the end-game and the primary goal for KM, and findability is one of its main supports.  A massive monolithic database of 20,000 cases is a haystack, and knowledge within it is very hard to find.

So where would you put your knowledge, if you want it to be found?

To answer this, think about where you would put a needle, if you want others to find it.

sewing kit by Michelle on Flickr

For home use, you would put your needles into a sewing kit.

The sewing kit is a collection of tools to do a job. The kit is where you will find needles, pins, thread, safety pins, buttons and scissors. It provides you with the resources to do repair jobs on garments, all collected in one place.  The domestic sewing kit is a shared resource for all the needle-workers in the household. My wife uses it, as do her daughters, as do I when I need to sew on a button.

That's also how we need to package our knowledge.

We need to package our knowledge around the jobs that need to be done. Knowledge should be stored based on activity, rather than the type of knowledge. So knowledge on preventative maintenance - to take an example at random - needs to be stored in one place; case studies, lessons, guidance and standards should all be co-located, not hidden away in individual haystacks.  We call these collections of knowledge "knowledge assets" - a collection of the knowledge tools needed to do a job.

We need our knowledge to be a shared resource for the relevant community of practice - the maintenance community, in my example above. The knowledge asset is owned by the community, managed by the community, updated as a result of community discussion and knowledge sharing, and re-used by the community.

Keep your valuable knowledge in shared knowledge resources, whether you call them knowledge kits or knowledge assets.

Never hide knowledge in a haystack.

What's the best way to find "people who know"? Yellow Pages? Or Social Media?

A large proportion of your organisational knowledge is never written down, and is often too complex or too contextual to transfer in written form anyway. If you need to find this knowledge, you need find the person.  But how? 

This picture by unknown artist is licensed under CC BY_SA

The problem is similar to one you might face at home, when looking for an expert knowledgeable tradesman to fix a problem. Where do you look?

At home, most of us use one of two options.

Firstly, you might use your own network to find a trusted plumber, a good builder, a gardener who knows the difference between a plant and a weed. Then. if you need someone out of the ordinary and therefore outside your personal network, a "look-up" system is invaluable (Yellow Pages, or an online equivalent such as Rated People.com. Here you can find the registered contact details of everyone in your area with a specific set of skills and knowledge.

How can you emulate that at work? When is networking effective, and when is a  corporate Yellow Pages the answer?

Networking - advantages and disadvantages

The huge advantage of networking is that it is dynamic. People come and go, they join and leave the network, but the network remains. Through the connections within a network, you can quickly reach people you have never met; who are two or three degrees separated from you, but linked by mutual connections. Through asking a question in a community or practice, for example, you can often tap into a wide range of expertise. Networks requite little effort to maintain - they are usually self-maintaining. Other than the core group or the coordination structure they need little investment.

The disadvantage is that contribution in networks is voluntary and a network seldom reaches everyone with relevant knowledge. Network adoption, when purely voluntary and bottom-up, often stops at around 20%, so what happens when the knowledge you need is held by someone in the remaining 80%? When sponsored and promoted, communities of practice can reach far higher levels of adoption, but still levels of engagement are highly variable. Some staff are still suspicious of networking at work being purely social, and often it is the people you most want within the network - the older technical experts with a lifetime of experience - who are least willing to join. One of my clients constantly observes that "the experts just won't join the communities of practice". And without the experts, these communities have become communities of ignorance; lots of discussion but little knowledge exchange.

Corporate Yellow Pages 

The big advantage of the corporate Yellow Pages, if rolled out top-down, is that everyone can be registered, even the experts. You don't have to hope that a query will be passed (by the 20% of people active in the network) to the right person who will give you the answer. Even the obscure areas of knowledge can be registered and made available for search.

For example I was teaching a KM course in Trinidad some ago, demonstrating an in-house Yellow Pages system, and I asked the class “Has anyone got a topic you want me to search for?” A guy at the back called out “Microwave Towers”. He was putting a series of microwave towers in Trinidad to communicate with a remote base, and wanted to find others with experience in the company. So I did a free text search, and came up with one name, Stanley Patillo. So I said “There you go – someone else with experience” and he said “I am Stanley Patillo”. Well, at least he now knew that he was the sole expert on this topic!

The second advantage is that once you find the expert, the approach to them is a personal approach. Rather than a general request in a

The disadvantage of a  corporate Yellow Pages system is that it needs to be maintained. People have to keep their entries up to date, Even large public-domain systems like Linked-In suffer from this problem, and out-of-date entries are worse than no entries at all. However this is one-time effort, and doesn't require the expert to constantly monitor conversations. They can wait to be contacted.

Sometimes organisations try to use social-style personal pages as a substitute for Yellow Pages, but this seldom works, as I explain in a blog post from last year - the model for People-finders should be Dating sites, rather than Facebook-style personal pages.

What's the answer?

The answer, like so much else in KM, is that this is not an either-or situation.

Use both.

Use well-designed Yellow Pages systems, updated as part of the annual appraisal system, that work like dating sites, allowing you to find "just the right expert" for your knowledge needs.  Make sure the system links with the Communities of Practice,  and acts as an index of communities as well as an index of individuals.

Supplement this with Communities of Practice, which allow more free-form exploration and discussion within the community of practitioners. Make sure the communities link with the Yellow Pages system, and use this as a "list of members".

That way, you allow everyone in the company the chance to engage with the system they are most comfortable joining, and you allow everyone in the company two ways to find the right person with the right knowledge to solve your problem.

5 reasons why Enterprise Search will never be as good as Google

All the time we hear managers saying "we want a search engine as good as Google". Here are 5 reasons why you can never even get close.

Image from wikimedia commons

 Google is the yardstick for search, and managers seem to want internal enterprise search that works as well and as (apparently) intuitively as google. But there are 5 good reasons why this will never happen (bearing in mind that I am by no means a search specialist).


1) Search engine optimisation - webpages want to be found

Do you have a website? If you do you will be as familiar as I with the deluge of Spam emails offering to optimise my website for Google search. SEO (Search Engine Optimisation) is big business, and the owners of webpages are doing lots of work on Google's behalf to ensure their pages are indexable and findable and optimised for search.

But who, in an organisation, optimises their documents and sites for internal search? Let me tell you who - Nobody; that's who.  Unless you are very lucky, few if any people think about the issues of findability when they publish content.

Google is successful in finding sites because those sites want to be found. They are often very keen to be found, because they are trying to sell you something. The search results at the top of Google's list are often the ones most desperate to be found. Many documents in your enterprise system do not want to be found, often for issues related to confidentiality as described below.

2) The fact that the web is interlinked html pages, whereas your content is usually isolated word documents (if you're lucky!)

Sometimes it's not even Word documents - I know organisations that save their critical knowledge in pdf form!

The difference between interlinked web pages and isalted documents is critical. Google can crawl through the web of interlinked sites, can understand the context of a site partly through its links, and can identify authoritative or important sites based on the number of links that point to them. The search engine results at the top of the list are often the ones with the most backlinks.  The components of the page are also obvious to Google - the title, the first level headings, the metadata - and these also are used to understand what the page is about.

Your documents are not linked. Each stands alone. Each has to be searched and indexed separately. There are no backlinks. There is no visible structure to the document, other than to the human eye, and the search engine cannot tell a footnote from a level 1 heading.

3) The hordes of search engine specialists employed by Google.

How many search engine specialists do you employ? None, right? Google employs tens of thousands. That's one of the reasons their search works better than yours.

This is especially an issue if you are planning to use Semantic search, or to optimise customer search of your knowledge base. In these cases you will need a search engine specialist to build and evolve the ontology, track and improve the search accuracy, and define the synonyms and stop words.  However managers often neglect this aspect, and assume a search-engine is a one-off purchase that will run itself.

4) Google doesn't do "security levels"

Google assumes everything is available and visible to everyone. It doesn't do passwords or access restrictions or security levels. It searches everything that is not on the Dark Web.

A lot of your documents are effectively on the dark Web - they are in secure folders on Box, or Dropbox, or SharePoint. I consulted recently to an organisation that had 300 separate databases or document management systems. They had opened about 6 of these for indexing, the rest were effectively "dark" as far as search was concerned.


5) The web doesn't do version control

Every webpage on the web is the only version. Rather than storing a webpage as version 3.5 and writing version 4.0, you just rewrite and publish the page. Every page on the web is the current version, and is constantly under development. Google only returns one version of the page - the current version.

You don't treat documents in this way. Very often, unless your document management is very good, you will have multiple versions of the same document stored in different places.  One of the bugbears of enterprise search is that it will often find all these version in your search results.

So the next time your managers ask "Why can't we have search like Google" - 

you can reply - "Yes, we can, IF

• You move all content out of documents onto wikis
• You keep only one version of every document
• You train all staff in search engine optimisation
• You hire a team of search engine specialists, and
• You make all documents open to everyone".

Then see what they say!

Enterprise search can work, but it will never work like Google.

Search or Browse? Which is best?

Should you optimise your knowledge base for search or for browse? Answer to an online question.

I received the comment below on my blog post on "Knowledge documents vs project documents".

"I found this a helpful blog. I am working on the implementation of a matter management system within a large law department. One of the things I've been considering is the appropriateness of organizing documents within matters using a folder structure versus metadata and tags. 

"I have a hypothesis that it makes sense to use a folder structure to organize "project" or "matter" documents - because the folder structure operates as a story map, and helps people understand what is involved with the specific project/matter. Browsing for project documents seems intuitive. But it makes sense to use metadata to classify "knowledge" documents because users are likely going to want to find knowledge documents through "search" as opposed to browsing. 

"I'm interested in hearing reactions to that hypothesis."

Firstly I am pleased the blog post was helpful! Then I have two answers for you below.

This is the dilemma of optimising for search or for browse when it comes to maximising findability of knowledge and information. We assume "users are likely going to want to find knowledge documents through search" - but is that true?

• This study found 14% of users start with search
• This found less than 5% start with search
• This found that 59% of web visitors frequently use the internal search engine to navigate on a website and 15% would rather use the search function than the hierarchical menu. 

Some conclusions from these studies are as follows:

• Most people use the search feature after they've tried the navigation or the content links. Search is seen as the last resort.
• If people are looking for something very specific, like a product they know the name of, they're be more inclined to search.
• There are two kinds of people in the world: Searchers and Browsers. Searchers can browse when required, and Browsers can search when required. 
• Programmers and engineers use the search feature more often than 'normal people'.
• A user browses a table of contents when he or she is looking around to see what's there, usually moving with a mind open to discover new things. 
• In contrast, a user searches content when he or she needs to locate a specific piece of information.
• People very often use only search functionality on their mobiles. Complex navigation seldom works well on mobile devices and people just don’t use it. (Except on news sites, where we still browse).

So the first part of the answer is this

You have to optimise for browsers. 

From the results above, browsers are the majority. Also search has its limitation: a lack of discovery. A user relies on search to find specific information he or she already knows or suspects to exist. Rarely does a user search for something he or she doesn't even know to search for. browsers see more and buy more - often things they did not know they wanted.

I like the idea of structuring your folders like a story map, or you could use the model of the knowledge supermarket (see my post on How a Knowledge Supermarket helps the knowledge customer to find what they need). Supermarkets are predicated on findability, and one of the reasons they put the bread and the wine at the back of the store is that it forces you to see more of the store, to browse, and ultimately to buy more.

Also, try to introduce a standard folder structure, so your lawyers can move from one matter to another and still find their files stored int eh same way.

However the second part of the answer is this

You have to optimise for searchers as well.

This means getting a good tagging system and a good metadata structure. Good metadata and a good folder structure are not mutually exclusive - you need both. Some people will browse and find more that they came for; some will search, and need to find exactly what they asked for.

Like so much in KM, this is not an "either-or", this is a "both-and".

Cater for the browsers and for the searchers, and you might just please all of the people all of the time.  

Feedback loops in the Knowledge cycle

Last week I described a "Pull cycle" for knowledge - let's now look at the feedback loops in that cycle.

You can find description of the cycle here. This is a cycle based on knowledge demand (unlike the supply-side cycles you normally see) and includes the following steps;

• The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")
• The first step is to seek for that knowledge - to search online, and to ask others
• Seeking/asking is followed by finding
• However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we find more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.
• This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.
• Finally the integrated knowledge needs to be applied to the problem.

In the picture above, I have added the monitoring and feedback loops to each step, which work like this:

• After the behaviour of asking/seeking, you feedback firstly whether there was any asking/seeking (so the organisation can track the behaviours of knowledge seeking) and you monitor and feed back the topics that people are asking about or searching for. You can for example analyse questions in a community of practice, or queries to a helpdesk, and you can analyse search terms from the corporate search engine logs. These will give you some ideas of the knowledge needs in the organisation, which knowledge supply has to match. 

• After the finding step you feedback whether  you found the knowledge you needed, or not. This feedback will help identify gaps in the knowledge base where the knowledge needs are not being met, and can trigger the creation of new knowledge assets of articles.
• After the review step you feed back whether the knowledge was relevant or not. In reality this feedback will be merged with the previous step. 

• After the Integration step you feed back on the quality of the knowledge you found. This feedback will identify knowledge assets or knowledge articles which need to be updated.

• After the Apply step, you feed back whether the knowledge was actually applied. This will help identify the most applicable and useful knowledge assets and articles. 

• Finally, after the problem solution step, you feed back how much difference the knowledge made, and how much value was realised through problem solution. This allows you to track the value of the entire pull cycle and the entire knowledge management framework. 

Many of these monitoring and feedback loops are well developed in the customer-focused KM approaches such as KCS (Knowledge Centred Support), but any KM approach can apply these as part of their own KM metrics framework.

It is through the feedback associated with the steps that you can tell whether KM is actually working.

Is your knowledge base more like an underwear drawer or a supermarket?

There are three models for a knowledge base - which one is most like yours?

Your online Knowledge base is where you store your documented knowledge, It is a repository - but more than that, it is a knowledge resource for others. Someone looking for documented knowledge comes to the knowledge base to search and browse.

So what do they find?

Generally knowledge bases fall into one of three categories. Let's call them the underwear drawer, the library and the supermarket display.

The underwear drawer (see top picture), if you are anything like me, is the place you pile all your clean washing, generally with the newest washing on the top. The drawer is easy to fill - you just cram everything in - but you know that the hard work will be done when you search (often early in the morning, in the half-light) for a set of matching underwear with no holes. All the work is done when searching, and very little is done when storing. The knowledge base equivalent is the uncontrolled filing structure, where you rely on a good search engine to find what you want. Dump it all in, then search for what you need.

The library (or the organised underwear drawer, see bottom picture) is a managed and structured repository. You know the category, you know the title, and you find the book. Or you know the drawer, and the relevant section, and you find a rolled set of underwear of the right colour. The work is distributed between the seeker and the storer. You categorise when you store, and you browse to the right place when you search. The knowledge base equivalent is the organised and tagged knowledge base, where you can browse or search for the knowledge you know you need.

The supermarket goes one step further (see my post from last year on the knowledge supermarket). In my local supermarket, for example, you can find a section that displays pasta, pasta sauce, Parmesan cheese and Italian wine, all within the same attractive display. Without searching, you are presented with all the ingredients for an Italian meal. Similarly with curries - curry sauces, poppadoms, nan bread, Cobra beer, lime pickle - all in one display. Lots of work is done by the storer, so as to minimise the work for the seeker, and as a result, they pick up the Impulse Buyer - the person who was not actually looking for this material in the first place, or who had forgotten that they need lime pickle with their poppadoms. The knowledge base equivalent is the Knowledge Asset; the one-stop shop for knowledge on a topic - the wiki page or portal that gives you everything you need to know, whether you knew you needed or not.

So what's the lesson for Knowledge Management?

I believe there are three reasons why a supermarket is the best of the three models for your knowledge base.

1. Firstly the main barrier for KM is not supply, but re-use. Many companies have no difficulty in creating knowledge supply, but all companies struggle with re-use. Therefore if we are to lower the barriers, let's lower the barriers for the seeker and the re-user. Let's invest in knowledge packaging, and the creation of knowledge assets, so that there is no excuse not to re-use.
2. Secondly, although the search engine vendors will say that the search engine can do all the finding work for you, most people start by browsing rather than searching when they are shopping for something. Supermarkets are built for browsers, unorganised underwear drawers aren't. 
3. Thirdly, a search result will not return the "unknown unknowns" - the things you did not know to search for. The supermarket, on the other hand, is well designed for ensuring you find the impulse-buys which were not on your shopping list. 

Think about the knowledge user when you design your knowledge base, and don't make them or their search engine do all the work.

3 ways to make tacit knowledge as findable as Pokemon

Lots of work is done, as part of Knowledge Management programs, to increase the findability of documents. But how do you make tacit knowledge findable, given that it is as invisible to the naked eye as Pokemon?

Source publicdomainpictures.net

The ratio of tacit to explicit knowledge in an organisation is an unknown factor. People often quote "80% of the knowledge is tacit" - but nobody knows for sure. It's a large proportion for sure, and in some organisations very new to Knowledge Management it can be way more than 80%. So how do we find that tacit knowledge when we need it?  You can't see it, you don't know where it is; you just know you  need it.

We work on finding documented knowledge through several approaches:

• Making sure it is owned
• Making sure it is collected and stored in findable places (the knowledge supermarket - also see my post on "a haystack is no place to store a needle")
• Making sure it is named properly
• Making sure it is tagged and categorised.

But how do we ensure tacit knowledge, still in people's heads, is findable?  The problem with tacit knowledge is that it is invisible. Like Pokemon, we can't see it, unless we have the tools to look for it.

Here are three tools we can use. 

Firstly we can link the people to the documented knowledge. By keeping the names with the knowledge we allow the reader of the document to find the originator, and ask for more detail - to ask for the tacit knowledge which never got into the document.

Secondly we network the people into communities of practice. If you ask a question of a community of practice, it will reach the person with the answer and with the relevant tacit knowledge, even if you do not know that person.

Thirdly we introduce a knowledge-finder system. By this I do not mean a personal directory system such as Facebook, LinkedIn or SharePoint's MySite. These sort of systems are very good for finding the personal details of someone who's name you already know, but are poor for finding people with specific knowledge or skills. Even LinkedIn struggles with this, with no way to search for a combination of endorsed skills, even if you trusted the endorsement system.

No, the best analogue for a people-finder is a dating site. Dating sites are designed to make people findable, based on certain personal characteristics ("Tall, dark haired, handsome, single etc"). People-finders in organisations need to make knowledge-holders equally findable ("expert in knowledge management, experienced in KM strategy and framework development") which means using metada lists of knowledge categories. Selecting knowledge-types from preset lists is constraining in terms of data entry, but it massively enhances findability, and findability is what we are looking for here - finding the tacit knowledge that is otherwise as invisible as Pokemon.

This sort of tacit-knowledge-finder is the Knowledge Manager's equivalent of Pokemon Go, acting as an index to all the tacit knowledge which is out there, but invisible to the naked eye. 

How to structure knowledge to be findable

How do you best structure your knowledge bases? I argue you should build a structure based on findability. 

Image from wikimedia

Knowledge is not created in the same structure as it will be sought.

Knowledge is generally created as part of the work structure - as a work product within a project or a division. All too often the temptation is to structure and/or store the knowledge in the same way - by project, team or division. However people coming looking for the knowledge may not know where the knowledge was created, and instead will look based on their immediate knowledge need.

Take for example an organisation that files Lessons Learned within project files. "The lessons were created in this project" they may argue, "so the lessons should be filed in the project files". So if the Tiger project learns lessons about pitching a project to the French government, and on planning a major road bridge construction, then these lessons go into the Tiger project files.

However the person looking for lessons on pitching for French government work, or for planning a bridge project, may not know which project learned such lessons, and may never look in the Tiger project files (and certainly will not want to search through the files of every project). Instead they will be looking for some knowledge base with answers on "How to win work in France" or "How to plan construction of a road bridge".

Structure your stored knowledge based on what people will be looking for, not based on who created it. 

This is for two reasons:

• knowledge re-use is a bigger barrier than knowledge creation and any so barrier to re-use should be removed; and
• you are removing a major component of waste in the knowledge supply chain, namely unnecessary searching and filtering by the users. 

The choice of your overarching primary structure  for your knowledge - the highest level of your taxonomy, the way in which you assign stewardship of the knowledge, and the fields covered by the main communities of practice -  should be based on the types of knowledge needed by the knowledge users.

What this structure is, will depend on your organisation. You have many options.

You can structure according to activity and process, if you are a process-driven organisation or department. Knowledge is about process - how to do stuff - and is owned by process owners. Many of the oil companies, such as ConocoPhillips, use this structure, and the knowledge base is structured along process lines; processes such as planning, permitting, constructing, marketing, selling. Military "doctrine" is classified by Activity - logistics, convoy operations, road blocks etc.

You can structure around clients or industry segments, if you are a sales or services organisation. Buckman labs use this structure for their Communities of Practice, as does Aon. The structure of the knowledge base will therefore mimic the structure of the key accounts.

You can structure according to product or client offer, if you are a manufacturing, consulting or legal service organisation. We structure the knowledge in our Knoco knowledge base this way, as do the Big 5, as do oil sector service companies such as Schlumberger or Halliburton.  Chrysler structures their knowledge according to the main components of their cars, Pfizer according to their drugs, and legal firms according to the type of legal product.

You can structure according to equipment, if your role is to maintain and operate a piece of plant such as a nuclear power plant. Sellafield uses this structure for their configuration management knowledge, and a knowledge base for such a context will be structured according to the main pieces of plant and machinery.

Many organisations have multiple structures - either as multiple metadata facets, or even as separate knowledge bases. In our fictional example above, there will be one lesson (on pitching to the French) which goes into the Key Accounts knowledge base, and another (on planning for a major road bridge) which feeds the Processes knowledge base.

The key points are:

• structure your knowledge around the needs of the user, rather than following the structure within which knowledge was created;
• structure your knowledge so that people can find what they are looking for;
• structure your knowledge so that you can ensure that the key areas of knowledge are owned and maintained and connected to communities of practice; and 
• have multiple structures if there ware multiple user groupings. 

The key is to see which structure most fits your key knowledge, then ensure the knowledge base, the knowledge owners and the communities of practice are aligned with this.

How a Knowledge Supermarket helps the knowledge customer to find what they need

Your knowledge base should be less like a teenagers cupboard, and more like a supermarket.  Here's how.

Image from wikimedia commons

Following on from last week's post on findability, lets think not just how you make knowledge findable, but also how you make it browsable.

Too many knowledge bases use the "teenager's bedroom" approach )which I mentioned in this blog post) - where you dump everything into the knowledge base willy-nilly and rely on a good search engine to dig it out again. However the problem with relying on search is two-fold:

• Good search requires good indexing and SEO, and
• You need to know what you are looking for before you can search.

Sometimes the user needs to browse instead, especially if they are not sure what knowledge they need (i.e. they don't know when they don't know).

Here the supermarket is a good model. Supermarkets rely on people finding the content they need, so they can buy it. They also give a lot of though to pointing the customers towards other products, which they might not have known they needed. Every aspect of a store’s layout, from the flower display near the entrance to the chocolate by the check-out is designed to stimulate "shopping serendipity".

• Flowers, fruit and vegetables at the entrance make the store smell and look good
• Quick-use "grab and go" items such as snacks and bottled water are at the entrance, for people who want to shop quickly
• Promotional items are at the aisle-ends, so are in plain sight 
• Products are grouped by type (pasta, tins, cheese, butter) to make them easier to find
• Popular high-value items are displayed at eye-level
• Often there are themed displays - a Mexican section with sauces, tacos, tortillas, refried beans for example, or an Indian section with curry spices, sauces, poppadums and Naan bread - so you can buy all you need for a single meal
• Warm colours attract people to a store, hence the warm brick exteriors. Cool colours inside encourage more contemplation and higher sales
• Loyalty cards are used to track customer activity, and to learn more about customer behaviour. 

Can we use similar principles to encourage users to browse our knowledge bases? We could try similar approaches to colours for example, putting the high value items in the high-visibility page space, promoting new knowledge where it is most visible, grouping and associating content so that all knowledge related to a particular process or activity is grouped together (see here), placing the "grab and go" items on the front page, and using web metrics to understand the behaviour of our knowledge customers, so we can improve the design of the knowledge base.  

If we make our knowledge bases a little more like supermarkets and a little less like teenagers' bedrooms, we stand a better chance of attracting and keeping the browsing customers, and helping them to find knowledge that they didn't even know they needed.

How to make knowledge findable

How many times do people miss knowledge because they don't know it exists, or can't find it?

My guess is that this happens all the time. Someone creates a great knowledge resource, but others don't know about it, and even if they do suspect it's there and go seeking for it, they can't find it.

Hide and Seek by Emilio Labrador on Flickr

To avoid playing hide-and-seek with knowledge we, as KM professionals, need to consider four things

We need to make people aware of the sources of knowledge

Somehow we need to be able to alert people that knowledge resources exist. We need something or someone who says "there are experts in this field, and there are resources available to you. You do not need to make this up for yourself. There is knowledge out there, which you can acquire". In your organisation, you need to bring this awareness in during induction, and you need to point people to the key tools - the search engine, the community index, the yellow pages.

We need to concentrate on Findability

We need to ensure that knowledge resources are findable. As Peter Morville, the author of Ambient Findability says

Findability precedes usability
in the Alphabet and on the Web
You can't use what you can't find.

Your knowledge assets MUST be findable. They must be ambiently findable (which means that by their very nature, they pop up when you start looking). The titles of the documents, lessons etc need to give a strong indication of the knowledge within.

As knowledge managers, sometimes we spend far too much time creating usable knowledge assets, without thinking about creating findable knowledge assets (actually, we often spend too much time on capture, and ignore both usability and findability).

We need to ensure knowledge is stored in sensible places

See my blog post on "a haystack is no place to store a needle"

We need to "keep the name with the knowledge"

Very often the findable knowledge is the documented knowledge, and as we know, documented knowledge only contains a proportion of the total knowledge. You need to ensure that documented knowledge includes the name of the contributor(s) so you know who to contact if you want the tacit detail.  The documented knowledge therefore acts as the signpost to the tacit knowledge.

"People finder" systems in KM - the Online Dating model

---

A "People finder" or "Yellow Pages" is one of the key supporting tools in knowledge management, but at the moment many organisations are using the wrong model when it comes to creating or buying such systems.  

They are using Facbook as a model, rather than Match.com or Udate.

Let me explain.

Given that much of an organization's knowledge is tacit, and not written down, then you need to be able to find people with specific knowledge in order to be able to ask them questions, and to tap into what they know.  Many organisations really do not know "who knows what", and tacit knowledge often cannot be searched for.

A dedicated tool such as a people finder or yellow pages allows just this possibility.  The idea is that you should be able to  type in a query such as "who knows about marketing pet food in Southeast Asia," and receive a list of people who you can talk to for advice.

Many companies that I have spoken to realise the value of a people finder, but seem instinctively to go to analogs of Facebook in order to create the sort of functionality.   They look for software such as SharePoint MySite where people can create a personal page, which is then available and searchable by others.  Or maybe they look at LinkedIn is an analog; again somewhere where you can create a personal CV, and maybe build some groups and some discussions threads around this.

However both Facebook and Linkedin are pretty poor at finding people based on their knowledge.  They are promotional sites ; they are not sites aimed at findability, or locating people based on a set of criteria.  I tried recently to find a Knowledge Manager based in Sweden via LinkedIn, and was surprised at the poor search results.  I'm sure those people are out there, Linkedin could not find them (Later note, this now seems to work better).

However there is a whole class of Software Systems which are 100% designed for finding people against a set of criteria; and these are the online dating sites.

Why dating sites are a good model for people-finders

Everybody who has used an online dating site (and that is nearly half the adult single population, at least in the USA) knows that this is a very different experience to Facebook.  Instead of a free form text-entry input page, where you can enter things like your taste in music or favourite band, an online dating site requires you to choose your criteria from pull down menus.  Age, height, build, hair colour, eye colour, location, smoker or non smoker, preference for music types, preference for leisure activities, preferred restaurant type; all of these are chosen from a pre-set list of categories.

This taxonomic structure means you know what criteria to search for. If you are looking for someone who likes folk music, for example, then you search for "folk music" under "favourite music".  You know that your potential folk-music-loving new friend will have chosen that option, rather than saying that they like folk-blues or folk-jazz, or Fairport Convention, or Mumford and Sons.

Using these preset lists is constraining in terms of data entry, but it massively enhances findability, and findability is what online dating is all about; finding the right person

The best yellow pages or people finders I have seen have used the same online dating model.  They require you to select criteria from a whole set of preset lists, including knowledge topics, levels of expertise, office locations, job title, and so on.  Finding a knowledge manager in Sweden is as simple as selecting "knowledge management" from the list of knowledge topics, and "Sweden" from the list of countries, because you know that Swedish knowledge manager will have chosen those same criteria from those same lists.  Using these preset lists is constraining in terms of data entry, but it massively enhances findability, and findability is what a People Finder is all about; finding the person with the right knowledge.

So when you are considering an in-house People Finder system, base it on the systems that work.

Base it on the online dating sites

Don't give your knowledge stupid titles like these

---

One of my hobby-horses is that publishing knowledge is of no value, unless that knowledge can be found and re-used. It needs to be usable, and to be usable (if it is published in a database or in a website) then it needs to be findable. This includes the ability to find lessons within a database, or stories within a story folder, or relevant posts within a community blog.

One of the key enablers of findability is a Good Title. The Title is the most prominent item in any browsing system or set of search results. The purpose of the Title is to enable the reader to understand whether the item is likely to be relevant to them. Based on the Title, they decide whether to open and read the item.

So part of the role of the publisher of knowledge, in ensuring findability and reusability, is to give a knowledge item a good and relevant title - not a lazy title, or a "clever" title, or an artistic title, but a title that tells the reader what's inside.

So would you know what these lessons were about, before opening them? Would the titles help you find relevant content? Would you even bother to open them? (although I could see you might be intrigued, in some cases). Apologies to any of you who wrote any of these, by the way.

• Duplicate
• Learning 1 of 3
• Public Lessons Learned Entry: 0406
• Additional learning from (Incident X)
• Spurious event on (Project Y)
• Z Project - After Action Review (Lesson Learned)
• When you sweep the stairs, always start from the top (this one was not about stair sweeping by the way)
• From take-off to landing (and it's not about flying a plane)
• Problem

And if you want to see good practice in using titles, browse the NASA lessons database here 

When knowledge in a manual is not enough - Apollo 11 example

---

There was a very interesting documentary on Neil Armstrong on the BBC a couple of days ago, and in there was a great little story on the need for rapid knowledge when things go wrong, and the ineffectiveness of having that knowledge buried inside a thick manual. 

Here is a transcript of that section of the documentary.

BBC Narrator (talking about the Apollo 11 descent to the moon, with Neil Armstrong and Buzz Aldrin in the Lunar Module)

Almost as soon as they started the descent, things started to go wrong 

 Charlie Duke, NASA CapCom (talking head, present day) 

As they went around the moon, looking at their trajectory, the bottom fell out. we started having communication problems, and data drop-out ...... 

Narrator 

Then as they descended towards the surface, the main computer began to raise a series of alarms 

Historical footage, voice of Neil Armstrong 

Program alarm! 

 Charlie Duke, CapCom (talking head, present day) 

And then we started getting computer overload alarms. That really shocked me, as it could potentially be a showstopper on the mission. 

 Historical footage, voice of Neil Armstrong 

Give us a reading on the 1202 program alarm! 

 Buzz Aldrin, Apollo 11 astronaut (talking head, present day) 

Neither of us knew what 1202 meant. We knew where we could find the answer - but it was in a document about that thick (indicating with his fingers a book the size of a phone directory) and you had to leaf through it - and here we are halfway down to landing on the moon!!  

But luckily we had a bunch of guys back there on Earth - they could look it up! 

 Narrator 

The team back at mission control found an answer in 23 seconds. 

 Historical footage, voice of backroom staff 

We are go on that, flight 

 Historical footage, voice of Gene Krantz (flight director) 

We are go on that alarm? 

 Historical footage, voice of Charlie Duke, CapCom 

 Roger, we are go on that alarm.  

Eagle, you are Go for landing, over.

A small moment in the history of Apollo 11, but a giant lesson for Knowledge Management. There's no point in providing Knowledge to people in a format which means that when they need it, they can't find it in time. However you transfer knowledge, findability is a key issue (see my 2010 blog post "you won't use it if you can't find it"). And if findability is not easy, give people someone to call who knows where the knowledge is.

How do you structure your knowledge?

---

Sooner or later you are going to have to think how you structure your knowledge in your organisation.

This is for two reasons - for findability, and for ownership.

You structure your knowledge so that people can find what they need in a single place, and you structure your knowledge so that you can ensure that the key areas of knowledge are owned and maintained and connected to communities of practice.  Yes, you can also have ontologies, taxonomies, folksonomy, etc etc - you can index and tag your knowledge in many ways - and structure is valuable also; if for no other reason than to give people access to the things they never thought to search for.

The choice of your overarching primary structure - the highest level of your taxonomy, and the way in which you divide ownership -  depends on your organisation, and you have many options.

You can structure according to process, if you are a process-driven organisation or department. Knowledge is about process - how to do stuff - and is owned by process owners. Many of the oil companies, such as ConocoPhillips, use this structure.

You can structure according to equipment, if your role is to maintain and operate a piece of plant such as a nuclear power plant. Sellafield uses this structure for their configuration management knowledge.

You can structure around clients, or industry segments, if you are a sales organisation. Buckman labs use this structure for their Communities of Practice, as does Aon.

You can structure according to product or client offer, if you are a consulting or service organisation. we structure the knowledge in our Knoco knowledge base this way, as do the Big 5, as do oil sector service companies such as Schlumberger or Halliburton.

The key is to see which structure most fits your key knowledge, then ensure the knowledge base, the knowledge owners and the communities of practice are aligned with this.

You wont use it if you can't find it - findability in KM

---

But I just can't find it anywhere.
Originally uploaded by tpholland

About a year ago, I took over the role of treasurer for my little local church. This is a tiny church, dating back to the 1100s, but still active and still requiring funding, so when the current treasurer moved away, someone had to take over. He gave me a good handover, but this is a new job for me and I have had a number of headaches already, where i have been scratching my head wondering how to do some arcane component of the role.

This week, I have been working with the diocesan offices, helping them with plans to set up some Communities of Practice, and we were discussing the role of the treasurer. My contact mentioned that there is a Treasurer's handbook on the diocesan website.

Well, this was news to me. I wish I had known about this before - it could have been very useful. I went to the website, browsed around, searched under "Treasurer", and still couldn't find the handbook (I have since been told where it is, and it's a gold-mine of information).

I wonder how often this happens? Someone creates a great knowledge resource, but others don't know about it, and even if they do suspect it's there, they can't find it.

That's where we, as KM professionals, need to consider two things


* KNOWLEDGE AWARENESS

Somehow we need to be able to alert people that knowledge resources exist. We need something or someone who says "there are experts in this field, and there are resources available to you. You do not need to make this up for yourself. There is knowledge out there, which you can acquire". In your organisation, you need to bring this awareness in during induction, and you need to point people to the key tools - the search engine, the community index, the yellow pages. I wish someone had done this for me when I inducted as a treasurer.

* FINDABILITY

We need to ensure that knowledge resources are findable. As Peter Morville, the author of Ambient Findability says

Findability precedes usability
in the Alphabet and on the Web
You can't use what you can't find.

Your knowledge assets MUST be findable. They must be ambiently findable (which means that by their very nature, they pop up when you start looking). As knowledge managers, sometimes we spend far too much time creating usable knowledge assets, without thinking about creating findable knowledge assets (actually, we often spend too much time on capture, and ignore both usability and findability). I wish the Diocese had made their resources more findable.

In conclusion, I would like to add to Peter Morville's three-line poem.

Awareness preceds findability which precedes usability
in the Alphabet and on the Web.
You can't use what you can't find,
and you won't find what you don't look for.