Zooming in to knowledge

You know how quickly you can zoom into your house on Google Earth? Can you zoom into your organisational knowledge just as easily?

You can browse to your house very quickly on Google Earth.

• First you find your country, 
• then your city, 
• then your suburb or village
• then your street
• then your house. 

Sure, you can get there very quickly indeed if you know the postcode, but if you don't know the code, you can still find your house by zooming in.

Can you find your way to knowledge just as quickly within your own knowledge base? If you don't know the exact title of what you are looking for, can you zoom in and find it?

The "zooming in on Google Earth" analogy comes from an excellent blog post by Tomas Björkholm entitled Lean Documentation.  Tomas recommends six practices for really good, helpful knowledge transfer through documentation (in his case, documentation of IT systems);

• Practice 1 – Identify your consumers and their reasons for using the documentation (what we call "writing for the unknown user")
• Practice 2 – Structure it like Google Earth - with each level linking to the next
• Practice 3 – Keep it small
• Practice 4 - Make the text inviting to read
• Practice 5 – Incorporate visuals
• Practice 6 - Make it easy to maintain

The first practice is about identifying the user(s) for the knowledge, and Tomas suggests that there may be multiple users, each requiring different levels of detail. This is true, but even if there is only one user (i.e. the knowledge worker who needs the knowledge to make decisions), they still may need that knowledge at different levels of detail as they work through the topic:

• The high level knowledge to give them a heads-up as an introduction to a topic 
• The medium level knowledge that maps out the things they need to address
• The detailed work guidance, which they will refer to as they progress with the activity
• Access to original documents, templates and/or people who can offer further advice, if the guidance turns out to have gaps in it.

Package knowledge in layers

This means you have to package knowledge in layers. Giving people too much detail - too much granularity - in the early stages is counterproductive. It will just overwhelm them.  Giving them too little detail when they are deep in the work and need detailed answers is just plain unhelpful. They need the right level of detail at the right time. They need to be able to zoom in; just like on Google Earth.

As an example, we recently created a "knowledge asset" (packaged set of guidance on a particular topic) for an organisation, covering the topic of "partnering along the supply chain". We created this with the following layers:

• A high level quick-start guide
• "Top lessons" for each of 14 sub topics
• A full FAQ for each of the subtopics
• Links to a library of supporting documents and to people with relevant experience

These layers allow the next partnering manager, whoever he or she might be, to be able to rapidly zoom in on the answers to the questions she doesn't yet know to ask, at the time the answers are most needed.

This packaging takes time, it takes thought, but it is an investment in lean and structured knowledge. As Tomas says in his article - 

People use documentation to find answers to the questions they have. The quality of the documentation can be measured by the time it takes to find the answers.

Make sure people can zoom in on the knowledge they need very quickly.

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.

The importance of maximising knowledge findability

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

Image from wikimedia commons
attribution Dg-505, CC licence

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.

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 existence of knowledge resources

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 ensure 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.

Don't make people play hide and seek with knowledge. Ensure findability. 

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.

Maximising findability in a People-Finder system - the online dating model

In another reprised post from the archives, we look at People Finder systems, and suggest they should follow the model of dating sites rather than Facebook

Image from wikimedia commons

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, which would provide much better findability.

Let me explain why.

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, other than searching for reports and hoping to talk to the author.

A dedicated tool such as a people finder or yellow pages allows just this possibility of searching for people based on "what they know".  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 as 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.  Facebook allows you to communicate with people who are already your friends, but is not set up to allow you to find people you don't already know. I tried recently to search LinkedIn for people with KM skills in Sweden, and was surprised that this was not possible.  I'm sure those people are out there, but Linkedin could not find them (unless you have an expensive Recruiter account).

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, what you had for dinner or your 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 you can 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.

Effective systems for finding people with tacit knowledge need a similar knowledge-based taxonomic structure.  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 building or buying an in-house People Finder system, base it on the systems that work.  Base it on maximum findability.

Base it on the online dating sites

Why good Titles are important in KM

If you want knowledge in a lesson, post or knowledge article to be found, give it a good title.

One of the occasional recurring themes of this blog is the importance of Knowledge findability. Knowledge needs to be used in order to add value, and before it can be used it needs to be found. This includes the ability to find knowledge in lessons within a database, stories within a story folder, relevant posts within a community blog, or experience within the head of an expert.

One of the key enablers of findability when it comes to documented stories, lessons and knowledge articles 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. If the title makes no sense, then the seeker may not even realise they have found the knowledge, and may pass over it unknowingly.

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.

Bad titles

Would you know what the lessons listed 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

Good titles.

If you want to see good practice in using titles, browse the NASA lessons database where you can find titles like these:

• Construction Site Safety, Sheet Metal Panels Materials Handling
• Design Considerations For Lightning Strike Survivability
• Thermographic Mapping of PC Boards
• SpaceWire Cable Fabrication and Installation
• Orbiter Protection System "Y" Curtain Wall Retraction
• Portable Hypergol Checkout Panels.

These titles clearly tell you what the lesson is about, and the reader instantly knows whether the lesson is relevant to their context. In almost every case the lesson is related to a process - handling of panels, mapping PC boards, fabrication of cable - or to a component such as Hypergol checkout panels. Someone planning a similar process, or designing a similar component, can find the lesson based in the title.

If you want knowledge to be found and used - pay attention to the title!

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

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.