Capturing Knowledge and Making It Findable

Previously, I wrote about the critical importance of capturing knowledge, and capturing it effectively. Let us assume that the organization has bought off on the idea that capturing this information is worth doing – and that they are doing it well. Let us also assume that our content is stashed on a reasonably capable intranet platform, and we have a reasonably capable enterprise search engine (such as Google or MS Enterprise Search) happily and effectively indexing all that captured knowledge.

Are we there yet? Almost – as long as the stuff we have out there is actually “findable” in the proper context.

When someone is searching for answers, they need to find the Best Document for the Job. Alternatively – when folks are looking for “the report that shows Daily Sales with Projected Month-End Totals,” I really want them to find this report (labeled Daily Sales Projected) and not that report (labeled Monthly Projected Sales). Terse titles that fit nicely on the page header don’t provide much guidance.

Why the concern for “findable” documents? Well – have you looked at a result set from a typical internal document repository? It’s never as nice as the demo …

Google as a Design Pattern

Over the years, I’ve seen CMS platforms, document management systems, and well-intentioned database architects see documents as objects that need attributes to be indexed. MS Word has been doing it for years – in Office 2007, click the Office Button and go to Prepare, Properties. See the Keywords and Category properties? Remnants from an era where (I think) database designers felt the quickest way to find a document was to text scan a finite list of words in a given column – something like

SELECT * WHERE LOWER(Keywords) LIKE %daily sales%)

Scale this up over a large number of documents and a scattered set of authors, and we encountered Problems. We also got proposed Solutions like Taxonomies, Document Approvals and all sorts of bureaucracy.

Then came new ideas like full text search & AltaVista, followed by page-rank & Google. On the public Internet, we are able to instantly access the right document in seconds, often by entering rather obtuse search terms.

True, there is indexing science and a bit of crowd-sourced brilliance in the search results, but also consider SEO – Search Engine Optimization, or documents (web pages) that work very hard to be found. This is text-based Darwinism, the Invisible Hand of the knowledge market – and it’s a bit of natural competitiveness that can be brought into the corporate intranet to drive knowledge capture and sharing to greater levels.

First things first – let’s approach the problem from the “consumers” viewpoint …

Findability as a Requirement

Google has set the expectations of all computer users; my search should return results in an instant, showing the best answers on the first or second page. I don’t have to understand how the Internet [knowledge base] is structured, or candidate material [similar reports or documents] is organized – I expect that the best answer can be found using Google, and need only learn how to enter a variety of simple search phrases to suss out the best content.

How can your team learn from Google’s example? First, we need to define guidelines for all project deliverables – guidelines that will make them search-engine friendly.

• Word-processor documents are wordy by nature, and will do fine in search engines as long as they are written reasonably well. Authors should not try to impress with witty turns of phrase – unless they provide a simple, succinct Executive Summary that uses language common to your organization
• Slide decks (PowerPoint etc.) have words, and are often overly wordy, but often are not built with well constructed sentences. Consider adding a decent amount of explanatory text in the Speaker Notes.
• Diagrams and spreadsheets, images and drawings may contain some searchable text, but this is typically terse and not always helpful. An excellent strategy would be to create a short, explanatory document for each file (README.TXT, anyone?) – or a single document that describes the various non-text project deliverables in reasonable detail. Enough description to help these documents turn up in a search query.
• Static reports, queries and “cubes”, and custom code should also be findable – often, this is exactly the stuff folks are looking for (How do I report daily sales by product category …). Of course, search engines typically don’t index source code – so treat these objects like spreadsheets, creating short, descriptive, search-engine-friendly summary documents that identify these useful reports, and tell folks how to navigate to them, via menu options, transaction codes, required security access, and how-to instructions.

A forward-thinking project manager will add “findable documentation” to the list of final deliverables, along with the design specifications, training material, and testing documentation. But how to encourage effective findability – especially when techs don’t like to document stuff? Back to Google for some guidance …

Re-Use as a Success Measure

Google has defined ground rules for content providers; the basic mechanisms of full-text search and page rank rules are used to make our content rise to the top (the science of SEO). However, note the engine that drives the competition for top spot on the Google results … I get paid.

Why does Google work? Content creators want to be found, people get rewarded when they get found. So much so, there is an industry and an ever-changing set of best practices built around Search Engine Optimization – driving my content above the din and getting the attention of those all-important eyeballs.

We can take advantage of this phenomenon in a traditional organization to drive our innovation goals. Consider a reward system for people, like royalties or click-through impressions, when their knowledge gets re-used. Granted, this is counterintuitive for most organizations; on the Internet, your reward comes when people use your program / read your page. You get no reward for creating the page, only when people use the tool, download the app, consume the content. In corporate America, it is reversed – people get rewarded when the process documentation is complete, success is achieved when the project is done. People may develop skills in making documents and presentations look good, but there is no market pressure or feedback mechanism to make this communication / knowledge transfer more effective.

This might take some creativity – publish traffic reports and download counts on the intranet for some immediate positive feedback. Consider putting targets for content created and content re-used for your teams annual performance objectives. Remember, recognition is often more important than monetary rewards – but those don’t hurt either!

Timeless wisdom from 2010, updated with fresh insights.