The really simple guide to choosing a web content management system

By David Walker (Google profile)

"i know we need to do more with the website but I'm getting differing advice about what system to choose." I've run into friends, colleagues, acquaintances and complete strangers with this problem over the past 15 years. You see them sometimes on StackExchange and Quora, posting a question along the lines of "What is the best content management system?", and getting told "there's no one best system", which annoys the heck out of them, because they know there must be a best system for them, in their current situation.

The best CMS is the one that will eventually do most to make their organisation work better and make them look good for choosing it. That's what they want. The trick is figuring out how to get it.

So here's one way to think about that problem.

CMS selection is hard

Let's be brutal for a moment. At heart, most people don't know much about selecting software. They will happily choose the market leader (hello Microsoft, hello Adobe), the free popular solution (hello, Gmail), or the solution clearly targeted at their niche. In the content management space they can't choose any of those - there's no market leader, and even the free solutions will cost money to implement. So they're lost.

There's nothing wrong with being lost. The content management landscape is extremely fragmented and tremendously confusing. As I write this, Wikipedia's CMS list contains 174 products. Some of the biggest players, like OpenText Content Suite (formerly OpenText Web Experience Management, and a long series of names before that), are still struggling to overcome poor reputations earned more than a decade ago. Smaller commercial players offer some excellent packages. A few open-source projects are among the most admired in the field. Custom-built systems still play a big role in many organisations.

At heart, it's a people issue

Yes, selecting a CMS is about technology. But if it's going to be effective, your new CMS is going to need to be a tool for people working in an organisation. So it's going to need commitment.

I can put it more strongly. When you put a CMS in an existing organisation, you're engaging in politics. You need to find out what people want, and why. You need to show you're delivering it, explain to them the considerations which they don't know about but which have to be taken into account, and convince them you're acting to bring them the best possible tool. If your audience is lawyers or marketers or, really, most knowledge workers, they will already have firm work patterns that they will not break without a great deal of convincing. If the deputy CEO has a friend whose mate has persuaded her that .NET is no good for content management systems, or that Documentum will solve all her problems, you will need to be able to change her mind or at least open it to other possibilities.

If I've made it sound like the politics is a bad thing, I don't mean to. The truth is that managers have good reason to fear that the wrong system will be selected. Most experienced managers have experienced the damage stemming from a bad choice of IT system, if only because bad choices are so common.

Many, many CMS projects fail. And by far the biggest problem is that people don't like using the tools. Jeffrey Veen wrote Why Content Management Fails more than a decade ago now and it is still true:

I’ve spoken to a number of Web teams that have used a CMS with varying levels of success. One problem I heard repeatedly was that the project worked fine, but nobody used the software once it was available. I call this the Stupid User Argument, and it’s a favorite of IT departments. The techies did their jobs, after all: They diligently gathered requirements, scoped out the solution, carefully selected a vendor, and managed the project to a mostly on-time and on-budget conclusion.

So how come nobody actually uses these systems once they’re in place? The answer is easy: People don’t like to change the way they work, particularly knowledge workers.

Knowledge workers spend years building strategies to accomplish their jobs, practices that likely date back to study skills acquired during their education. So changing those processes — no matter how valid the provided technical solution — is nearly impossible. Users will rebel, even after substantial training.

Find out what's driving the need

If your organisation is contemplating a major IT project, there's probably a reason. It may be bad, it may be good. At some point, someone decided the organisation needed to commit resources to a new CMS.

So your first question is:

• What has triggered this project? Was there a paper written by an outside consultant and signed off by the CEO, a document that you can use as the charter for the entire job? Was it an angry thought-bubble from a department head confronting some content stuff-up, who who will blanch at an $80,000 total project cost? These two extremes drive very different projects with very different budgets and outcomes.

CEO commitment is vital. If you have that, everything else will be easier. Without that commitment, you have a much bigger job.

Find out what sort of budget is being discussed. In the context of your organisation, that will tell you how a great deal about attitudes.

Also bear in mind that a demand for new technology sometimes hides different underlying problems.

IT solutions have all sorts of useful shortcuts. Maybe your whole project is driven by a bunch of information coming out of an internal spreadsheet, and there's another way to automate the production of that data without completely changing systems.

And publishing is a specialist skill. Maybe marketing doesn't have anyone who's been exposed to publishing disciplines, or IT has the content responsibility but no-one who can correct copy. If that's the case, the project is doomed before it starts, because no new CMS will fix these problems. Jeffrey Veen again:

There is a larger issue at play. Even the most thoughtful projects may be misguided. Over and over I’ve heard the same complaint about these projects, “Turns out, after all the budget and time we spent, we really didn’t need a content management system at all. We just needed some editors.”

For more on this, see Content Management is sometimes just management, on this site.

Find out what your people do

Your next two questions should be about organisational capability. That is, you must ask people:

• Who will be building and maintaining the technology? If you're a small group with a couple of Web designers on tap, check out a designer-friendly free system like MODX Revolution or Expression Engine (this site is built with MODX). If your organisation's big IT department is devoted to Microsoft solutions, then find the best .NET CMS that meets your needs - Umbraco, Kentico, DotNetNuke, whatever. If your trusted web services provider has spent the past five years dealing with ezPublish, you have your starting point. If some of your people have worked with Drupal and want to do it again, then that's your leading candidate right there. When it's time to make a project happen, nothing beats the enthusiasm of your colleagues. And if you don't have people or suppliers with the ability to work with any of the systems, it's time to find yourself some new people - which is a project of its own.
• Who will be adding content to the system? Internal users will want an interface that rewards use - it must react fast, protect the user from losing their work, make content easy to find, and ease tasks like creating new pages and including links and images. That might push you towards CMS Made Simple, or even WordPresss if your needs are otherwise modest. And if most of the content will be contributed by a user community, the CMS must support a strong forum capability.

In almost all cases, the biggest cost of a CMS is the cost of the people who will work with it. If you can make a decision that gets the best out of people, your CMS selection project will be well on the way to success. And you need to make sure that senior management understands that. (Smart managers will, because smart managers think in terms of organisational capability.)

Then find out what your people need

While you're talking to people about those personnel issues, ask what the system need to do. If you're new to the software world, this is called requirements-gathering.

So now it's time to ask:

• What do you need the system to do? Don't kid yourself; this is hard. Online forums are full of advice to "know what you want before you start". The reality is that you will not know exactly what you want even when the system is commissioned. Kim in marketing simply cannot tell how much workflow capability to trade off for better versioning; she's never really been exposed to a good workflow system and doesn't know whether it would make her life better or worse, and she cannot explain what would be the value of reverting the site to the way it was last week. She certainly cannot tell you the preferred trade-off of the person who will unexpectedly replace her half-way through the project.

You should take a look at Step Two's document How to evaluate a content management system. It's old now, but these guys know their stuff.

Do bear in mind that not all requirements are created equal. For instance, many CMS texts stress the importance of complex workflow and versioning. In large publishing businesses, these are sometimes important. In most smaller organisations they don't matter as much. Your workflow may consist of one person putting content into the system and another approving it to go live - the sort of task that can be accomplished with a staging server and email. Versioning may be adequately covered by a regular back-up.

Last, help people understand the process

When you have a system, remember this: being right is not enough. This is a complex people problem, so it's important to make people understand what the landscape looks like and why you've come up with the choice you have. Again, think like a good politician. Once you know what needs doing, don't pretend it will be easy. Instead, soften the audience up by creating a clear sense of what the real problems are, and then explain why your ssolution is the best way to fix them.