Taxonomy for Dogs and Children

Lessons Learned

I'm about to embark on my third internal content management system (CMS) since 2001. Content management has come a long way since then, when our VP of Engineering hired a consultant to deploy the free SharePoint Team Services 1.0 as part of Windows XP, and hoped the group would use it. Within a month, the single document library looked like the front hall table where an entire dormitory had dumped their mail. That's how I became a SharePoint admin. Four years later, a systems integrator recruited me for my SharePoint experience as a full-time Process Manager for a large state project administered entirely (that was the goal) through SharePoint--again, free and out of the box. This time round, my current company will be using an open-source alternative, Confluence, and I'll be one of several Subject Matter Experts (SMEs) on the deployment team.

Most deployments start with a tool, and the technical questions about what the tool does and how to make it do what you need it to do. As SharePoint has emerged as a tool worthy of an acronym (MOSS, which is nicer to say than WSS), discussions seem to center on how to deploy, customize, enhance, extend, add-on, and otherwise engineer SharePoint as a software solution.

My own lessons learned focus less on these techie questions, which are satisfying because they have clean answers (even if they're not the answers you want). Our deployments were never intended to be customized, and the desired investment was zero money and near-zero IT time. Even when a third-party solution would have solved a business problem, as the BA admin I had no access to the SharePoint server itself, which was administered by our IT group in each case. When you're working with an "out-of-the-box" solution, you don't get to think out of the box. I got quite good at devising creative solutions "inside the box" that leveraged SharePoint to satisfy exceptionally demanding business users without touching the server or writing a single line of code. That, as they say, is another story.

The most important lesson I learned, and that I teach, is that building a library involves more than shelves and bookbinders. You need authors, readers, and--promises of search engines and collaboration systems to the contrary--you DO still need librarians. The part I play with would-be CMS engineers is to repeat, early and often: "Computers do not create content. People create content. Producers used to be called writers. Consumers used to be called readers. Librarians help writers and readers find each other." And, when faced with the intense and well-meaning frustration of a content producer at needing to get the words right: "Yes. If we all lived in your head, we'd be better off. But other people need to understand it too."

So, in recalling seven years on the front lines, here are some lessons learned. Each has a story behind it, and some vivid and/or bitter experience: but writing for the web needs to be concise and crisp. So, here you go.

About Users

• Content Management Systems (CMS) and Knowledge Management (KM) are projects undertaken only when it hurts. The people it hurts the most are not necessarily the ones who will get the most use out of a well-designed CMS.
• Do not forget to communicate to the end users of the CMS what problems the new system is designed to solve. If you are really proactive, you will ask them what problems they would like it to solve. These will be different than the pain points identified by those who started the project in the first place.
  
• No one likes to make someone else's job easier at the expense of more work on their part.
• Don't bother fixing what isn't broken. If your users are sharing content in a way that works for them, leverage and improve on that before telling them why they could be doing better.
• Managers may want users to collaborate far more than users want to collaborate, or vice versa. These expectations are implicit requirements in a CMS, and may surface only when rollout does not meet expectations.
• Collaboration and content ownership are both important, not the same, and can be, but are not necessarily, in conflict.
• Content producers have obligations as content owners that may create limits and disincentives to true "collaboration."
• Producers do not like to share content that "isn't finished." The CMS needs to provide tools that the producer will accept as alternatives to keeping drafts and notes on their personal hard drive.
• Content producers are The Few power users and vocal stakeholders, while content consumers are The Many who often do not even consider themselves stakeholders.
  
• The Few will insist on creating the CMS to serve their needs, which are usually far more complex and can be confusing to consumers.
  
• Turning consumers into producers creates a higher signal-to-noise ratio that often backfires and creates resistance to the CMS.
• "Collaboration" can and will expose differences of opinion, factual inconsistencies, power struggles, and unmade decisions. Consumers do not want to know all this. They want authoritative information--even when they disagree with it and then want to "collaborate" to change it.
  
• Managers and team leads are generally more interested in sending than receiving.
• The same person will behave differently as a consumer than as a producer.
• Producers want consumers to pull, while consumers want producers to push.
  
• Lots of producers will create overlapping, inconsistent, outdated content that needs a SME/KM to ratify. This person was once known as a writer.
  
• Consumers want to know what The Answer is, Now. They don't want to do research and analysis, they'd rather ask a person (their de facto KM).
• As long as it's faster to ask a person, consumers won't go to the CMS. Producers must leverage the CMS to provide answers.
• Most content producers actively enjoy the sense of urgency and importance that comes from answering questions and knowing the answers. Promoting self-service knowledge transfer takes away that sense of personal fulfilment and is a disincentive for producers, even when they are overwhelmed with questions and acting as a bandwidth bottleneck.
• As long as it's faster and more accurate to send an email or an IM than to do a search, users will ask questions before searching for answers.
• Especially in software environments, many users have much stronger facility with spoken than with written English. This makes tacit verbal knowledge transfer (asking questions face to face) more attractive than explicit formal knowledge transfer (go look it up).
• CMS is best for asynchronous communication and will never replace synchronous communication. Users will always need face-to-face, phone, email, and IM.
  
• Users in search of answers often do not know how to frame the question. They may not know how to recognize the answer when they find it, especially if it's not the answer they are expecting.
• Users like to browse. Users like to search. Some users are Browsers or Searchers by nature, but eventually all users will want and need both. Don't make them choose by designing your CMS to prefer one or the other. If you have a dedicated Browser or Searcher dominating your requirements team (especially if that person is a senior manager or tech lead), try to enlist users of different approaches and experience levels to balance the team.
• Once you have invested all that time in producing written content, be gentle but firm with consumers who are overwhelmed at "I have to read all this?!" Be even firmer with producers who don't want to keep it up to date "because no one wants to read all this." They will usually short-circuit the CMS to share more current knowledge one-on-one. This will make your CMS fall even further into disrepair. Librarians must encourage, cajole, demonstrate, help, and insist that writers write, and that readers read.
  

About the KM Role

• No one will call you a knowledge manager. You won't know you are one. How do you tell? Here's a useful metric: you are answering questions more often than you ask them.
  
• It's a personal discipline to go to the CMS instead of answering from your own knowledge. Shooting from the hip reinforces tacit knowledge transfer and guarantees distrust in the CMS.
• If your own knowledge is out of date and you discover this through a question, UPDATE THE CMS AT ONCE so the explicit knowledge is accurate.
  
• Think of the CMS as your reuse repository for answering questions.
• Seize the teachable moment. When someone comes to you with a question, show them how you find the answer in the CMS. Next time, walk them back to their cube and talk them through the search themselves. Invest your time in teaching your users to fish. Of course they would rather you serve them fresh fish and chips to order. This will not scale. (Pun intended.)
  
• Keep track of all the questions you get asked in a given time period and how you answered them. This will make the ROI of KM very visible to your manager.
• Find ways to add and update content daily, in small doses. Building a KM system is something that will always fall into the "when we get to it" category. It's your job to get to it, since you're the one who needs it the most.
• Integrate email into your CMS!!!! If you can't pull AND push content via email, your system is doomed.
• Users can and will insist on personal and customized, just-what-I-need-to-know content. Explaining that you cannot send each and every QA person a daily list of only the bugs they need to review is often fruitless and may result in your manager ordering you to do just that and work extra hours to do it. Invest your extra hours in building an automated system to do it for you.
• Give your CMS a face. Be the Knowledge Manager and the Go-To Person. Then, and only then, send them links to answers as your first line of defense.
• Remember that asking good questions is a learned skill. If it's easy for you, it's probably transparent and you wonder why others can't just go find the answer themselves. Notice what questions your users are NOT asking before they come to you.
• Elicit expectations actively and up front. Pay careful attention to what The Few stakeholders expect, especially what they expect you to know without telling you. These are the most difficult expectations to manage, and you may have limited choice in mitigating risk.
• You will never stamp out the process of emailing attachments, but you can damp it down by sending links instead.
• If you are serious about cutting down on attachments, enlist your IT department to place a limit on mailbox size. This will make your users scream bloody murder. Let IT be the bad cop so that you can be the good cop by promoting links as an alternative.
• Be polite but firm with people who email you documents to post for them on the CMS. You may have to provide that service, especially for your manager. If this practice is choking your inbox, reexamine your navigation structure and ask why it's hard for your users.
• Do not expect your users to memorize your directory structure. If they ever do, they will not let you change it. Be gentle with people who post things in "the wrong place." Make sure your CMS can handle the manual routine filing that you will need to do behind the scenes.