Specifying and implementing web content management software

Many organizations are now considering using a web content management software (CMS) product to facilitate the effective management of web sites and intranets. With many hundreds of open source and commercial CMS products to choose from the process of establishing requirements and selecting the best product for the long term can be both complex and risky. The implementation itself also needs to be managed with care, especially where there is a considerable volume of legacy content to be migrated to the new system. This paper provides an introduction to the benefits and challenges of content management software. It emphasizes that it may take a year from the time that the decision to assess the requirements for a CMS is taken to a full and effective deployment.The costs of implementation are also outlined, as these are invariably significantly greater than the CMS licence cost.

The way in which an organization presents its products and services is now very largely influenced by the way in which these are presented through its web site. This is the case whether it is a publisher setting out a range of journals, or a library providing services to customers. In many cases the library site is also an element of an intranet, and so may have to present a different face to external and internal audiences. The majority of web sites are still built using page authoring software such as Microsoft Front Page or Macromedia Dreamweaver and in many cases these products can provide very user-friendly web experiences.
However, the publishing and business environments are now subject to rapid change. Publishers continue to acquire new titles and other publishers. In the business environment, new departments and sources of information result in the need to revise the information architecture of the web site or intranet on a regular basis. This is where the apparently low-cost investment of using page authoring software to compile static web sites inevitably causes problems in modifying text, links and graphics across a substantial, and often unknown, number of pages.
In the case of intranets there is an additional problem as organizations realize that using the webmaster approach of a small team of specialists adding content to the site just does not scale.
Content is not added quickly enough and the site soon loses the 100% trust of employees that it is essential for an intranet to maintain. Of course, in theory every appropriate member of staff could be given access to, and training on, Front Page (as an example), but often staff only publish on an occasional basis, and so have to go through a relearning cycle just to put up the quarterly sales report. This is neither effective nor efficient.
Over the last couple of years there has been increasing interest in using content management software to provide a more flexible site authoring environment, and in this article the basic features of content management are set out.

CMS and CMS
An initial problem is that the expression 'CMS' is used in two different ways. CMS can stand for both 'content management software' and 'content management system'. A content management system enables content to be managed on a lifecycle basis, supporting its creation, re-use and presentation. Content management software is, in effect, specialized database software that supports a content management system. It is possible to have a content management system without content management software, and just having installed content management software does not

MARTIN WHITE
Managing Director Intranet Focus Ltd mean that the organization has a content management system. Confused? You are not alone!
The key features of content management software are ■ content creation through templates, which requires no technical expertise ■ content review supported by work-flow ■ content versioning closely managed ■ content tagged and held in a repository ■ content repurposed for delivery to specific audiences ■ site design framework independent of content structure ■ comprehensive administration functions.
It is worth looking at each of these in sequence.
The objective of using templates is to enable employees to contribute content without any need to be familiar with page authoring software. It also enables the site manager to ensure that standards for page presentation are maintained, and that appropriate metadata is added in a consistent manner. The concept of work flow is very familiar to publishers and to libraries. The use of work flow in a CMS is to enable content to be reviewed prior to publication, but all too often this can be taken to extremes. Just because work flow is provided does not mean to say that every content process has to be handled in this way. Indeed the default should be that there is no work-flow process used unless there is a clear value added to the user of the site.
In a CMS, every time that a piece of content is checked out of the system and even the smallest change is made (perhaps to Anglicize a word) then a new version will be created. This can be very valuable in ensuring that content changes are tracked. However, a long document that is being developed by a number of authors can quickly build up a very long list of versions, and identifying intermediate versions can be difficult.
Behind every CMS is a database, though most CMS vendors refer to it as a repository. Each piece of content is individually tagged and databased for re-use. This is an appropriate place to note just one of the differences between a document management system and a content management system. In a document management system the emphasis is on maintaining the integrity of the entire document. A content management system will break the document up into individual sections, images, tables, logos, etc. and in effect hold a virtual version of the document which can either be rebuilt on demand, or individual elements re-used in other documents.
Most CMS products require the organization to have a suitable database environment, such as SQLServer, Oracle, mySQL or similar. The problem often arises that although the organization does have SQLServer licences, there are not enough such licences to support a CMS. This is just one of the many hidden costs of implementing a CMS.
It is at this stage that metadata management becomes important. There is no point in fragmenting a document into individual content components if there is insufficient information to identify them and re-use them. Without a consistent and thorough metadata scheme the investment in a CMS will be wasted. The proposed implementation of a CMS is usually the first time an organization has had to face the need to develop a metadata scheme. The basic building blocks are those in the Dublin Core Metadata set, but there is also a specialized scheme, PRISM, for the publishing industry.
CMS software will be able to repurpose content automatically to take into account different styles and formats used in a web environment. In general there is an emphasis in CMS selection on content contribution, and not enough on working through how publishing will be managed.
One important attribute of a CMS is that the content and the design can be divorced from each other. Although much can be accomplished with cascading style sheets (CSS) in terms of creating new designs and layouts for a web site, the options within a CMS are usually more powerful. However, attention needs to be paid right at the outset to information architecture issues. This is because each CMS will need to be customized during the implementation, and although changes are possible later it is rarely as easy as the CMS vendor will probably suggest.
Most CMS products provide an almost endless array of administration capabilities. These are especially valuable in a decentralized content contribution situation so that reports can be produced about content that has not been updated, or to highlight content from a specific contributor, who has left the organization for example, enabling it to be allocated to another employee. Other important aspects of the administration capabilities are the management of document security and the ability to design new templates.

Technology options for a CMS
There are four CMS options. The first is for the organization to build its own CMS or to ask their web agency to do so. In theory this often looks like the low-cost option, but in practice it is easy to end up with a solution that meets current requirements but cannot be developed in the future without significant additional development costs. When a commercial CMS vendor funds product enhancements the cost can be spread across much of the current client base as well as new customers.
There has been a lot of recent interest in using open source software to build web sites and intranets. The software is either free or can be downloaded for a nominal fee. In many cases this is a good option, but only where the organization has the relevant development skills as in general this software is rather poorly documented and certainly not supported other than through informal discussion threads.
The number of commercial CMS vendors continues to grow each month, and there are probably around 300 or more at present, though a small number (perhaps ten) account for perhaps 50% of all the current installed base. CMS products are complex application suites, and are really a set of tools that need extensive customization. The higher the price the higher the degree of functionality (usually) and the more the product needs to be customized to meet the needs of an organization.
Another option is to purchase a portal application. However, a portal is really only a desktop presentation of content from a wide range of databases and other sources, and usually has only a very basic level of content contribution functionality.
The final point to consider is the value of a search engine. Many web sites have only limited search functionality and even large intranets often fail to implement a search engine of sufficient utility. Many content management solutions come with search software included, but this is often only there to assist a content contributor to locate content for re-use, and not to provide searching across the site. When a search engine module is included it may well be a 'light' version without some of the more sophisticated features.
One of the questions that is yet to be resolved in practice is the extent to which an 'enterprise' solution is either possible or desirable. In other words, can any one CMS solution meet the needs of a graphics-rich web site with e-commerce applications, an intranet and an extranet? At first glance the appeal of reducing development costs and licence fees may seem attractive but in fact the level of customization needed for each application, and the potential risks of the entire project getting behind schedule through unforeseen implementation issues are powerful arguments for not considering this approach at present. The current alternative is to buy 'best-of-breed' solutions for the web site and the intranet, and glue them together with the effective use of XML and an integrated approach to metadata.

Implementing a CMS
The implementation of a CMS is a major task for any organization. Even if only a few content contributors are involved any failure to meet expectation will be visible to every customer and every employee. The majority of IT departments are unfamiliar with this type of software, and so have little experience on which to base decisions.
Without doubt it is essential that a very clear requirements document is prepared, which sets out the business requirements and is not just a list of functions derived from a book or web site. This document should also form the basis for the selection of the vendor, even if just open-source software is being considered.
A typical time-scale for CMS implementation is along the following lines: Month 0 Start of the selection process Month 2 Completion of invitation to tender Month 3 Responses received and an initial selection carried out Month 4 Detailed discussions with the shortlisted vendors Month 5 Decision made on a preferred vendor It may be possible to reduce the time a little, but only by a month or so -which means that if you are now reading this paper and you decide that there are merits in implementing a CMS then you will not have the CMS in full operation until 2005! The schedule becomes a lot longer if the organization needs to go to a full public procurement, for example in the Official Journal of the EU. Add four months.
There are four important implementation issues that need to be considered at the outset. The first of these is that there is a considerable variation in the way that a vendor prices a CMS. It could be per seat, per site, per server, per module, indeed per just about anything. A commercial vendor will also be charging 'standard' licence support fees of 20% of the base licence cost. In addition there will be the cost of the consultancy to carry out the customization of the CMS. These products are specialized, and quite proprietary, so there are very few freelance consultants available for hire. As a very rough rule of thumb the additional costs over and above the basic software licence are likely to be at least as much again, and can easily be three or four times as great. This means that if the organization has allocated £300,000 for the CMS implementation, then it will only be able to afford to buy products with a licence cost of under £100,000.
The second problem is that of migrating legacy content to the new CMS. This is not straightforward, and it may be necessary to 'touch' each page, convert the look and feel and also add appropriate metadata. Assuming that each page of a 10,000-page site or intranet takes just two minutes to move into the new format, this still represents around two person-months of effort. In reality the time taken is much longer, and it is not a process that is at all easy to automate.
CMS implementation is a sufficiently complex project that it cannot be carried out by the current webmaster and team without risking a very serious impact on the quality of the existing site. Additional staff may have to be recruited and trained, and yet may not be needed once the CMS is implemented. It is the cost of additional staff during the implementation phase that adds considerably to the overall cost of the CMS project.
Finally, the implementation of a CMS will result in a change of culture, especially if the CMS is used to decentralize content contribution in an intranet. An issue here is that staff will be asked to contribute to the intranet, but their managers may not be aware of how much time and effort is involved, even with template-driven contribution. Too many intranets are run on a 'hobby' basis, and it is very important that web contribution roles are included in job descriptions and evaluations from the outset.

In conclusion
This paper sets out only some of the basic elements of content management software and systems. Implementing a CMS, either for a web site or an intranet, is a major project with a lot of hidden costs. The benefits can be substantial in being able to enhance communications with customers, prospects and employees, but these benefits only arise when there are very clear objectives, expectations are balanced by resources, and the true scale of the implementation of a CMS is fully understood.