The Secret to Managing a Content Management System Deployment

There's a great line in The Producers (the 1968 Mel Brooks film) where Max Bialystock says, "I'm condemned by a society that demands success when all I can offer is failure!" I know firsthand that for many managers, confronted with deploying a new Web content management system (CMS), that sentiment is very true.

The challenge is that it's a Catch-22. For any Web content management project to succeed, the stakeholders (contributors) need to adopt and embrace the new system. However, these same stakeholders are, many times, simply uninterested in learning anything new or changing the way they perform their current jobs. It becomes the challenge of the CMS project manager to overcome that issue and not only roll out a successful new software tool, but a new workflow process as well.

Failure to overcome this challenge can be the death knell of the project. Failures to achieve adoption by the stakeholders can sometimes cause the organization to forfeit all of the benefits that a Web CMS typically affords. Stakeholders who grow frustrated with the system will simply ask for additional resources to support the new processes. This is exemplified when organizations add an additional resource to publish content or to support an unwieldy software implementation and basically turn the CMS into a very expensive FTP client. Content contributors then run back into their Microsoft Outlook holes and send out their content updates as they did before. And, at worst, this can lead to a complete avoidance of the CMS to update the site - transforming the software into nothing more than a series of large files taking up space on the server.

To be successful, the assigned project manager must not only take steps to make sure the right software solution is chosen but more importantly, ensure that the content contributors and key stakeholders are invested in the success of both the launch and the ongoing management of the CMS.

Remember, the number-one goal of a Web CMS is to empower the nontechnical business users to publish to the Web site. Every other feature that you are grilling vendors about, including workflow, versioning, publishing, search engine optimization and digital asset management, comes along for the ride. If users don't adopt the system, the other features are useless.

So, while this isn't a comprehensive list, here are the top three things that nontechnical project managers can do to ensure success in the deployment of a new CMS.

1. Communicate; feel their pain. We've all heard the cliche of the project built by committee - somewhere there's a camel and the original design for a horse. But don't forget the Wisdom of Crowds (great book by James Surowiecki). The first thing the project manager should assemble is a community of contributors that will be utilizing the new CMS. Create a series of forums about what's broken with the current process and how the new process should work.

Once these forums have been established, consider developing an official document that will explain the project and its desired outcome in detail. This project definition will be your requirements document as you gather all of the desired outcomes and new capabilities and start to map them against a set of features, functions and services that you'll require from your chosen solution. Many larger organizations choose to outsource the project definition phase to consultants with either vertical expertise and/or previous CMS implementation experience.

In general, the goal of this project definition is to outline:

The scope of the project: What this project will entail (which divisions, which Web sites).
The business goals of the project: What you will achieve from a business point of view and how you will measure the success of the project.
The key deliverables: Is there a new Web site and a new CMS, or just a CMS, or other functional items?
Key assumptions being made: What key assumptions need to be made and dependencies outlined in order to satisfy the above deliverables.
Key people involved: The key people and their role on the project.
Functional business requirements of the project: These are the key benefits not specific features (e.g., "easier to manage content and publish to the Web," not "XHTML compliant output").
Functional technical requirements of the project: Keep these high level for now, but capture any critical items (e.g., must be Microsoft based, or must be able to scale separate of Web traffic).

2. Usability - more than just a pretty interface. As you are selecting a tool to deploy, it's helpful to remember the number-one goal again. If you don't provide your users with a usable tool - then all of the other features are useless.

That said, usability is much more than just an easy way to cut and paste from Microsoft Word into a "what you see is what you get" editor. Savvy project managers will pay attention to flexibility of the system, realizing that it contributes to overall usability.

Workflow and collaboration. How does the system handle workflow, and is it intuitive for users? Does your organization work with a "task"-based type of workflow, a more nonlinear-based workflow or something highly structured with complex legal review? How does the tool facilitate collaboration as content is moving through a workflow? Is it intuitive? Is it easy?
Flexibility for users. To put it in the estimable words of Star Trek's Spock, how does the system handle the needs of the many versus the needs of the few or the one? If you have users with only one particular task on a repetitive basis, can you limit their interface to just that task? Can you name your own workflow steps, so that they make sense to you and avoid having to learn an artificial "application" language.