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.
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.
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.
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.
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.
Julie L. Mohr says
David, good content and a very relevant conversation. I love Leslie’s comments around bite, snack, and meal. I would add that part of the problem with content management is with the hierarchical structure in which knowledge is stored. Our brains all fundamentally work and store knowledge differently. When we store a document on a server in someone else’s logical structure we often struggle with where to store it. Thus retrieval is ultimately just as difficult. The search capabilities of the tool that enables KCS is incredibly important to success with transactional knowledge. I believe that it is equally important here. Keywords and metadata are important (hence why the snack is important) but so is the hierarchical structure that is developed. This is often in the context of IT not in the context of that all users of content will understand. If you can apply an awesome search engine (like Google does across documents and webpages) across the content then it will help bridge the gap of the findability of content. But documents are subject to duplication and being out of date simply because we can’t find them. This too needs to be fixed.
David Kay says
I think it’s a very useful observation that we should move from browse-centric model to a search-centric one. Thanks for calling that out. This is another reason to move from a documents to content, too: wiki pages are much easier for search engines to deal with than the average document.
Of course, since taxonomic schemes will always be with us, it’s important to get them right: https://www.dbkay.com/knowledge-representation/what-makes-a-good-taxonomy
Christie Morin says
You hit the nail on the head David! Thanks for sharing; great article and these are always topics of discussion contended!
Rod Weir says
Bookmarked! Great post David. Templates are the way to go with structuring content for sure, as well as giving the author a great head-start to the usefulness of the piece.
Aaron Fulkerson says
This is a great post. Thanks. The best practice of unifying and “blending” content types from multiple disciplines (Training, Support, Product) is something we promote too as part of a self-service maturity model. Of course, KCS customer support is a recommended stage of this model. 🙂 By the way, we’re big fans of the expanded focus of KCS (beyond support). Loving it.
Jason Lazarski says
Great article. Thanks, David. We’re promoting it at MindTouch. 🙂 Read more here: https://mindtouch.com/resources/critical-early-stage-self-service-maturity-blending-content-types