In London this past April, the state funeral for Queen Elizabeth, the Queen Mother, was held. In the space of a week, all the complex arrangements were made, even resurfacing the road outside of Westminster Abbey to remove the very visible road markings. Everything went as planned, to the minute. The secret, of course, was in the preparation. For over 20 years, a plan for the funeral was updated at regular intervals and similar plans are in place (with code names such as Forth Bridge) for all the senior members of our Royal Family.

Organizations planning to implement a content management system should take heed of the benefit of forward planning. Over the last year, many of my firm's consulting projects have been to assist organizations in the selection of a content management system (CMS). Some already have a CMS for their Web site, and feel confident in using this experience, and CMS vendor, to deploy an enterprise CMS solution. Others may have a document management system, and see benefits in using this system to manage Web content. The majority have no formal document or content management system, but have read of the importance of such a system. All are now setting out on the path to

Setting Out the Objectives
I've seen quite a number of CMS RFPs, most of which are set out in a checklist format as a way of evaluating vendors. That is an important step, but does not in itself guarantee that the CMS will be delivered on time, on budget, and will meet expectations. This is because the RFP is written in terms of functionality rather than function. Current CMS applications have more than enough power to handle the most complex of content management processes, but how many organizations have worked through the workflows behind document preparation, and (of even greater importance) identified where there could be benefits in re-engineering the workflow to gain the maximum benefit from the CMS application?

Workflow management lies at the heart of a good CMS implementation. The workflow sets out authorities to publish, authorities to modify, authorities to view and authorities to archive or discard. From this will come a substantial amount of essential metadata development. Often organizations think that they have such procedures, but they tend to be flexible, with the organization almost self-adjusting to the resignation of a member of staff or a departmental restructuring. That is very difficult to engineer in workflow software terms, especially when two or more workflows have to meet in the middle, such as the preparation of an annual report, where financial, business, legal, and marketing content all having to arrive at the correct time and place for publication. If you are not yet familiar with the benefits and challenges of workflow design it can be a salutary lesson to use Microsoft Vision (which also forms the workflow module of many CMS applications) to formalize the creation of a document.

A Four-Phase Project Plan
Apart from setting out the RFP in functionality terms, the other error that organizations make is not setting a realistic schedule for procurement and implementation. There are at a minimum three main phases of the project, and posssibly four. The first of these is the underlying research on the type of documents and content that need to be managed, the availability or otherwise of taxonomies and other classification tools, the extent to which a CMS will need to integrate with an ERP or HR system, or a records management system, and the development of key workflows. This work is likely to take at least three months in any reasonable-sized organization.

Next is the preparation of the RFP itself and the selection of a vendor. As mentioned, the RFP needs to be written in terms of deliverables, preferably with some degree of performance objectives. "We wish to be able to produce the papers for the board within one month, instead of two, and reduce the staff resources allocated by 20%." That implies that you know the staff resources involved, and can then be used in the RFP as a criterion for the review of the performance of the CMS in due course. Then comes the dispatch of the RFP, deciphering vendor and/or systems integrator responses, meeting with vendors and other members of the project team, and then negotiating the contract. If you are able to do that in less than three months, you have not taken enough care.

Phase three is the initial implementation. The implementation schedule set out in the tender will likely be reviewed during the process of the successful vendor preparing an initial Statement of Work. This is the time when both the vendor and the organization discover a lack of quantification and clarity in the content management procedures currently in place, without even moving on to proposed changes. As a result, the time that the quotation, which is always subject to due diligence, gets revised by the vendor, and a fresh round of financial requests have to be made by the project manager. Another outcome is that the original project schedule starts to look increasingly optimistic. I advise clients to write absolute dates into the RFP and contract. If it is important to have the Annual Meeting papers prepared using the new system, then this should be formally stated in the RFP. This focuses the minds of both vendor and organization to a remarkable degree, especially if the date is then written in the board minutes.

Almost certainly you will benefit from creating a Critical Path Analysis for the initial implementation, so that even before the contracts are signed, the fact that IT are also implementing an ERP system is taken into account when assessing staff resources. Training staff is also often overlooked. It is not just a question of multiplying the number of staff by the number of days training required. The sequence in which staff are trained is often very important, and can have internal political implications if Department A gets trained before Department B, which regards itself as much more important to the organization.

Phase four, which I will only mention briefly, is the steps beyond implementation, when new functionalities are introduced or regional offices are linked into the system. Once the initial enthusiasm is over, the project team is disbanded and the momentum can easily be lost. Looking again at the overall schedule, the initial implementation will almost certainly take at least three months, regardless of vendor claims.

Project Management
The summary of all this is that the overall process, from deciding on a CMS to the end of the initial (probably partial) implementation will probably take from nine to twelve months. There are some important implications. The first is to manage everyone's expectations—from the chief executive to the departmental secretary. This is not out-of-the-box software, and because of the visibility of the content approval process, there may be some difficult cultural and office politics issues to be addressed.

Second, a CMS is probably the most complex rollout you and your IT colleagues are likely to have to manage. The entire process needs to be treated as a formal project from beginning to end, with clearly-documented procedures for gaining sign-off on activities and for raising issues that could impact the implementation schedule and the achievement of objectives. A project manager needs to be appointed with clear terms of reference and the authority to make things happen. There has to be an adroit balance between a team environment to ensure that all issues are addressed in each phase.

The third implication is that there needs to be excellent communication about the project, the benefits that will result, the challenges that the organization will face, and the potential disruption that may be caused to the organization and to individuals. Consider making a section of your intranet a forum for conveying project progress and also for gaining feedback on the process.

The final implication is that people will change and the business will change in the course of the specification, procurement, and implementation. The worst possible outcome could be a CMS that meets every requirement that was set out in an RFP dated June 2002, but at best, only some of the requirements of the organization in December 2003.