27 March 2014
Here’s the truth about CMS selection: It doesn’t really matter…
I have lived through many CMS projects, both as customer and implementer, I’ve learnt that it’s not the technology decision that determines whether or not you will successful.
They generally stress the importance of engaging with stakeholders and carefully assessing platforms against some kind of feature matrix. Most will recommend developing a deep understanding of your organisation’s use cases, some debate whether or not to use a scoring mechanism while others try to distinguish between selection criteria and requirements.
None of this contributes that much to the eventual success of your online publishing. Most stakeholders don’t really know what they want and many won’t have any experience of using a CMS. It’s also difficult to come up with meaningful long-term requirements for something as fast moving as online publishing. There is always some value in leaving an audit trail to explain technology decisions,, but your time may be better spent working on a decent content strategy rather than agonising over the technology.
Many CMS implementations do go wrong, but this rarely happens because you selected the wrong platform. It’s more likely to be because the UX got carried away, the project manager went to sleep or the CTO decided everybody should switch to open source. Any implementation is subject to unexpected changes in circumstances that your carefully crafted requirements matrix and stakeholder engagement won’t protect you from.
So what does matter?
In most cases a CMS selection is a commodity decision. CMS is a pretty generic technology these days and for the most part the choice comes down to how much you want to spend. Once you have decided on your budget there will be a range a range of solutions available, each of which meet your requirements to a surprisingly similar degree.
For example, every middle-market CMS worth its salt will support versioning, workflow, multi-lingual content, rich security, social media integration, flexible content templates, content security, search engine optimisation, content search and asset management. You can waste a lot of time trying to isolate the subtle differences between these platforms based on generic features.
That’s not to say that you can toss a coin to make the decision. There are still a few questions that can make a difference, it’s just that they rarely appear on a requirements matrix.
1. How much will it really cost?
Most CMS decisions are made on cost alone, but often the wrong cost. There’s more to a CMS project than the license fee as you should include the servers, training, annual fees and several years of on-going developer costs. That extra twenty grand for an initial license will seem like small beer after you’ve spent three years throwing money at the implementation.
2. Who will implement it for me?
You’re not selecting a spouse. It’s a piece of software. The choice of implementation partner is probably a lot more important. These are the people you will have to deal with when the project is late, the site goes down or you find that a new feature will cost a fortune to implement. By this point, the vendor has banked your license fee and disappeared into the sunset.
Many organisations get agencies or consultancies to help them select a CMS and most will guide their customers towards the platforms that they feel most comfortable delivering. This is not as cynical as it may sound. After all, if you are sold on the relationship, then it makes sense to use something that gives the implementation a greater chance of success.
3. How easy will it be to get rid of this CMS?
When you’re left with a smoking crater of a dead CMS, how difficult will it be to get out of it? Will you be able to export everything or are you forever tied into the implementation?
It’s a great question to ask vendors for the hell of it as it always makes them blush, but there is a serious point here. You should expect things to change and the last thing you want to do is couple your content to a monolithic platform that is long past its sell-by date. If you are going to use a CMS platform for five years then you’ll need something that will evolve with you. If this doesn’t happen then you will need an exit strategy.