Content management systems - getting it right

• an ever-expanding growth in electronic communications across multiple media 
• the recognition that content is critical to basic business operations 
• regulatory requirements to provide an audit trail and ability to recover particular versions of documents 
• economies of scale and operational efficiencies resulting from everyone using the same systems 
• ability to provide greater control over the presentation of content, particularly for business brand identity.

• Integration of the editorial and publishing process across an organisation 
• Streamlining of the workflow of the content lifecycle: capture > create >manage >deliver > maintain (expire/archive) 
• Distinction between different content types and templates 
• Audit trails and version control 
• Online business process automation 
• Administrative tools for workflow, security, archiving, etc.

• Planning & Design: needs analysis, vendor selection, capacity planning, etc 
• Implementation: project management, system configuration, user interface design, integrating other applications, documentation 
• Operations: business recovery/contingency planning, systems and asset management 
• Training: technical, user and information science (content classification, information architecture, metadata/indexing, search engine performance) – although readers of this magazine are suitably qualified to dispense with the need to pay for such services (indeed we could sell to the consultants!) 
• Support: telephone, email, onsite and preventive maintenance.

* * * *

Stages of a CMS 

• Specification 
• Product development (less of a task
• these days) 
• Implementation/Deployment 
• Support maintenance 
• Development/update

• Be clear that you actually need a content management system. While a CMS will improve the delivery/retrieval of content across an organisation it will not improve the quality of the content on a website – that’s an editorial and writing issue (any complex website will need a managing editor – which a CMS is no substitute for) 
• Think long term: secure senior management support and understanding of this commitment 
• Avoid the word ‘project’. It implies it’s a one-off event and that no future funding will be required for maintenance, continuing development and support – content management is a process 
• Decide what scale of CMS is required. Single site? Business? Enterprise scale? 
• Carefully consider information architecture, metadata (whether automated or manual) and a taxonomy (a third party taxonomy, common XML schemas or your own custom-created taxonomy) 
• Ensure that you comply with legislation (e.g. data protection), security and regulatory obligations 
• Detail your required specifications and conduct a vendor ‘beauty parade’– IT research firm Forrester produces a useful checklist of questions to ask3 
• Realise the decision-making process will be longer due to the very nature of what’s involved. You will need stakeholders from at least the major departments in your organisation, so allow sufficient time for this if working to a deadline 
• Don’t forget a Digital Asset Management library.

Some of the typical problems that arise with the deployment of a content management system include:

• It wasn’t needed in the first place (doesn’t apply if you’re thinking on an enterprise/organisation-wide scale) 

• It was seen as a one-off ‘project’ with no planned development 
• It was driven solely by IT 
• Change management was not sufficiently considered 
• Content staff fail to specify requirements clearly, e.g. a flexible, detailed editorial calendar function, iterative, rather than straight-line editorial workflows, etc 
• There are poor internal communications. IT developers and content generators and writers wail they are ‘from different planets’. (Except of course they aren’t. As a feminist postcard goes, ‘Men are from earth – so are women – Deal with it!’) 
• It was ‘built in a bubble’ – the configuration of the CMS developed was not aligned with your business strategy.

• Establish support processes for deployment, operations/use and technical troubleshooting – each will generate different types of enquiries which need to be routed appropriately 
• Train users according to their preferred learning style – whether its one-to-one or as part of a group. There will always be a spectrum of ability in any large group of people 
• Develop thorough documentation – there should be separate manuals for general CM users and more sophisticated CM administrators. Good documentation can reduce support costs by addressing queries at the point of source. Occasionally highlight certain topics/aspects of your CM tool in your communications 
• Specify standards and guidelines (e.g. web style guide)
• Ensure you are using every available channel of internal communication and that your messages are consistent across these. Communication also needs to be regular 
• Work with early adopters. Certain departments (or more accurately the personalities within those departments) will recognise the benefits to be gained by adopting the ECM. They will help generate internal ‘success stories’ that can be used to win over more recalcitrant departments. One size does not fit all, so be flexible in your approach to deploying the ECM system to different departments or communities 
• Involve users and stakeholders in the process. This can operate on a variety of levels, ranging from a web form to submit enhancement or development requests, to general conference calls to discuss ideas and issues more broadly. Adopt an ‘account management’ approach to important groups.