Selecting a Content Management System

As part of the web site improvement project for East Northamptonshire Council, I have been involved in the selection process for a replacement Content Management System (CMS). A CMS allows an organisation's content authors to publish content to its web site.

The current CMS was no longer fit for purpose, and had reached the end of its useable shelf life. It lacked many of the features now found in the modern CMS, such as RSS feeds, social bookmarking (allowing you to link the content to your preferred social media site) and other Web 2.0 features such as podcasts and blogs.

When selecting a new CMS, there is no fixed criteria or blueprint of what constitutes a requirement specification, but there are common themes that should be considered. the list that follows is not intended to be comprehensive, or go into great detail, but to serve as a starting point from which you can derive your own CMS requirements specification.

• Technical specification - This should include the preferred operating system, application server, web server, database technology, programming language (if you intend to extend or modify the CMS) and any other appropriate technical requirements. You need to consider a CMS that is compatible with the tools and technologies that are used within the organisation. The market leaders may not be fit for purpose if they use unfamiliar technologies.
• Content creation - Specify how the content should be created. For example, what requirements are needed in the authoring environment. This could include such features as WYSIWYG authoring (a type of authoring environment where what you see during the design is how it will appear once published and stands for "what you see is what you get"), drag and drop, spell checker, separation of content from formatting, content reusability, metadata creation. The authoring environment should make it as simple as possible for a non technical person to create engaging and professional looking content, quickly and simply.
• Content management - Specify what tools you need to manage your content. For example version control on content to see when a piece of content has changed and by whom, audit trails to see what activity has taken place within the system, automatic notification of when content should be reviewed, Draft-Submit-Approve workflow model, the ability to manage the style(s) that are applied to the content and todo lists.
• Publishing - All styling should be applied to the content during the publishing phase, leaving the author free to create their content without having to worry about how it looks. This should be achieved through the use of style sheets and page templates. This makes it easy to separate the look and feel of a web page from its content. You may want to be able to publish to multiple sites or to a staging server.
• Presentation - It should be possible to view the published content in any of the major browsers. You probably want to consider the amount of client side scripting the CMS requires to run. Remember, you have no control over how the client has configured their computer (except perhaps in intranet scenarios where group policies may restrict or deny such configuration), so you may want to keep technologies such as Javascript to a minimum. The HTML that is created should conform to the latest W3C HTML specification. The metadata that is created for each page by the CMS must be sufficient that it can be used with an appropriate taxonomy, and used in searching and indexing the content.
• Taxonomies and metadata - If you are using a taxonomy (such as LGNL, IPSV if working within local government), then you will need to ensure that it is fully supported. Can content authors add additional information (metadata) to the content to allow it to be more easily found.
• Integration - Do you need your CMS to integrate with any of your back office systems, and if so, which ones? For example, you may need you CMS to integrate with your Customer Relationship Management (CRM) system, or your finance system if allowing online payments.
• Compatibility and accessibility - The web pages produced should be compatible with a variety of different media, and should comply with the latest standards of web accessibility. The web pages should be fully functioning, well-performing and compliant. For example, within the public sector, it is important that web pages meet AA accessibility standards as a minimum.
• Reporting requirements - Allow the interrogation of data held within the CMS. Information should be available on when each item of website content has been updated, and by whom. It may be useful to provide website usage statistics and publish selective information automatically to the website. The CMS should also ideally provide a rich set of standard reports which can then be easily customised by the content author and /or IT department.
• Administration - The administrators of the system will need to create users (content authors), and grant them access to various parts of the CMS in line with their needs. This should be as granular as possible, to allow access to the system at the lowest levels possible. This should also ideally include the ability to reset passwords, amend the site styling, configure and run any scheduled reports, including a broken links report.
• Maintenance and support - This should include both upgrades and patches. You will need to ensure you have read the support agreement, and are happy with it. What are their hours of business, how can they be contacted, how do you raise an incident with them. Are you happy with the terms of their Service Level Agreement (SLA)? How often can you expect an upgrade, and how is this delivered?
• Data migration - If you have an existing CMS, is the new supplier able to migrate this content into their CMS on your behalf? Are there any additional costs associated with this?

This is far from a full CMS requirements specification, but is aimed to serve as a starting point to hopefully make you consider what you need from your own CMS.