How to Choose a CMS

So how do you currently select a CMS for a project. And I’m asking this more of the people who will be using the CMS to manage their website rather than those that will be doing the development work.

Far too often people assess a CMS platform with giant spreadsheets listing features the CMS should have and score each candidate on each feature. The problem with this approach is that any good CMS will be flexible and extensible and will be able to meet all of the criteria you’ve set out in your spreadsheet. In fact, I can’t remember if I’ve ever responded to this kind of feature matrix with a “no, Sitecore can’t do it”. Sitecore is very flexible and extensible and any feature required can be met, as long as adequate time and budget are available to do so.

So why are these spreadsheets used? This kind of CMS selection tool normally appears early in the selection process to weed out the duds. At the start of any kind of selection process filters need to be put in place to get rid of the candidates that have no chance of ever meeting your requirements. This is why we have potential employees send us resumes and this is why we have to make sure the CMS that is being considered is (as I qualified above) “good”.

But once you filter the duds out it is highly unlikely you’ll find enough differentiation between the CMSs left in the race to make an informed decision. To quote a recent blog post from Janus Boye:

10 years ago when only few vendors supported certain features, e.g. workflow or Office integration, vendors could easily differentiate themselves on features, but today that is different.

Once you get to this stage of selection it is more important to understand how requirements are going to be met rather than if they can be met. One way of doing this is to talk with your developers (whether they be yours or a development house) and simply ask them to describe how your requirements will be met.

Another way many people try to make a decision at this stage is to request a demo of the CMS, often running through a script of a common day-to-day task to see how that task / requirement will be done. This assumes that there is a magical CMS out there somewhere that can meet all of your esoteric requirements with out-of-the-box features and zero customisation. Don’t be fooled, this kind of CMS simply doesn’t exist. But many come close. The key I think to using this selection technique is to not be too specific in your demo script. Bullet points of areas to be demonstrated work better than a comprehensive script.

But the absolute best way to select a single CMS is to use all CMSs up for selection. Let me describe to you the best way I have seen to do this.

A while ago I was involved in a “CMS Smackdown!” that a potential client ran as part of their CMS selection process. This involved several teams all implementing a mini-site using one of the potential CMSs.

Each team of up to 4 was given a room and 3 days to implement the mini-site. The team make up was up to each team but all work could only be done by members of the team. No development was allowed before the event or out of hours. Much of the reasoning with this approach was because the client wanted to understand exactly what it took to develop a site in the CMSs up for selection. We were however allowed to use existing modules and libraries.

Each team was given the requirements for the build at the start of the first day so everyone was starting at the same pace. Then while we all coded like hell, staff from the client sat in the room with each team to absorb how difficult the implementation was. The client’s staff were a mix of developers and content authors.

And after 3 days of intensive development I was proud we were able to deliver a fully functioning website. That’s a complete website in only 96 hours! I’m quite proud of what we were able to achieve…just don’t tell the account managers how quickly we did it .

At the end of the smackdown each build was deployed to the client’s server and they were able to play with each to complete their assessment and make a decision on which CMS best suited the way they work.

And now for some advice for those who might be lucky enough to participate in a CMS smackdown. If you fail to plan, you plan to fail. Careful with that advice, it’s antique . But in this kind of high pressure environment where you only have 3 days to pull together a website you simply cannot afford mistakes or wasting effort on repeating yourselves. You need to make sure you’re organised and each team member knows exactly what to do. My team even went as far as taking a source control server with us to coordinate each of our code edits.

Yes, I know this approach can be expensive, but when you’re dropping a lot of money on a new website build isn’t it worth spending a little more to ensure you’ve chosen a CMS that works for your organisation?