Five Mistakes to Avoid When Buying a CMS

CIDM

October 2006


Five Mistakes to Avoid When Buying a CMS


CIDMIconNewsletter Scott Wolff, WOLFF & Associates

If your business is in the market for a content management system (CMS), it is important to recognize that no two products are alike. With such a wide array of applications to choose from, choosing the best CMS for your business can be a challenging task. Although all CMS applications address storage and version control, products vary considerably regarding the handling of content, content granularity, and the management of structure and content types.

Here are five common mistakes you can avoid when purchasing a content management system.

  • Buying a system without defining your requirements
  • Buying the wrong type of system, one that is not well suited to the level of granularity required by the objectives
  • Buying a system that is too slow for outsourced development or localization
  • Not considering the cost of change management
  • Building instead of buying; buying instead of contracting for a hosted solution
  • Buying a System Without Defining Your Requirements

One of the most important steps is to conduct an upfront analysis to define exactly what your business needs are, as indicated in Figure 1. Too often, businesses approach purchasing a CMS like buying a car; they figure they’ll know it when they see it. The problem is that, unlike a car, content management systems offer a complex feature set that is often not well understood by the buyer at the time of purchase.

To solve this, you need to define what your business goals are and what the customer needs are, and then specify the technology capabilities that will best meet those goals. Your task can include conducting a business analysis to clearly specify what business goals will be supported by investing in CMS technology. An audience analysis defines what segments, languages, and regions, must be served and what is the background of the typical customer. A task analysis can help to define what the customers are trying to accomplish with the information and under what circumstances they refer to this information. Many businesses have been producing information for years without taking time to evaluate the publications being produced. A publication analysis can include usability testing to evaluate if the content is accessible, accurate, and relevant to meeting customer needs. A process analysis is needed to define the current workflow, the roles within the process, and who the users of the system will be. Finally, if you are moving to structured content development, it is worthwhile to conduct a content analysis to start the process of identifying reusable components, document types, and document structure. As you can see, becoming an educated buyer starts with knowing all aspects of your publication needs and processes.

Wolff_Figure1

The next step is mapping out the system requirements based on the analysis you have conducted. Fortunately, most businesses know a great deal about their customers, publications, and business objectives, so this analysis is often a process of summarizing the business knowledge in such a way that it can be shared with IT or professional service providers and vendors.

Buying the Wrong Type of System, One That Is Not Well Suited to the Level of Granularity Required by the Objectives

Content management systems belong to both a class and a pedigree or type. Systems can be low cost, mid market, upper tier, or enterprise level by class but really address very different markets by type. CMS types include records management, web-content management, single sourcing, repurposing, document management, digital-asset management, learning management, and semantic web solutions. Each of these system types addresses a different set of content types with different degrees of structure and varying levels of granularity for the content being managed.

Your company may already have any number of content management systems. You need to ask yourself whether they are adequate for addressing the current business needs. I often hear of Learning Products departments that have requested a CMS project for single sourcing, only to get driven into an existing CMS system their company invested in for other business needs. It is ideal if one system can meet the needs of two different business functions. However, businesses often make the mistake of either buying or using the wrong type of system or the wrong class of system for the task at hand. Figure 2 is a diagram depicting the relationship of content component size “granularity” to the ability of a CMS system to “manage” and “track” information.

Wolff_Figure2

For example, Stellent’s Universal Content Management suite is not optimal for a single-sourcing application where high granular content reuse was required. However, if you were in a large-scale business with hundreds of legacy content types that needed to be published via the web, Stellent is an excellent choice. Systems such as Vasont, XyEnterprise, Trisoft, Ixiasoft, Astoria, Siberlogic, or others are more appropriate choices to satisfy granular requirements for content component reuse.

Even if you choose the right type of solution, if you choose the wrong class of solution, you may still be in for a disappointment. For instance, attempting to create an enterprise-class solution from a mid-market product can prove difficult to impossible, both from a scalability and performance perspective, as well from an integration perspective.

Sometimes CMS buyers feel as though they didn’t get the whole story when they purchased their CMS. More often than not, they are asking questions which are too general about the prospective products. Most vendors will answer a buyer’s questions honestly; more often it is the questions themselves that are simply too general. If you ask a vendor questions such as: “Do you have version control?” or “Does your product support XML?” the answers are more than likely going to be yes. Most CMS sales people can reasonably answer yes to most general questions. Additionally, it is important to delineate what is included for the licensing fee versus what requires customizations at additional. Sure they can do it, but what is it going to cost? To the novice CMS buyer, all the systems can soon appear to be very similar. As a rule, general questions lead to general answers. Being able to differentiate CMS type, class, and granularity will help identify competitive solutions for your business needs.

In my experience, it is not that the CMS is good or bad, only that someone purchased a less than optimal solution for their business or purchased a system with unrealistic expectations for the product’s capabilities, scalability, or configurability. Not understanding the full cost of the system is another potential problem. A product may cost more initially, but, because it is highly configurable, it could prove less expensive for implementation. For example, Vasont ships with over 300 processing options included. These are configurable code options which do a variety of special processing, providing a degree of customization out of the box. Attempting to customize a solution for tasks it is not well suited for can drive the cost up significantly.

Buying a System That is Too Slow for Outsourced Development or Localization

It is important to consider the impacts of performance with CMS technology. The more granular the systems, the more pieces and parts the system must manage and manipulate. The more granular the system, the more imperative it is to test the system for performance characteristics. There are a number of factors that should be considered when addressing the performance of a CMS.

For development systems, consider

  • the volume of components and content
  • the remote access of the CMS
  • the number of simultaneous users accessing the components

As each of these factors increase, you can expect the performance to degrade proportionally to some degree. Here the key is testing. Create meaningful test data that demonstrates the use case scenario effectively, including multiple users, multiple offices, multiple regions, multiple languages, large amounts of content, and large documents sizes. How content is passed and what content is passed can affect system latency and therefore system acceptance by content developers and end users alike.

With low-cost systems, it simply isn’t practical for vendors to conduct elaborate pilots to test the system performance extensively. Consider a trial period for the purchase instead so that you have a chance to work with the system before committing to a purchase. For systems in excess of $100,000, it is worth conducting a feasibility test of the system’s performance. For such tests, it is common for the vendor to charge for professional services associated with system configuration and testing.

Remote outsourcing is an increasing prevalent means used to develop content, along with translation and localization activities which often occur in other locales. Understanding the ability of a solution to perform well for remote users can be a critical aspect for success. In all cases, when possible, testing should simulate real use-case scenarios. If you have an office in India or China that must access the CMS, be sure to experiment with having a writer or translator access the system from that remote location. The key is to test, test, and test! It is preferable to identify performance issues before purchasing.

Not Considering the Cost of Change Management

With all the costs associated with purchasing the right CMS, it is quite easy to overlook other expenses associated with managing your information. In addition to the license fees to cover users and servers for development, staging, and production, you should consider the cost for customization, maintenance, legacy content porting, and future upgrades. Have you thought through how your business paradigm might change? In most cases, a CMS offers a business a chance to rethink old processes and roles. The analysis you do early on can pay dividends as the volume and tempo of change increases with the introduction of a new technology.

If you are starting from scratch without any legacy content, you will be free to implement the ideal system from the start. But, if your business has years and years of content that now needs to be captured in the new CMS, you could be facing a large expense for converting formats, recasting navigation, and changing from unstructured to structured information. Depending upon your circumstances, you may be required to republish the information entirely in one pass as a hard system roll. Careful planning should be exercised. In addition to budgeting for content conversion, consider contingency plans for overall risk reduction during initial publication. If your business depends upon these publications, proceed with caution. Schedule overruns and performance issues, as well, as general change management for training, new roles, and new process steps can take you through several publication release cycles before all the kinks are worked out.

Building Instead of Buying; Buying Instead of Contracting for a Hosted Solution

Many organizations soon realize that they cannot buy a system off the shelf that will meet their every desire. They have a few hot shot programmers in house who say that for the money involved, they can just build the system exactly the way they need it. Before considering such an option, recognize that CMS systems are quite a challenge to create. If your programmer’s experience doesn’t include working for a CMS vendor in the past, you should be hesitant. The problem is one of sheer complexity. Correctly managing reuse, for example, entails managing multiple versions of content related to multiple deliverables, being managed by multiple writers, and undergoing multiple workflow instances simultaneously. As a rule, it is usually more effective, cheaper, and faster to purchase a CMS than it is to build one from scratch.

Still not convinced? First, consider that most content management systems take years to stabilize their architecture, based upon the input and working experience with many customers. Second, when buying a CMS, you are, in effect, sharing the development expense with many other customers. Third, bug fixes are a fact of life with complex systems; if you built it, you fix it, instead of just deploying the patch or the next version.

There are a number of open-source solutions making great inroads in the market place, such as Plone. In most cases, even though there is an established development community, these systems tend to be for the do-it-yourselfers. If you go the open-source route, contract with the qualified support needed to maintain a business-critical system. Going to Yahoo Groups late at night with a question to the community is a bit like shouting from your roof top that your house is on fire; you hope someone responds, but you don’t know until they do.

If the first rule is buy before you build, the second rule is host before you buy. Of course, your business requirements in both cases will dictate what makes the most sense. But, as a rule, it is less costly to contract with someone to host your content on a CMS server. There are several good reasons why. First, if you buy a system, you have a physical server and a staging server to test new releases of the CMS in your environment and an IT organization to field calls about system issues, hung connections, performance issues, etc. Depending on the scale of the solution, this could be anywhere from one person to an entire IT team. Second, if the CMS is hosted for you, installation is a non-issue, as is optimizing the configuration. The hosting provider, or the Software as a Service (SaaS), manages those aspects for you. There are several good examples of host providers, including DocZone.com, Crown Peak, and Hot Banana. Perhaps the best reason to use a hosted solution is the same reason people usually give for not using a hosted solution. It takes the system out of the hands of the business. With hosted solutions, the expectation for “having it my way” is greatly reduced, and, therefore, the cost and degree of customization is also reduced. Hosted solutions sometimes boast they can have a system up and running in 30 days. Compare this with six months to two years with purchased systems and two years to five years with custom-built solutions. Be creative and look for ways that reduce your cost as you approach a CMS solution.

In summary, if your business is going to invest in a CMS, do the upfront analysis needed to correctly specify your CMS requirements. If you don’t have experience with a CMS, seek help in specifying and selecting one. Consider both the class and type of CMS required. Whenever possible, test the performance characteristics of the CMS under the actual load and with realistic scenarios based upon use cases defined in part by your system requirements. Recognize that introducing a CMS is often a tremendous change to your business which requires planning, budgeting, and training, as well as change management for the people impacted. And finally, look for ways to simplify your requirements so that you can buy or even contract for a hosted solution. CIDMIconNewsletter

About the Author

IMG_8515 final

Scott Wolff
Principal
WOLFF & Associates
scott@scottwolff.com

Scott Wolff is principal of WOLFF & Associates, a consulting company providing expertise in publishing and content management. Previously, Scott worked for 17 years with Hewlett-Packard Company, where he introduced an extensive single-sourcing strategy for centrally managing, automating, and outsourcing publications development and localization and led initiatives to standardize all of HP’s technical publications. As an engineer for HP, Scott Wolff managed production teams, technical publications teams, and outsourcing, and developed software. Scott received his degree in Industrial Engineering from Rochester Institute of Technology and two Master’s degrees in Engineering and Computer Science.