KCS Principles Can Fix Content Management

We’re covering a big topic, so this is a longer post than usual.  TL;DR: Apply KCS principles to Content Management, too.

We’ve written before about the differences between KM and CM (see Knowledge Management vs. Content Management).  Briefly, KM focuses on short structured articles that are about one thing, while CM focuses on longer-form content and documents.  Traditionally, the KCS Practices Guide says CM is out of scope for KCS—as shown in The Content Continuum.  But our experience is that many KCS principles apply to content, too.

This matters. Most enterprises are unhappy with their content repositories, and, by extension, with their content management practices.  We recently interviewed one team member who described his enterprise’s SharePoint as a “big ol’ pit into which people throw documents,” and another who opined that she would “rather slit her wrists than search in SharePoint.”  Would we hear the same thing at your company? SharePoint and other CM systems get a bad rap, but it’s not really the technology—it’s how people use it.  That’s where KCS concepts really help.

Decentralization

When we meet with people frustrated with CM, they often wish there were a person who could just do it all—someone to whom they could send documents or notes or an email, and have them somehow fix it up and file it properly in the CM system.

We call this the “myth of the magic librarian.”  It’s appealing, but it doesn’t work in the real world.  If you think of the knowledge and experience across the organization, it’s simply not possible that a person, or a small team, can somehow know enough to document everything.  And, unless the organization is willing to fund a small army of these magic librarians, they simply won’t have enough bandwidth—they’ll become a bottleneck.

This, of course, is how KCS is different from traditional KM practices.  Rather than centralizing KM into a small team, we distribute knowledge work across a whole organization of knowledgeable people.  Effective CM also requires decentralization.

Demand Driven

Content should be developed because someone needs it, not because we’ve always generated a particular document in the past.  There has to be an identified need (similar to KCS Evolve Loop content.)

For example, if I’m a Benefits professional, I know that people will need to know about health care plans as Open Enrollment approaches.  And if I’m revising a returns policy, I know that my customer service staff will need to know what the new policy is.  In both those cases, I know there’s demand for content, and I’ll write it.

On the other hand, consider a technical team that performs an analysis of alternative architectures and selects one.  Is it worth documenting the reasons why others were rejected?  Unless your company has a lot of second-guessing and finger pointing, probably not.  Focus on the selected option and pass on documenting the rejected ones until someone explains why they really need it written down.

Context is as Important as Content

One of the chief complaints we hear about content is that it’s not written in the language of the intended audience.  An HR specialist explaining corporate benefits to an employee probably needs to read about “taking family leave to take care of a friend’s child,” not an “in loco parentis FMLA qualifying event.”

Specialized language is a badge of subject matter expertise, and with ‘the curse of knowledge’ expert writers might not even know that their audience won’t understand what they’re writing.  Experts need humility, empathy, and feedback to write plainly and clearly.  But even the most insightful and correct document is useless if it can’t be easily digested by the people who need it.

Reuse Tracking

In prior versions of KCS, the Practices Guide specified that knowledge reuse was tracked by linking from an incident to a knowledge base article.  Version 6 makes that idea more generic, saying that there can be a link from any “system of record,” or that a reuse count can be maintained on an article without the need for a link.  Reuse data is critical to KCS, becase it drives knowledge worker performance assessment and knowledge domain analysis.

This same approach works for content as well.  It’s a small thing to ask of people who use a document to click a button somewhere saying they used it, but the insights it drives can be priceless.

Collective Ownership:  Every Use is a Review

The other gripe we hear about content is that much of it is out of date.  This probably sounds familiar to many knowledge managers, too. That’s why “every use is a review” is such an important part of the KCS Solve Loop.

In CM, users of content often see themselves as passive consumers—either they like a document, or they shrug and move on.  KCS says moving on isn’t an option. If an article is outdated or otherwise doesn’t meet the need it purports to, the reader should flag it (or fix it, if they’re licensed to.)  Content Domain Experts should track and act on flags, making sure that content is kept current or archived.

Structure Matters

One challenge of many content management systems is that content is stored in the form of documents:  Word files, PowerPoints, PDFs, and the like.  Because these documents are free-form, and because it’s hard to write truly descriptive file names, documents are hard to find and hard to use.

While content isn’t ever going to be as concise and structured as knowledge base articles, we can move in that direction:

• Less is more! Boilerplate, lengthy introductions, and dense paragraph after paragraph of text form a ‘wall of words’ that intimidates readers.  Strip content to its essence.  Use bullet points and lists where appropriate.
• Templates.  Most documents should be based on established templates.  Someone authoring meeting minutes, a requirements document, a policy, a workflow, or a manuals shouldn’t start with a blank document.  Templates drive consistency and readability, and make it easier to author new content.
• A content standard. KCS programs maintain a succinct document that defines what good content is: how to use the templates, what brand names to say or not say, and how to set metadata properly.  Content management programs should do the same.
• Pages, not documents. Many content management systems have the ability to store simple Wiki-style web pages in addition to content.  Wiki pages are easier to find, skim, and consume than documents, and we recommend them whenever specialized multimedia content isn’t absolutely necessary.
• Bite, Snack, Meal. Our colleague Leslie O’Flahavan recommends that authors structure content as a “bite” (descriptive title), a “snack” (a summary), and a “meal” (the full document.)  This is in contrast to the standard model of having a document simply titled pdf, which is a lot more like “mystery meat.”

Coaching and Proficiency-Based Licensing

A key tenet of KCS is that you need to earn the right to contribute and maintain content by demonstrating that you know what you’re doing.  Peer coaches help develop these skills, and assist managers in identifying who is ready to become a licensed contributor or publisher.

Isn’t it strange that there’s so much concern about broad-based contribution to knowledge bases, but uncontrolled access to content management systems is the norm?  In most environments, anyone can upload or modify documents.  We recommend implementing the same coaching and licensing model for content management programs to give people the skills and confidence they need to be successful.  And, “trust but verify:” as with KCS’s Article Quality Sampling, spot check licensed contributors to make sure that they’re following the content standard, and give them further coaching if they’re not.

Content Domain Experts (CDEs) and Content Domain Analysis

Much of the content in a CM system is built as people do their jobs.  Meeting facilitators take notes, product managers document user stories, and marketing people write solutions briefs.  But, as with KCS Evolve Loop content, sometimes it makes sense to invest in value-added content, including multimedia content, in specific areas.

Content management programs should identify subject matter experts—let’s call them Content Domain Experts, inspired by KCS’s Knowledge Domain Experts—and give them time to do value-added content work.  They can analyze the use of content in the system, create high value content, and provide feedback to the rest of the organization for continuous improvement.

Leadership is Required

The final KCS lesson for CM programs is that good things don’t just happen by accident.  Time and time again, we’ve seen that KCS programs founder without strong executive sponsorship and capable program management.  Why should content management be any different?  Organizations that deploy Confluence or Drupal or SharePoint and then walk away from the program won’t reap the rewards.  In all but the smallest organizations, there needs to be someone who walks in the door thinking about CM, leaves at the end of the day thinking about CM, and works on CM during all the hours in between.