Two years ago, I had my first experience of implementing a content management system (CMS). I will withhold all names of organizations, people, and platforms to protect the guilty, but let’s just say it’s painful even now to recall the confusion, the groping, the anger, and the desperation that my group went through. There are probably support groups out there to help us recovering CMS implementers, but in case you’re teetering on the brink of your own CMS implementation, about to go over the edge into the abyss, I want to offer some perspectives from our experience.

If you’re getting ready to implement a CMS, and you haven’t yet worked out your content strategy, then I urge you to do it now. If you don’t, you’ll find yourself saddled with a cumbersome CMS that doesn’t do what you need it to, that actually multiplies (rather than reduces) the time and resources you spend managing content, and that everyone curses and tries to circumvent.

A System Without a Strategy

I’m sure that other folks know more about how a CMS implementation is “supposed to go”—or maybe I’m simply naïf, and it’s always a crap shoot—but this is where it began for us and where we first went wrong.

Our consultants were exceedingly thorough in their project plan. They insisted on an exhaustive requirements gathering phase. They asked us, “What do you want your system to do?” We, being CMS noobs, responded, “Uh, we don’t know. What can it do?” They responded in their most solicitous tones, “Anything you want.” Round and round we went, we on our side trying to comprehend what CMS could do for us, and they on theirs trying to architect a system to fully satisfy the undefined requirements of a nonexistent content strategy.

Authoring Environment: The work areas and system branching were established before any questions of content ownership could inform them. For each of our websites, there is now one, all-encompassing authoring area, through which all our content authors tip-toe. It’s a good thing that we have fewer than 20 active content authors, and that we’re all friends.

User Permissions: Because the system was configured without a clear plan for who should be given which level access, we started simply: In order to share the one enormous authoring space described above, we’ve given most users administrator-level access. I know, I know…not cool, but it’s now so deeply configured that it’s hard to change.

Workflow: We didn’t really understand how a CMS could manage a workflow, so the system gives us one, basic workflow for everything. If you author it, you can publish it. If you want someone else to look at it, you send them e-mail. See “User Permissions” above.

Templates: Our data and presentation templates were developed starting with something called a “standard page,” meaning “no content type.” Guess how much of our site is based on that template? You’re right—a LOT. We did get wiser about content types as we went along. Some of our content types corresponded to unique publications, but we had only a rough idea of what metadata we might need even for those. Once you’ve begun populating your templates, it’s hard to make any change to their basic structure. We are stuck with some of our fundamental, uninformed decisions, and perhaps we’ll fix them next time around, when we have to migrate all the content to another system.

Platform: In our particular case, the CMS does not interact with the webserver, except to deploy files. Although we had a hard time believing that this could be the case, very late in the process, we realized that if we wanted a dynamic website in any sense, we’d be on our own to come up with a web application that would work with the CMS. A content strategy would have helped us articulate our requirements for the functioning of the website and insist on what we needed.

In the end, we have a CMS that we call our “glorified FTP server.” Our templates are ok for some things, but lots of our content is still composed in an external web editor, then either imported into the CMS or pasted into the templates because the CMS WYSIWYG editor isn’t adequate for sophisticated HTML. We have made peace with the system, but in our darker moments, we imagine all the things we could be doing with our CMS now, if only we’d known what we were doing in the first place—if only we’d had a content strategy.

CMS without CS

Designing and implementing a CMS without a clear content strategy leaves every decision to best guesses.

Content strategy scopes the content domain: For whom are you producing content? What is it supposed to do? What media will it employ? How will it produced? How will its effectiveness be measured? This is the strategic context into which your CMS is built.

Content strategy identifies content types: The whole basis for CMS templates is the content type. The content strategy not only identifies the content types that will be built into the system, but it specifies their basic structure, their metadata, their required and optional fields, their controlled field values, and their options for presentation.

Content strategy defines content presentation: CMS templates separate the content from its presentation. You create the content, then select from a range of presentation options. Without a content strategy, there’s no clear path from the visual design of the site to the visual design of all the kinds of content.

Content strategy maps the workflow: CMS generally provides customized workflows, so that content can be authored and published in a smooth, controlled process. Content strategy lays out the processes by which content is generated, published, repurposed, and retired. These processes can then be encoded into the CMS workflow.

Content strategy sets the rules for content archiving and retirement: A good CMS should have a good archiving system built into it, so that content doesn’t languish forever in outdated obscurity on your website. Content strategy guides the process for reviewing, refreshing, and ultimately retiring content into an archive.

Content strategy suggests the platform on which the content is delivered: In my limited experience, a CMS seems to require another application layer on top of it that actually drives the website. (Maybe that’s just the idiosyncratic failing of our CMS.) Without a content strategy, however, it’s not clear what that web application needs to do or how it will draw from the CMS, if it can.

Don’t Let This Happen to You

I tell you this because if you have no idea what content you’re going to create, how it will be produced, and how you need to govern that process, you’ll have no idea what to tell your CMS guys when they ask for your requirements. I hope you find my grim tale helpful. I’m a much wiser content manager now than I was before, but a content strategy would have spared me the scars.