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.