Recommended steps when outlining a CMS strategy

Regular

posted 21 Feb 2005 in Volume 1 Issue 7

Recommended steps when outlining a CMS strategy

Selecting a content-management system will impact a wide range of business processes and information systems. For this reason, the procurement of a CMS has to take place within a strategic context, and based on as rigorous a business case as possible.

1) Organisation objectives

The business objectives of the organisation for the next two to three years should be set out, including key success factors. Even if the decision to implement a CMS is taken immediately the business case is accepted, it will almost certainly take 9-12 months to fully implement a CMS in most organisations of any size. It is therefore important that the CMS business case reflects, as far as possible, the business requirements at least two years ahead to avoid the danger that some short-term problem is identified as the critical success factor, but by the time the CMS is implemented this problem has been solved.

2) Information requirements

Those information requirements that will have a specific impact on meeting the business objectives should be set out, together with the associated business processes/workflows. This section of your strategy should include both information generated from within the organisation, and information arising external to the organisation. Differentiation should be made between explicit (documented) information and implicit (the knowledge of staff) information.

3) User segmentation

Each organisation has many user segments, such as:

Research/administration;
HQ/subsidiary;
Language and culture differences;
Staff working remote from an office;
Customers and suppliers.

The main user segments, their size and information requirements should be summarised. It is important to identify important flows of information between the main user groups and/or between departments. One of the problems with many intranets is that they end up as stores of documents, and do not facilitate the transfer of information.

Often a department ends up having to do a lot of re-purposing work on a document from another department to ensure that it can be used effectively. I came across a case where a finance department sent out financial reports to project managers as neat PDF files generated from Excel spreadsheets, which the project managers then used to enter data into their Excel spreadsheets. Changing the file format to Excel saved all concerned not only a considerable amount of time but also ensured that there were no errors in the information held at project level.

4) Information-technology infrastructure

This section needs to be in an understandable text format, and not making unconsidered use of the IT architecture charts so beloved by IT managers. This section can easily get too long in proportion to the rest of the document, so setting out a standard of no more than half a page for each subheading is still generous.

The topics that need to be covered are:

Information systems architecture;
Local and wide-area networks;
Operating systems;
Database environment;
Storage environment;
Portal implementation;
Desktop environment;
E-mail and other messaging;
Web environment (intranet/extranet/website);
Current and future browser-based applications;
Standards;
Outsourcing policy;
Training and support;
Disaster recovery;
Network security.

Anticipated changes to the IT infrastructure over the next two to three years should be summarised.

5) Systems integration

Requirements for integration of document and content-management applications with current and planned systems and applications should be set out. These would typically include:

E-mail and other network applications;
Personnel systems (excluding payroll);
Enterprise-resource planning systems;
Enterprise-information portal systems;
Records-management systems.

The integration requirements should be stated in terms of information exchange, and not in technical terms at this stage.

6) Capital and operating budgets

The basis for the establishment, monitoring and review of capital and operating budgets that might have an effect on the procurement of the CMS should be set out. There have been situations where there has been budget allocated to the purchase of software but no allocation for the professional services required to implement the CMS. Committed versus discretionary spending should be identified, as sometimes apparent budget flexibility is in fact constrained by the need to upgrade a core system. One of the issues with CMS implementation is that the costs may well extend over one budget year, and yet there is often no way that spending in the following year can be authorised at the time the decision to purchase the CMS is made.

7) Document analysis

In this section a broad quantification of the document environment should be set out. This will include (for example):

Simple versus compound documents;
Sequential versus collaborative authorship;
Document volumes (by above categories);
Rate of change of these volumes;
Typical lifecycles;
Quality management and review.

The timing of specific events (such as an AGM or a major conference) should be set out, and the short-term impact on document types and volumes assessed. In the process of implementation, much more work will be needed on document types, but even at this stage some sense of the scale of document diversity and volumes is essential.

8) Document creation

This section should set out in more detail the way in which documents are currently created, covering (for example):

How documents are created;
How many people typically are involved in document creation, review and production;
How often documents are updated;
The extent of this updating;
Existing workflows, which may be implicit rather than documented;
Extent to which documents are used across business processes, and what (if any) repurposing is carried out.

9) External document management

Many documents will be received by the organisation in printed, written or other formats (video, audio etc). Other examples include third-party translation of documents. The range of formats should be set out, and the level of integration with internal documents should be analysed. One of the benefits of a document-management system can be the management of external documents where there is a need to collate comments and respond to the external agency concerned.

10) Document publishing

All too often with content-management systems the emphasis is on content contribution, and content publishing is not reviewed in sufficient detail. Because some CMS products are better at content contribution than content publishing, understanding the publishing requirements is an important consideration in the selection process.

Documents can be published through a number of channels, including (for example):

Posted to an intranet or extranet;
Posted to a website;
Published in a printed format;
Published on CD-Rom/DVD;
Circulated in a paper format;
Added to a database for internal and external access;
Accessed through mobile devices.

The current and anticipated future balance between these (and other channels) should be considered. For example, the implementation of a customer-management system may result in documents relating to specific customers or projects being published through this system.

11) Security and confidentiality

Documents that should not be accessible to groups of staff within the organisation should be identified, together with reasons for the security requirements, and the circumstances under which these restrictions will be lifted (eg, after a specific period of time). Building a security model for document management needs considerable care at the outset of the implementation, and changing it subsequently can be difficult.

12) Metadata standards and taxonomies

At this stage the aim is to understand the current situation and likely requirements, such as:

Extent of current metadata schema;
Conformance to Dublin Core and other metadata standards (eg, e-government);
Status of taxonomies and classifications;
Procedures for updating and revising metadata and taxonomies;
Use of computer-based methods for taxonomy creation;
Organisational skills to create and maintain metadata schemes.

13) Search

I have commented above on the concentration on content contribution at the expense of content publishing, and the same is true of content search.

The problem is made even worse by the uniformed view that ‘All we need is Google’. Certainly Google is a very good search site, but the enterprise version is a rather different product. It may be very difficult to gain an idea of how users will search for information, especially if there is no current search facility on an intranet, but even basic level information will be valuable, as it may help to understand the scale of the search problem. A search engine can also be a valuable content integrator across a number of different content servers, and in this connection understanding search requirements is essential.

The main types of search that need to be carried out on document/content repositories should be discussed, including:

Approaches to relevance ranking;
Document content presentation;
Personalisation of the results.

The focus should be on how the results should be presented, rather than how the search itself will be carried out. From an understanding of the outputs an indication can be gained of the level of metadata tagging that needs to be applied in order to facilitate this type of output. For example, if a user wants to see the description of a document displayed then the description has to have a field of its own and be tagged accordingly.

14) Records management

Relevant records-management standards and guidelines should be set out, and the extent to which the organisation has to meet national or other records retention and management standards should be highlighted. Of course, for public-sector bodies in the UK, FOI and data protection requirements should also be included.

15) Governance

This section should set out the organisational structures for managing information flows, including the setting of standards for document and records management. Organisations with registration under ISO 9000 for quality management may find that they have to be re-certified in order to take account of the way in which documents are managed in a CMS.

16) Staff resources and training

The staff skills and expertise required to implement the content-management strategy should be considered, including training needs, and the extent to which content-related tasks should be included in job descriptions and evaluations. It can be useful to plot content contributors on a grid (see figure 1).

The aim of this grid is to start to identify the training requirements. Staff with poor content knowledge may be support staff in a department that is presented with documents and asked to add them to the system.

17) Business case

The basis on which a business case could be made for the adoption of a content-management system should be set out.

This could be based on, for example:

Improved productivity;
Speed of adding material to an intranet;
Providing audit trails for decisions.

It is important to identify groups of staff that will see early benefits from the adoption of a content-management system. At this stage the business plan is in outline only, but it is still worth capturing the key issues.

18) Risk analysis

The risks to the organisation of implementing a CMS solution might include:

Resistance to changes in business practice;
Disruption to current business;
Unforeseen costs;
Increased levels of IT support;
No apparent benefits to staff.

19) Implementation issues

This section should identify some of the possible implementation problems that have arisen from the research. These might be:

Heavily over-committed staff in key departments;
Lack of management vision;
Budgets based on current year only;
Lack of technical skills in an IT department.

20) Glossary

It can be helpful to include a glossary of key terms used in the strategic plan, particularly any technical terms that may be unfamiliar to some readers.

Implementing a CMS

There are quite a number of issues that need to be considered in implementing a CMS solution. The first of these is process change. If the CMS is going to make a significant difference to the organisation then a business process may have to change to take advantage of the technology. There are three ways of managing the process change.

Change the process before the CMS implementation so that staff are used to the new procedures before having to cope with the CMS interfaces;
Change the process at the same time as implementing the CMS, on the basis that there is going to be serious disruption in any case so a little more will not make much difference;
Implement the CMS and then change the business process.

Usually the options are not quite as clear as those, but in principle I would favour the first route. Staff are able to stay within a comfortable technology environment while coping with the process change, (which could be just the adoption of Word style sheets to ease content contribution into the CMS) and so then only have to deal with a technology change. If the templates and work flow have been well designed, the transition should be fairly smooth.

The ‘all change approach’ may be the only option in some circumstances, perhaps as a result of time pressure. Probably the least satisfactory route is the third option, because ideally the CMS should have been set up for the new business process, so learning how to use the CMS interface, and then having to re-learn the process at a later date may give rise to some problems of adaptation.

All the way through the implementation process the key issue has to be managing expectations. In a large CMS project I was involved in, four departments were due to be the initial roll-out targets, but the word got out that the CMS was now in place, and all sorts of special claims were being made for ‘Why them – why not us?’. Any implementation needs to have a marketing and communications strategy that sets out quite clearly what is going to happen and when. In general it is best to keep the news to what has been agreed and what has actually happened, and not to get too clever about forecasting implementation dates for the next 12 months to the nearest day.

The CMS will be to the greater good of the organisation, but staff will largely see it only in terms of the impact on them personally. All managers involved in the implementation need to agree how training is going to be managed (and financed) and how requests for changes in job descriptions and salaries are going to be handled. With so many staff-related issues to consider it is advisable to have a member of the HR department on the implementation steering group.

The membership of the steering group needs to be carefully considered, and may well be different from the group that was involved with the development of the SoR and the selection of the vendor. There should be a stronger representation of business users rather than IT specialists, but the group should be kept to a manageable size. Groups that number seven or more tend to present more management difficulties than they solve. An important consideration is that members of the group should be able to take executive action. There is no time to waste if the implementation process is to go smoothly and to budget, and if group members have to go off and consult every time a decision has to be made then the whole process will quickly get bogged down in procedure.