Knowledge Management Principles - jmadison222/knowledge GitHub Wiki

In a knowledge economy, applying knowledge is the work. But often, the delivery of the core knowledge event is what it means to be done with the task. For example, if an accountant gets the financials in monthly, it’s "done". But if that accountant leaves the company and now one knows how to do the filings, you’re in trouble. The process around doing the filings is also part of the job. The higher-level knowledge is the core of knowledge management work. Don’t let any knowledge work be "done" unless that process knowledge is captured.

Within any given knowledge artifact, there are also lower-level details that are critical but can get lost. Again with the accounting example, what are the formulas that generated those numbers? Don’t let knowledge work be "done" unless that lower-level knowledge is also captured. This higher-level and lower-level knowledge is 80% of the knowledge you’re missing without a serious knowledge management process. Only 20% of knowledge is embedded in the core knowledge artifacts.

The capturing of that higher-level and lower-level knowledge is not trivial. It will take some serious work, and needs to be called out as a deliverable. Don’t ask people to bury the work in their day job without making time in their day job.

Under review.

Who will be using this environment, and what does success look like for them? This will often define who you assign to the effort and how you pitch the value to the consuming areas when you’re done. This will also feed directly into the persona conversation later. This customer work is directional, where the personas will be much more specific. The thing you will deliver them, in the loosest sense, is knowledge. But what will they do with that knowledge? And then one step beyond that, how does that action make them more successful in their work? That is where you’ll be deriving value from all this work, so you need it as an anchor point early on.

What is a "widget" - For the remainder of this discussion, we’re going to use the term "widget" to mean the thing that your KM environment is about. You don’t build a KM environment as an end it itself. You build it because it addresses some topic. You build an accounting KM environment to do accounting—​accounting is your widget. You build a technology KM environment to build technology platforms—​technology is your widget. The thing your customer needs in the rest of the discussion is that "widget", where for your environment, it’s whatever business you understand them to be in.

When your knowledge platform is new and exciting, you’ll show the whole thing off and everyone will have an ocean to explore. Once consumers become stable and know the content, they won’t want to wade through an ocean to see what changed. Provide a mechanism to summarized what changed on some recurring basis such as monthly or quarterly. It doesn’t have to be fancy. Just links to the new or changed thing and a brief description.

Under review.

Most sites tend to accumulate obsolete or forever-draft content. Get rid of this early and often. Don’t wait for "some day", which will never come. Do such things as requiring the elimination of junk as part of routine publication or review processes. If something has been draft forever, ask if it should be eliminated. Rather than having junk scattered everywhere, put all the junk on one or a few pages specifically designed to manage junk and don’t make it easily discover through the main user experience. In general, just have an attitude of intolerance for the small flaws that are often ignored and get rid of them sooner rather than later.

In any significant knowledge repository, there will be a Pareto distribution of value among the topics. Mark the important topics so that people know what they are. Or create some kind of hub that connects to the most important pages. If you don’t have some mechanism of indicating the more or less important topics, the more important ones will get lost among the less important ones. The front page is a special kind of hub, so use it to put the most important topics in front of the user. If you’re buying a platform, look for a mechanism to allow voting as that meets the recommendation function.

Under review.

Under review.

Under review.

Under review. If nothing else, these are the three most common personas, so start here:

• User - The person who uses the widgets defined by the KM environment.

• Builder - The person who builds the widgets used by the user.

• Operator - The person who takes over the widgets once the builder builds them, then keeps them working.

You will pretty much always want the first one. The second one is common. The third one only happens when your widgets are big enough to be built and operated by different people or groups.

Under review.

Under review.

Under review.

Under review.

Under review.

Under review.

Whether within a site, a page, a paragraph—​sometimes even a sentence, put the most important part first, then the second, third, and so on, with the least important things last. This is the opposite of how most people write, where they build up the details before reaching the climax of the story. People write this way because life tends to unfold this way—​lots of little details that finally culminate in a big event. When managing knowledge, this is not efficient. Tell the reader the point first, then unfold the details in case they’re interested. This allows the reader to stop when they no longer care about the details. Balance this rule with the one about story telling—​since sometimes stories are better; but most of the time, write in pyramid style.

Writing in the context of KM is not the same as writing a novel. It’s not even like writing a technical book. Most KM work is for the purpose of making people productive in some context, typically a business environment. Your reader is trying to get something done and is short on time. They generally appreciate just being told what to do, so tell them. If you’re chosen to author KM content, it’s because you’re a trusted expert. As the expert, get bossy. Tell people what to do. They will appreciate it. The next two points are specific ways to do this.

Under review.

Under review.

Under review.

This is my favorite! It’s the measure of success. If you’ve managed all your knowledge correctly, people should be able to leave you alone, including for days when you’re away. Knowledge management is, of course, good for the organization, and the value to the organization is why you’re paid to do it. But also, all the knowledge experts, having codified their knowledge in the platform, are now much less of a key person dependency and can go away without the organization hitting bumps without them.

Consider the table of contents on this very page. Consider the wording of the section headings that are in the table of contents. By reading the table of contents, the reader, can, of course, get a good feel for what’s on this page. But that’s what any table of contents should do. Beyond that, each entry in the table is about six to 10 words that make the best possible attempt at actually summarizing the topic of each section. When done this way, the table of contents becomes a summary of the widget being discussed on the page, not just the page itself. Work to make each table of contents capture the most critical 10% or so of the entire topic so that even if the reader read only the table of contents, they would have a solid understanding of the topic at hand.

The table of contents is a page level notion, but the concept extends to other hierarchical summary opportunities. Things such as index pages or hub pages lend themselves to this pattern. Don’t just make your page-level tables of contents have this summarizing power, but do it with any construct that is well positioned to summarize the things to which it refers.

Under review.

Under review.

The old expression is, "A picture is worth a thousand words." Actually, both are useful, and because they each serve a different purpose, both should be used. A picture generally facilitates conceptual understanding. Lots of well-written words facilitates precision, execution, and repeatability. You need both. Start with pictures to capture the essence and build understanding, and to satisfy those who only need that and really don’t need to read your text. Then build out the idea in detail with the text.

Links are a great way to connect information, but they can be overdone. Resist the urge to put links everywhere. Link in strategic locations, generally more toward the top of any given page. Link to things that are generally expected to be stable. Where a specific item is within a larger page, consider naming the location and linking to the higher level. For example if "How to Polish a Widget" is on the "Widget" page, rather than link to the nested area, just link to the "Widget" page and tell the reader to find the "How to Polish a Widget" section. When a knowledge environment is young, users will find this a bit more work, and it is, but it is more stable over time. Even if you change the title of the topic to "How to Make a Widget Shiny", a reasonable reader can figure it out. But a broken link is just broken.

Under review.

Under review.