FOUR KEYS TO A SUCCESSFUL CMS IMPLEMENTATION

Typically, a content management implementation is an expensive venture, both in terms of actual costs (for software and services), as well as the amount of time and effort required by your staff to successfully migrate over to a new system. Another not-so-well-known fact is that the majority of CMS implementation projects fail.

In the twenty years that I have been involved in the world of publishing and content management, I have had the “opportunity” to experience many painful issues while trying to help clients move into a production environment.

If you are considering an investment in a content management system, you may want to consider these four keys to success:

1. Pick the right type of CMS to meet your business objectives.

The term “content management” is easily one of the most confusing terms in the industry. There are many different types of systems out there that purport to do “content management,” but are designed for completely different purposes. Before you can select a CMS, you must first ask: “What business problem are we trying to solve?”

Do you want a system to enable the dynamic update of your corporate website? Are you looking to manage your corporate digital assets and marketing or brand information? Are you looking to streamline your editorial and localization process?

Determine your business problem, and then look for solutions that are designed to solve that problem. For example, a Web CMS or Digital Asset Management system will not be well suited to manage an editorial and localization workflow.

A corollary to this rule: if possible, don’t just implement a solution because it is the “corporate approved standard” for content management. You might end up spending more time and money trying to force a system to go beyond the limits of what it was designed for.

2. Always look for a solution that conforms to international standards.

The biggest danger with most traditional software applications is their reliance on a closed, proprietary architecture. If the software you are depending on becomes obsolete, you face a nightmare as you attempt to migrate your proprietary content format into a new system. (Just ask anybody who used Interleaf for electronic publishing in the early 1990s. Or, for that matter, anyone who just tries to stay current between releases of MS-Office!)

Whenever possible, a CMS solution should conform to international standards approved by well-regarded organizational bodies like OASIS and the W3C. This will reduce your reliance on specific tools, making your content the most important thing, and pushing technology applications into the secondary supporting role, where they should be. As a side benefit, this will also prevent “vendor lock-in.” If you decide to switch tools at a later date, migration will be much easier (as long as the new system also conforms to standards).

• Ability to add semantic markup, to increase content intelligence (like better search results).
• Unicode compliance, which ensures support for all target languages.
• Ability to reuse content at the “component” level.
• Facilitation of true single-source publishing to multiple output formats.

3. Keep customizations to a minimum

A typical CMS implementation involves the integration of several types of tools, including authoring, database, workflow, translation, and publishing applications. It is rare that all of these features can be found in one product. Therefore, some level of custom integration and development is usually required in order to fully meet a client’s requirements. To make matters even more complicated, virtually every company feels that their process is highly unique and that a complete CMS implementation must support every aspect of their environment. In my experience, this is a misguided outlook that can lead to problems and unnecessary costly mistakes:

• Integration and customiza- tion can be extremely expensive and can take many months (or even years) to fully implement.
• Heavily customized environ- ments are difficult to support. If you have an integrated environment with a mix of products, it is difficult to troubleshoot and resolve issues. (Application vendors will often blame another application for unexpected behavior. When you have an environment with several products, it is difficult to assign responsibil- ity and get issues resolved.)
• An upgrade to one product might impact other products in the mix. Similarly, a change to one product’s API could affect some of the cus- tom integration code that is necessary to make your envi- ronment work seamlessly.
• Due to the expense and complexity of the environment, there is a high probability that you will be required to maintain the integrated sys- tem well beyond its useful (and even usable) life expectancy.

In addition to the tips I’ve already shared, here are two other suggestions that will help you to achieve the most rapid return on your investment:

• Start with a representative pilot project. Find a subset of your full content suite that suitably represents the challenges of your production cycle, and get that portion implemented quickly into a production-quality pilot environment. This will enable you to quickly demonstrate the benefits of the new system, work out any kinks in the process (before you load all of your legacy data into the system) and get some real value out of the system early. Look for a way to get a production-quality system in place in 90 days or less.
• Consider the “Software as a Service (SaaS)” subscription model as an alternative to software procurement. This is discussed more in the next section, but a typical SaaS solution costs less money, provides all of the required functionality from one vendor, and reduces or eliminates risk, particularly since you usually do not have to pay any license fees until the system is ready for production.

WHAT IS SAAS, AND WHY SHOULD I CARE?

“The on-demand model isn’t about delivering software per se. It’s about delivering the results of successfully using the software.” (Phil Wainewright, zdNet)

The SaaS business model is essentially designed to offer a full-featured solution in a hosted environment. The software application sits in a centralized, secure data center and is served up to end users completely via a browser. Rather than buying and implementing an expensive in-house solution, the customer pays a subscription fee to use licenses on the system. The vendor has to perform to the specifications of a Service Level Agreement (SLA), or there are typically financial penalties to pay. SaaS is gaining acceptance as an alternative business model, led by the popularity of applications like WebEx and Salesforce.com.

Any organization can benefit from a SaaS business model, regardless of their size:

• Small to Midsized Business: SaaS allows access to software that might otherwise be too costly or complex to implement or support.
• Enterprise: SaaS allows departments to avoid having to make large capital expenditures and having to pay for internal support costs. Large corporate environments typically turn to SaaS to support short-term projects, software that will only be used occasionally or by a small number of employees, and for applications that need to be available outside of a firewall to partners, contractors, suppliers, or customers.

HOW DOES A SAAS VENDOR DIFFER FROM A TRADITIONAL SOFTWARE VENDOR?

Traditional CMS vendors typically charge most or all of the purchase price at the time a contract is signed, before the system is even installed. Usually, the customer is responsible for the system deployment (often working with a consulting firm for integration). The vendor charges 18-20 percent annually for software support, and is not accountable for implementation failure—even if the system is never actually used in production!

By contrast, a SaaS vendor is responsible for configuring the environment and delivering a “turn-key” application. License fees to a SaaS vendor do not start until the system is production ready, and there are financial penalties for failure to meet the metrics in the Service Level Agreement.

Many “traditional” CMS vendors are considering (or announcing) that they will now support a “hosted model” as an alternative delivery mechanism. Most of these companies will struggle, however, because they will now be held more accountable for a successful production implementation. Plus, they will have a difficult time waiting for payment. It will also be very hard for these companies to give up their ongoing profitable maintenance revenue. (For example, 45 percent of Oracle’s revenue comes from maintenance!)

EXAMPLE OF A SAAS CMS: DOCZONE.COM™

Our company, DocZone.com, provides the first commercially available XML content management platform available exclusively with the SaaS “on demand” business model. Our customer base spans many industries: utilities, automotive, hardware and software manufacturers, and healthcare solution providers. Here are some examples:

• A European automotive company is using DocZone to facilitate the creation, localization, and automated publishing of their automobile user manuals in up to 30 languages, including bidirectional languages such as Arabic.
• A global healthcare company is implementing DocZone to manage the editorial, localization, and single-source publishing of technical manu- als, web-based training materials, and HTML help from the same set of source content.
• A localization provider is using the DocZone platform to facilitate their translation and content optimization services to their clients, enabling them to pass on significant savings for translation and desktop publishing, which makes them a more competitive player in the localization industry.

SUMMARY

Implementing or upgrading a content management environment is a significant and risky undertaking, and many options are available for consideration. But if you properly define your business needs, stick with solutions that conform to standards, start with a small pilot project, and look for rapid ROI models (such as SaaS), your chances for success will increase dramatically. Choose wisely—the rewards are worth it!

ABOUT THE AUTHOR

Dan Dube has 20 years of experience in business process re-engineering and implementing standards-based content management systems, including three years as the Founder and President of Lighthouse Solutions, an XML systems integration company. He led the successful deployment of approximately fifty XML-based content management and publishing systems around the world in a variety of industries, including telecommunications, legal publishing, aviation, automotive, insurance, and software documentation. He designed and managed the implementation of XML-based automated localization systems that are currently used in production at several Global 2000 companies.