Musings On Choosing a CMS: Feature Overload [NF0]

I’m working with a major client choosing a CMS.

In this particular choice, it’s a multi-year, multi-million dollar choice.

If all goes well, it will eventually be a system that touches from at least 1000, to many thousandsof staff.

Their demanding business context has quickly filtered the market from literally thousands to only a handful of systems. We’re now down to two major vendors. The first of these vendors is demonstrating their extremely powerful system.

Problem: it’s too powerful, and too customisable.

(Note: You may also find this Webinar on differentiating and understanding the value-add of different types of CMS. It looks at the differences and roles of Web CMS, Component CMS and Document MS (DMS) systems in an enterprise architecture)

Spoiled for Choice

The system is positively bristling with functions, but as a result, it looks unusable. By the end of this week we’ll have spent 4 straight days digging through this thing.  As the product selection team, we’re looking at as many aspects as humanly possible before the selection process itself stops being cost effective.
What’s happening is that with too many ways to do something and too many options, the whole thing seems daunting.  If you’ve not used a CMS before, or used only lightweight or simplistic ones (you know who you are, Vendors!) then a big customisable beastie can start to look like something you’d dread putting your users in front of, then having to train on and support.

Metrics vs Feelings [NF1]*

As scientific and unbiased as we try to make software decisions, there’s a very real and human component. And it’s an important one. When I talk about brand I talk a lot about the brand “experience”.

The whole “holistic content strategy” thing is about looking at all aspects of how content affects the experience of the brand.  It’s crucial to whether we’ll move from one phase of a relationship to another.
For this project we’ve defined 31 high-level use cases which between them have nearly 350 specific points of evaluation. Each evaluation point is then given a score and weighting multiplier, resulting in lots of juicy math and pretty pie-charts to make everyone feel confident and rest easy.

But do you go with the system that’s better on paper, or the one that feels like you could live with it?

Take Aways

What I’d like to put forward here is two musings from my experience with buying CMSs:

Not Just a Pretty Face

Don’t dismiss UI discussions as a software ‘beauty pageant’.  UI discussions are important.  Bad UI in your internal systems is damaging to performance in the same way as bad design of the content you’re managing in it.  The message gets lost, and you’re slowed, if not prevented, from realising your goals.
The fact that staff can be “told” to do their jobs but users can’t be “told” to engage with your content has some effect, but don’t rely on this factor. (This is especially true for those looking at buying structure, adaptive content, XML, or DITA-capable CMSs.)

It’s Not About You

That said, remember that this is technology we’re talking about.  Configuration options can be overwhelming, but especially with big systems, they’re there for a reason.

You want something that can grow with your business.  As the stakeholders in the system decision it’s your responsibility to understand how the system could look different to different user roles in your organisation.
The fact you’ve got to sit through ALL those options, doesn’t mean they do. You’ve got to sit through 20 examples of how the interface could look, but they’ll only get one or two.  As with all decisions in business, we must step outside of our emotional reactions and think on behalf of others.

Use the Math

The Use Cases and formal points of evaluation are your sanity check. As much as I think that people should weigh subjective user experience into the decision matrix, it is one – albeit important – factor among many.
Develop your use cases well, validate them with your users, then make your vendors go through them, ideally, with your content.

Investing in your use cases is vital.  Then you’ve got to brief the vendors to make sure they walk through them properly.  It’s easy to squander huge amounts of time, and eventually not be comparing apples to apples in the flow of canned demos.

If you don’t structure your evaluation, you’re only left with “I liked that one better, and I’m pretty sure they ticked all our boxes”. That’s not a reason to invest in any key system, and not a defensible position if anyone asks in 6 months time what you did with all that budget.

Any one else have CMS selection tips they can share?

* This is an NF (Nerd Factor) Rating


  1. Mark Baker

    Nos, my CMS selection tip is to pay close attention to the data model.

    In the end, the data is the only thing you own. The vendor licenses you the system, but they own it, and they decide what features they will add and when. What you should care about much more than the capability of the system to perform the functions you want is the capability of the data model to support the functions you want, and to support them efficiently. You can add any functionality you need if your data supports it, but if the data does not support it, the refactoring of the data to support a new functions could cost millions, and take years.

    The problem with specing a major system purchase is the same as that of specing a major systems development project: you spec every feature you think you might ever need, because you think you won’t get another chanced to ask for something you might need. This bloats system costs, as well as deployment cost, and a year later you usually find that you don’t use half the features you paid for, and you don’t have half a dozen features that it turns out you actually do need.

    At that point, a list of function points isn’t going to help you much. But a sound data model will save your bacon, making it possible to implement the features you forgot to spec.

    My advice: reduce the number of features to be made available initially to a minimum and focus on developing and implementing a data model that will allow you to add functionality incrementally as your experience with the system shows you what you really need and don’t need.

  2. B. Noz Urbina

    Hi Mark,

    Sorry I took so long to get back to you!  Absolutely. 

  3. B. Noz Urbina

    That said, when you say ‘reduce the number of features to made available to a minimum’, again, I agree, but that shouldn’t somehow turn having features into a negative mark on the product.  I find that first time CMS buyers – simply by the nature of not having bought/used CMSs – are overwhelmed by features they’ve never been exposed to before.  

    The result is that under-powered systems that lack features that will be very useful after the ‘initial’ phase might get passed over because they have all sorts of abilities that the buyer can’t yet see themselves using.  

    I had a client once say that publishing was more complicated that content management, which was relatively easy.  The thing is, she’d only done a publishing implementation, and hadn’t yet actually tried to do production-level CM for a large group.  

    It’s important to be concious that although we can’t know everything, we can know that we don’t know, and that can really help!


Submit a Comment

Your email address will not be published. Required fields are marked *

Go deeper

Want to learn more? Reach out to discuss your content challenges.


Brought to you by Urbina Consulting

Learn from leading brands with case studies, articles, and events via OmnichannelX.

This international learning hub covers omnichannel content, design, governance, and systems. It’s for everyone from beginners to advanced practitioners.