"Content management" is joining "knowledge management" and "information architecture" as a concept that everyone knows exactly what it is—until the time comes to set out a definition in writing. Then the arm waving has to stop. A working definition for the purpose of this article (which is not actually about content management software) is that content management software (CMS) provides a platform for managing the creation, review, filing, updating, distribution, and storage of structured and unstructured content. One of the attributes of such a platform is that it enables all these functions to be carried out in a design- and format-independent way, with no fixed relationships between any two items of content.

Web managers have used content management software for several years, especially when there is a need to manage complex B2B and B2C sites. Vendors such as Vignette, Broadvision, Interwoven, and Open Text have dominated this market. The Webmasters who use these systems are dedicated to the task of Web site maintenance. Through regular use they remain familiar with the vast range of functionality offered by such systems. Acquiring these systems can usually be accomplished with little reference to the rest of the enterprise, unlike a systems integration project, which tends to be driven by back-office financial and logistics systems.

INTRANETS AND EXTRANETS

The focus today is on intranets and extranets. Here the situation is rather different. Except in very large organizations, intranet content management is more widely distributed, and if there is central control on publication, it tends to be for final approval rather than any substantial design and format work. Managing multiple contributors, often in different departments and physical locations, is beginning to cause substantial problems for intranet managers working with Dreamweaver, Front Page, and GoLive on a page-by-page basis. There is also the realization that content reliability has to be of the highest possible level in an intranet. Recently Dell posted on its site an incorrect lower price for a monitor, but could get out of selling at that price because of some small print on the order form. Try putting up the incorrect vacation policy on an intranet and, when staff complain, telling them that everything is published on an Errors and Omissions Excepted basis!

Organizations with business-critical intranets are increasingly looking for a solution to content management for an intranet. There are a number of options, including building your own around an Oracle or SQL database, using Internet-based ASP solutions from companies such as Atomz and Intranets.com, or purchasing server-based systems. These systems can either be packaged products or open-source products that need substantial programming. The basic principles and functionality of content management systems and the preparation of a specification that can be sent out potential vendors have been well documented. See, particularly, Bob Boiko's Content Management Bible,published by Hungry Minds Inc., New York [www.metatorial.com], and Content Management Requirements Toolkit, Step Two Designs Pty Ltd., Sydney, Australia [www.steptwo.com.au]. Less advice on what to do once the responses have been received exists. In this article, I outline the process from vendor selection to successful implementation, based on projects that I have been involved with in Europe and the U.S.

VENDOR SELECTION

The implementation process begins even before the vendor selection. The specification for the CMS should include the optimum roll-out approach, with key dates and implementation success criteria. The entire process, from specification development to implementation, needs to be handled along formal project management lines. From the outset, there needs to be a Project Board that will undertake the vendor evaluation. This Project Board should also have overall responsibility for the implementation, otherwise all the knowledge gained—and decisions made—during the vendor selection could well be lost.

The Project Board should consist of perhaps no more than five managers who have the most to gain from the CMS implementation, and therefore a keen interest in the project. Almost certainly there should be representation from IT and from Personnel/Human Resources. Whether or not they will be directly affected by the CMS, there will certainly be IT issues, and the changes to staff roles and responsibilities will also need to be considered.

COMPARING APPROACHES

Once an initial short list of perhaps four to six vendors has been developed, the first problem is comparing the approaches from these vendors, even if the specification has been written (against current good practice) in a "check-this-box" format. This is the point at which a weighted ranking
of the vendors pays dividends. The process involves getting the Project Board to agree on perhaps six to eight selection criteria. These could be the use of XML, the approach to migration of legacy content, and the ease with which templates can be modified. Mandatory criteria will be budget and the confidence the vendor has in meeting the implementation dates. The relative importance of these criteria is then weighted on a scale of 1 to 4 (4 being mandatory). As each vendor comes in to make their pitch, the Board then give them a ranking of 1 (no idea) to 5 (meet the requirement completely). Multiplying and summing the ranking and weighting scores produce an overall score for the vendor.

It is important not to place too much faith in the final score. The benefits of this approach are in the discussions around the initial selection criteria and the allocation of the weighting and ranking scores. The process should ensure that all (or at least most) hidden agendas are revealed, and that perhaps one of the criteria needs to be split into two. In a public procurement situation, the scoring is a useful audit trail to show that due diligence has been carried out.

The sales pitch from the vendor needs to be managed with care. Set out in advance what the structure of the presentation should be, what elements need to be covered, and perhaps what the criteria are for selection. This is not the time for another demonstration of the software—that should have been carried out before the vendor even reached the short list.

What you should be looking for is the way that the vendor communicates their understanding of your requirements and how these requirements will be met, as well as the way in which the vendor team members deal with questions from the Board. One of the selection criteria can usefully be "feel"—do you feel comfortable with the vendor team? One member of this team should be the potential project manager should you select the vendor. Gaining an early indication of their communication skills and relevant experience can be invaluable.

SCOPING STUDY

Most vendors will want to carry out what is often referred to as a Scoping Study. The aim of this study is to assess the risks of the project, so that a formal quotation can be made. At the selection stage most vendors will not want to go firm on the price. There are two main reasons. The first is that many vendors have a per-seat pricing model that makes nuclear physics look like K-12 mathematics. At this stage of the selection process, it is unlikely that either the organization or the vendor has a firm enough grasp of current and future requirements. The second reason is that there is always a need for consulting work to adapt even "out-of-the-box" products to the customer environment. This consulting work could easily be double the license fee.

Another important outcome of the Scoping Study will be the implementation schedule. Vendors claim that they can install the software and get the intranet running in 4-6 weeks. This claim should be verified by talking to some reference sites. Try to ensure that you see reference sites that are close to your own organizational environment, even if it means traveling some distance. Try also to keep the vendor's sales staff at a distance. The reality will almost certainly be rather different, as much depends on how much work needs to be undertaken by the organization, especially in developing metadata and workflows.

As well as benefiting from the detailed report, the process of preparing the report can indicate potential issues in project management, understanding of business requirements, and, above all, the culture of the organization. The consultants will be probing into areas that probably no one has probed before. This can be very unsettling, especially for staff concerned about having to learn new software and procedures.

TO PAY OR NOT TO PAY

Some vendors will charge for the study; others will do it on a pro bono basis. If there is a payment to be made, the finance department will require some convincing, as in the end you may decide not to proceed with that vendor. The vendor will take the view that there is important information in the report that has a value to the organization even if the vendor is not selected.

Many vendors will not undertake the implementation themselves, but work through a local systems integrator. Here the selection process needs to be even more thorough, as you not only need to assess the software and the capability of the integrator to deliver, but also gain a picture of the relationship between the vendor and the integrator. Some integrators will have agreements with more than one vendor, and it may have been some time since they worked with your vendor of choice.

PROJECT MANAGEMENT

A CMS is probably the most complex rollout an organization will manage. Even a change to the desktop IT environment is less of a challenge. Indeed, only organizations that have implemented an ERP system are likely to have had any related experience. 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. The Project Managers need a specific set of skills, including excellent communication and negotiating skills, and the uncommon ability to balance attention to detail with a long-term vision of what has to be achieved. The obvious choice will usually be the intranet manager, but will they have the time to manage the CMS implementation and still attend to the daily content of the current intranet? [Editor's note: See Gretchen Tuchel's article on pp. 36-40 stating the case for information professionals' involvement in intranet projects.]

The Project Manager must have full authority to make whatever decisions are required to keep the objectives, schedule, and resources in balance. In reality, this can be difficult to achieve in an organization, but at a minimum, Project Managers should have a written statement that sets out their authority and to which manager they should go to should they need to make a decision beyond the scope of this authority.

None of these variables—objectives, schedule, and resources—can be changed without reviewing the impact on the others. The most frequent mistake made in project management is to set objectives without understanding scheduling and resource requirements. Changing the objectives as the project proceeds is equally egregious.

Successful projects need both a Project Sponsor and a Project Board. The Project Sponsor should have the seniority and scope to be able to understand, and where appropriate, implement, changes to the project plan recommended by the Project Manager. However, the Project Sponsor has not only to support the Project Manager, but also represent the Project Board.

DOCUMENTATION

Without a consistent approach to project documentation, tracking the project against objectives, schedules, and resources is impossible. The emphasis should be on regular short reports that are circulated to agreed upon members of staff. These reports should highlight the input that is required from readers and the deadline for response. Some care needs to be taken to ensure that e-mails are adequately tracked.

Without careful management, problem resolution (sometimes referred to as a red flag issue) can be a nightmare. A procedure must be established for highlighting problems as they arise, including a timescale for agreeing on who is going to take the actions to resolve the dispute. This is especially important when a systems integrator is involved. From the outset it needs to be recognized that the integrator is responsible for managing the vendor. The moment three parties get involved, with the customer contacting the vendor directly over a problem, chaos will result.

ROLL-OUT SCHEDULE

For even a small organization, the roll-out schedule may not be easy to set out and adhere to. For a CMS to be effective, current business processes may require revision to take advantage of the functionality of the CMS. Someone must decide on whether the process will be changed prior to the implementation, during the implementation, or left until everyone is familiar with the system. Among the factors to be taken into account are the impact of this particular process on other business processes, the ability of the staff concerned to cope with two different systems at the same time, and the risk to the organization if unforeseen problems arise in the transition.

The American Productivity and Quality Center [www.aqpc.org] surveyed various companies' roll-out deployment approaches and published the results as "Managing Content and Knowledge." Approaches included a phased implementation by functionality, a phased implementation by department/location, and an all-at-once enterprise approach. The survey indicated that there was no one dominant implementation strategy.

Much will depend on two key groups of staff. The first is the IT department, which will almost certainly have other projects in hand, will probably be unfamiliar with content management software in general, and will not have heard of the vendor. The second group consists of people who, through the implementation of the CMS, will have the most visible impact on the organization. If some immediate benefits are seen (quicker posting of internal vacancies and meeting details, for example), then all concerned will feel that the effort and expenditure are worth the investment. Individual staff members may also have an impact on the implementation. A department manager might be relocated to another site for a period just as the department concerned is looking to their manager for encouragement and guidance.

COMMUNICATIONS AND TRAINING

These roll-out issues lead to the need to have an internal communications strategy. The CMS will have an impact on every staff member, even if they are not directly involved with content creation. They will be expecting the intranet to change dramatically for the better overnight. The main objective of the communications strategy is to manage the expectations of all the stakeholders, ranging from content authors up to the CEO. The more open the Project Team is with outlining the progress of the implementation, responding to concerns and suggestions, the greater the chance of the implementation being a success.

Training programs also need careful planning. Usually CMS vendors do not want to get into the large-scale training business, and once the systems administrators have been trained, they will want to pass responsibility to the organization. There are two training requirements. One is for training in the functionality of the CMS; the other in how the business process concerned may have to change. The IT department will probably have the skills for the former, but the business change issue is much more complex and delicate, which is why having HR representation on the Project Board from the outset is vital. Job descriptions and staff evaluation criteria may have to change.

MAKE, BUY, ADAPT

The issues raised in this article are largely the same whether the decision is to buy packaged software, build internally, adapt open-source software, or use an ASP solution. This is why the total cost of implementation is not significantly different among the four options, as the costs are in the time and effort that need to be expended in the implementation of the CMS. I am not against using open-source software with a minimal or 0 license cost, but the programming still has to be done and the rollout managed. Some organizations may be able to bury the people costs, but increasingly, organizations are looking carefully at total cost of ownership.

The benefits of a CMS are as much due to the entire process of specification, procurement, and implementation as they are the actual functionality of the CMS software. From the time the specification for the CMS has been prepared to the date of full implementation could easily be 9 months. If the CMS does not deliver, then career-threatening questions will be asked. The risk to the organization of having to start the process all over again, while still working with an inadequate implementation, is too terrible to contemplate.

Martin White [Martin.white@intranetfocus.com] is Managing Director, Intranet Focus Ltd., and a regular columnist for EContent magazine.

Comments? E-mail letters to the editor to marydee@xmission.com.