Learning to Manage Your Content

Mark Lewis, Quark Inc.

Managing content is like riding a bike. It’s really hard…at first.
Both managing content and learning to ride a bike are complex. Nobody does a better job of breaking down the complexity of learning to ride a bike than the autistic boy Lou in the book “The Speed of Dark.”

Lou rejects the traditional approach offered by his parents and instead breaks the problem into its components:

  • Learning to steer
  • Learning to  pedal
  • Learning to balance

To Lou’s autistic mind it is clear that the first skill that you need to learn is steering. So, he walks beside his bicycle pushing it around the yard turning and straightening until he gets the feel for steering the bike. Lou succeeds. He then adds pedaling and balancing and soon rides.

Now it’s time for my son Logan to learn. Ironically, a friend told me that they had removed the pedals from their child’s bike to eliminate the complexity of pedaling from the equation. Hmmm. Problem: learning three new skills at the same time. Answer: Break the problem down into its components. Learn one new skill at a time.


First I remove the pedals and I place Logan near the bottom of a hill. All he has to do is lift his feet and roll to the bottom of the hill. He does it. Then he starts further up the hill for more power, adding pedals but only using them as footrests. He learns to balance. As he masters one component/skill, I add another. I add silly turning games. He learns to steer. Last, I ask him to trying pedaling. Pedal Logan. He pedals away and out of sight. My vision blurs….a little.

Break Down Content Management into Components
Managing your content is a huge task. You can break it down into components like you do to learn riding a bike. The first concept to learn in content management is the content lifecycle. Content lifecycle tasks are broken down into the following categories: requirements, design, implementation, test and maintenance.


Know Your Requirements
It’s common at a conference or workshop to have someone say “Can you recommend a CMS?”, or “Should I use schema X?”

The answer is it depends. It depends on your content requirements and your process. How do you know what to buy until you’ve determined what you need? And when I ask if they’ve documented their current processes and performed a content audit and the answer is no, then they start to get overwhelmed, but they don’t have to.

This is all part of the requirements task. This big task can be broken down into much smaller tasks. In fact, breaking down the requirements tasks is called a “work breakdown structure” (WBS).


Now you have smaller components that are quite manageable and do-able. The following Gant chart shows these component tasks in a timeline.


It’s a proven methodology. For software engineers, the lifecycle is similar: requirements, design, implementation, test and maintenance. Why? Because an engineer needs to know what is needed (the requirements), needs an architecture that supports those needs (the design), before they can write code (the implementation). Otherwise, it’s hacking. And we all know the results of hacking, garbage software. Have you ever read garbage documentation? I suspect that you have. We’ve all seen far too many new CMS, new tools projects fail because the requirements gathering and content design steps are skipped.

For more information on requirements, see “Doing Requirements Gathering” and “the wheel of content management” in Bob Boiko’s book the “Content Management Bible”.

Perform a Content Audit
Part of the requirements task is performing a content audit – identifying the content you have and the information products you have that contain that content. The WBS shown above contains two content audit tasks: top-level analysis and an in-depth analysis. They sound big and scary. But aren’t.

Here’s part of a top-level analysis I did for an accounting system. Even without understanding the details of my content, the analysis is easy to understand. I have content about accounting features that is being repurposed in a collection of information products. This is straightforward. You can do this for your own content.


The design task of the WBS is not so scary either. Let’s take a look at one of its sub-tasks, information modeling.


You’ve been working with information models (and structured authoring) for a long time, but you probably didn’t realize it. Take a resume for example. The information model for a resume is designed to satisfy a set of content requirements. A person wants a job. An employer wants information about a potential employee to help them decide if that person is a good candidate for the job. A typical resume contains the following components:

  •  Contact Information
  • Objective
  • Skills
  • Experience
  • Education
  • References

Let’s look at another information model that you’re probably familiar with, the model for a business letter:

  • Letterhead or sender’s address
  • Date
  • Recipient’s address
  • Subject
  • Salutation or Greeting
  • Message (body of the letter)
  • Closing
  • Signature

For my accounting project, I created an information model for content about the various features and entities in the system. The model is simple:

  • Title
  • Navigation Path
  • Definition
  • Usage
  • Image
  • Example
  • Prerequisites
  • Description (Marketing)

If you have completed the requirements task, and your content requirements are clear and accurate, the design task becomes much easier. You can see from these examples that information models are nothing to be afraid of.

Create a Reuse Map
With an information model in place, the next step is to create a reuse map. Creating a reuse map is one of the first steps toward designing a reuse strategy. The following reuse map shows my information model and how the content components are reused in my information products.


Again, you can do this for your own content. Use your model to determine if you can use a standard schema such as DocBook or DITA. If you can easily map the elements in your semantic model to the elements or customize the standard schema, then use the standard. If not, then you may need to roll your own schema. For more information on information modeling, see Bob Glushko’s discussions on “harvest tables” in his book “Document Engineering” with Tim McGrath.

In conclusion, by breaking down the tasks of managing content using a proven methodology like the one outlined above, you make it easier. By doing your due diligence of gathering requirements, you’ll be able to design your information models and design a reuse strategy. You’ll succeed and be in a better position to tackle your next content project. You’ll find it becomes easier and automatic, like riding a bike.