Selecting a Content Management System (CMS)

There are already various sites comparing features of content management systems (for example the CMS matrix), so this post aims to help set a framework for selecting a Content Management System (CMS). Aside from standard things to keep in mind when selecting a technology, there are some particularly important items for setting the tone of your CMS selection:

• Standardization / Governance. Is one of your objectives to standardize the look and feel of your site, or to try to ensure there's a consistent quality across your site? If so, then before you start moving into the new system then deciding who will make the decision of what goes up and how the decisions will get made is important. Sure, an advantage of a CMS is that anyone can publish, but this can lead to inconsistent quality. I'm not just talking about how workflow: for instance, who makes the call about adding a whole new site section?
• Stakeholder buy-in of objectives. This one is of course part of any technology decision, but some key factors in deciding about a CMS are: a) if you've decided to standardize aspects of your site, make sure everyone is bought in (otherwise people will try whatever they can to get out of the standard), b) if people's jobs are going to change (for instance, people that are doing hands-on HTML coding may not be doing that anymore), then is everyone clear on this?
• Envision key use cases. After you're in the middle of migrating your systems, you may lose sight of why you undertook this in the first place. Laying out key use cases in advance allows you to both not loose sight of the goals and also let's you more easily claim victory. Key use cases might be something like "Will be able to allow any staff member to publish a piece of content, resulting in it automatically appearing on the home page as well as the relevant country page, and also appears in country's RSS feed and email alerts". Of course, you also should list key use cases that you don't want to go away like "Compare statistics across different areas of the site in a consistent manner."
• Make sure everyone understands the complexity of a move to a new system. See this post that lists some of the complexity.

These are some of the particular factors to consider when selecting a CMS:

• Tagging. For a large institution, you may have issues keeping consistent quality in your tagging (and you may wish to consider an automated concept extraction tool to help in the tagging). At any rate, you will want to think about a method of tagging that will work for everyone (and ensure that your system will support this).
• multilingual/internationalization support. See this page that describes different levels of multilingual support. Some more advanced types of features to consider are Administrative Title and Interleaving Languages.
• distributed or centralized content entry input. This relates to the issue of standardization above.
• community/support.
• multiple site support. If you need to have multiple sites, what kind of functionality do you need? For instance, does content need to flow between sites? Do the different sites need to enforce a consistent look/brand?
• integration with other systems or all-in-one. A key decision will be how you are going to integrate with other systems, and, if integration is not as important (for instance for a smaller organization), then ensure that your solution supports the different functionalities you need.

With everything on the web moving so fast now (who knows when Web 3.0 will be the next thing we're all moving to), consider moving to a CMS environment that will allow quick innovation and new functionality. Some specific approaches to this:

• Try to pick a CMS that is innovating quickly. Of course, what you really want is to pick what CMS will be a winner in the future, but the best we can do now is pick a CMS that is quickly adding new features. Looking at lists like Joomla's extensions page for any CMS that you're interested in should help with this. Of course, it needs to be easy to add any new modules/extensions when they are released.
• ease of upgrading to new versions of the core CMS. Obviously hosted, SaaS solutions have an advantage here.
• ease of writing your own new functionality. Would the CMS allow your team to program (in some lightweight language like PHP for example) their own new functionality? If you don't have the skillset, is there a pool of developers outside your organization who could help? Is there useful documentation on how to write your own new functionality?
• support to expose/share data. We have RSS as a mainstream feed now, but what about richer XML exposed for more structured data? More and more, we'll need to support people outside our organizations utilizing our data to write functionality on their own sites, combining your data with other organizations' data.
• integration with outside systems. If a CMS already has integration with other types of systems (for instance, stats, newsletters, email alerts, membership databases, etc), then it may be easier to move to future leaders in these different spaces.