These are not the right questions.

Better questions revolve around how well the CMS can support and enhance the business, and whether it can continue to do this as the needs of the business or the customer change.

In an earlier post, I outlined 4 things a CMS must do. To recap, it must: 

All of them ‘obvious’ yet I know of projects that have failed to even deliver satisfactorily on point 1.

The greatest tragedy of many CMS selection projects is that unreasonable constraints are in play before any business needs are even written down. Constraints such as:

1. The technology to be used.

This may include the operating system or database type, or even the CMS itself.

“We are a ‘X’ shop.”

“We only have ‘Y’ Licenses.”

I am not saying anything about ‘X’ and ‘Y’, just that the thinking is a constraint you could do without.

There is also, “We have too much invested in our existing suite of products to change”.

2. The vendor to be engaged.

“We already have a relationship with ‘X’ to handle this for us.”

Again, nothing wrong with ‘X’.

3. The project owner

“All projects in the company with a major IT component will be run by IT.”

There are a lot of fishhooks in here. Projects need to be run well. There have to be agreed outcomes, and risks have to be managed. The issue I have is that this is a business project. The technology being selected is to support a specific business process and a defined output.

An example of a purely IT project would be a network switch upgrade. There may be business outcomes such as improved throughput, but the core of the work is technical.

In a business project the majority of the outcomes are on the business side – faster publishing of content, easier workflows, and improved ease of use for the public being just three examples.  

Certainly, let anyone with a good track-record in project management run it. Just remember they are working for the business owner of the project. The technology is the servant. Everything it delivers must serve the business. If there are integration issues, put someone from IT on the project team.

4. We have to support it.

“All company IT is supported in house for security reasons. We have to know what the users are doing.”

Working for the GCSB or SIS? OK, you can pass on this one. The rest of you don’t get to pull the security trump card to stop new systems being selected. A good project will assess security implications of new systems. As above, include someone from IT who specialises in your in-house security on the project team.

===

Constraints like these are bad because they ensure that any project process will only deliver what it is allowed to deliver. That is not good enough in this modern age.

So back to the question, what CMS should I choose?

You could look at just the features, and Smashing Magazine covered those basics back in 2009. Not much has changed, but that isn’t really the right answer either.

The key to getting the right CMS is to have an understanding of the business objectives for the site, the content publishing processes (existing or new) to be supported, and to run an excellent selection process. In that, you’ll want to avoid artificial constraints such as those mentioned above.

Real constraints such as budget, time-frame and project scope are fine.

You will also want to adopt some agile thinking – the project must be able to adapt as new information comes to hand, or as the business or the market changes – and you must have the flexibility to change some of the project parameters.

It is true that you have the most flexibility with systems based on Free and Open Source Software, but that might not be a requirement. You may need to outsource development and support of your whole system. These are long-term decisions, and you’ll need a lot of information to get it right.

If you go with a proprietary system will it be agile enough if market conditions suddenly change? Only you can say?

Are you going to be disrupting an already existing market. Yes? Most disruptors are using Open Source. End of story on that one, really.

One trap is to try to copy someone else’s ‘magic formula’. It is almost never successful. If you try to copy a competitor by using the same system you lose, because they already have a head-start and you can only act based on the public information you have. This will be out of date.

Another is go with fashion. All the cool sites are using Rails, so let’s use that. Bad again. The’ve chosen Rails for specific reasons based on their product, development process, funding and market. You might come to this decision independently – in which case, great – but if not, think again.

A third is to get someone else to decide. No one knows your business and your market like you do. Any consultant or vendor is never going to reach your level of understanding. You are the best judge of what factors are important to you.

If you are unsure, by all means engage an independent consultant who is familiar with running selection projects. They should be able to help you balance all the required factors based on your own business requirements.

The bottom line is that it is not really a question with a simple answer.