Thinking beyond the CMS feature checklist: validating requirements and considering change management

By Peter Keung

It’s important to see the forest for the trees when choosing a CMS

Selecting any new technology for your organization often results in a comparison of features, and the decision can come down to which product has the features you want.

But when it comes to choosing a CMS, to some extent they all have the same set of core features. You’re not usually technically limited on what you can do; the key is often in understanding how those features can be used effectively in conjunction with your organization’s processes.

Example: Editorial workflows and your CMS

Let’s take editorial workflows as an example. I’ve been in countless evaluation meetings where we’re rattling down a checklist with questions like “does eZ Publish / Platform do workflows?” The answer for eZ, and pretty much any CMS you’re going to evaluate is “yes”.

eZ has various core features that support a variety of workflows, and we’ve even created an editorial approval workflow extension that brings some of the features together. We’re not worried about whether we can technically achieve what you need.

More importantly: what are the necessary parts of the CMS workflow and how will they integrate with your existing online and offline flows? You might be tempted to define a strict order of approval steps within the CMS, including complex e-mail notification rules per section and per department. But just because you can do it technically, doesn’t mean you should do it that way.

It’s best to take a step back early on and evaluate how you currently handle your workflow:

  • Does the writer call or e-mail the editor, or even walk over to their desk?
  • When you work on editorial changes, do you officially assign the task back and forth to each other at different times of the day, or do you sometimes collaborate in real time?
  • How will a new CMS change people’s habits, and to what extent might they need to circumvent the workflow rules?
  • Are there offline assets or systems relevant to the workflow that won’t be in the CMS?
  • What happens if someone is on vacation — do all pending approvals pause?
  • Is there a plan for training editors, managing the adoption of the CMS workflow, and evolving the workflow over time?

None of these questions has anything to do with the CMS’s features. But they’re very important in the context of setting up your workflow to create effective processes. And the same would apply to any other processes that the CMS affects, including print and digital subscription fulfillment, ad management, e-newsletters, and so on. You need to surface what organizational changes the CMS will introduce, and ensure that you have the right change management plans in place.

It is a mistake to define your implementation requirements solely based on capability. Some rightfully rationalize this as the difference between a “buy spec” and a “build spec”; the problem is, the “build spec” is frequently omitted. Given the capabilities of mature CMSs nowadays, consider rolling in more of the “build spec” early on in the process as part of the “buy spec”. This helps to set the tone for the eventual implementation, helps to validate the “buy spec”, and ensures that key non-technical factors are not forgotten. Thinking beyond a simple comparison of features to specific processes, and process improvements, can help ensure you not only get a new system that works for you, but also that you get it functioning optimally to serve your needs.

Peter Keung is Mugo Web’s Managing Director. He has written books and documentation about eZ Publish and has managed some of the most complex eZ Publish implementations at the American Museum of Natural History, Hootsuite, Rasmussen Reports, and more. He’ll happily chat about CMSs anytime.