Product Selection
5 Biggest Mistakes in CMS Selection
by Lisa Welchman
26-Jan-2003 --
So you're in the market for a Web content management system.
You've combed the Web for information, gone to CMS vendor Web sites and downloaded some white papers, been flabbergasted at the number of vendors claiming to have Web CMS solutions, and perhaps gone to a few conferences.
Maybe you've even let a few vendors visit and give you product demonstrations and formerly propose their solution. If so, then you've probably weathered CMS sticker shock syndrome as well; and subsequently gone through the exercise of convincing your organization's purse string holders that a CMS will, beyond a shadow of a doubt, provide a meaningfully large return on investment. Then after all this, it dawns on you: you've really got to figure which CMS will work best for your organization.
Despite the best of intentions of the wisest Web site technical guru's, content developers and user interface experts, there are still several things that frequently can (and do) go wrong during a CMS product selection cycle.
Some Stories from the Trenches
In helping organizations select CMS packages for the past few years, I've seen more than a few snafus.
I once worked with a Fortune 500 company that had three separate initiatives to purchase a CMS that would support "the entire organization." Coincidentally, two of them called me seeking CMS selection consulting services -- and then a small amount of probing revealed the third team.
And then there was the county government that wanted help finding a CMS that would support their very interactive, sophisticated Web presence. Their only hard requirement was that it must cost less than $5K (including training and implementation).
Another organization wanted a content management system that would "webify" their fairly long-winded product marketing materials. The hope was that the CMS, would somehow transform their print-based materials into Web-friendly content.
Hopefully these anecdotes have left you chuckling. If not, perhaps you need to read more about what I consider to be the five biggest mistakes made during a CMS product selection. And, even if you were giggling a little, it couldn't hurt to take a look.
1. Letting a software vendor tell you what you need
This first mistake may seem simplistic but time and time again CMS shoppers begin their product selection process by sitting in product demonstrations and webinars or by reviewing vendor-produced product white papers and case studies. While this information can be helpful later in the selection process, it is useful to understand your organization's CMS needs prior to and independently of any vendors input.
Vendor sales and marketing staff are more than happy to define your problems for you. This is not because they are inherently manipulative people. Rather, defining a prospect's problem so that your product will solve it is in fact just "Sales 101." Many vendors will helpfully provide prospective clients with definitions, documents, and ROI calculators that will facilitate the drafting and justification of a CMS requirements document. There is certainly some value in past experience here; however, the methodology, data, and approaches will reflect experience solely with that vendor's product.
While it may be tempting to use these tools (because who has time to write a requirements document?), you are better off creating your own or soliciting vendor-neutral advice for assistance in this process. In the long run, this will actually save you time.
2. Not establishing a broad-based selection team
This may be the biggest mistake made in the selection of a Web content management system. Many times Web CMS product selection teams are formed in a casual manner, without actual implementation in mind. One typical situation is that either the content team or the Web site technical team manages the selection process independently without consulting their partner team -- or, more commonly, there is an imbalance between the two groups.
In all cases, a CMS procurement is a content and technical, cross-functional exercise. Both teams need to be included from the initial requirements definition phase going forward. If the content team is excluded early on, then requirements tend to be based solely upon the needs of the technical team. Generally speaking, user interface and workflow issues are minimized. If the technical team is excluded early on than the needs of the users are reflected and the technical requirements get put in the trunk. In both of these cases, the CMS implementation has a much higher probability of failing due to lack of support or out right rejection by the team whose needs were ignored.
Diversity on the product selection team does not just mean content and technical users. Consider also the broad range of stakeholders who will be affected by the CMS software deployment and include them early on. This should include representation from various lines of business, and functional agencies or groups within your organization, such as your finance and HR offices. It might be faster or easier to select the software without participation from all of these various constituents, but with exclusion, you run the risk of buying a piece of software that doesn't meet everyone's needs, or worse, having the CMS stakeholders not properly invested in making sure that the software deployment is successful.
3. Not understanding the total cost of ownership
CMS software packages can cost a lot of money. But, the software is only the half of it (or in many cases the quarter of it). There are service and support packages, training and implementation costs associated with CMS software deployments.
Professional service fees account for more than 50% of revenue for some CMS vendors. For others, that figure may be closer to 20%. While a lower professional services (and training and support) costs do not necessarily point to a more cost-effective solution, it is important to consider how these costs will play out in the first, 2nd and subsequent years of your organization's software ownership. Many buyers find themselves paying similar or greater amounts for professional services in Years 2 and 3 than they did in Year 1.
There are also the human resource costs within your own organization to consider. How independent will you be (or do you want to be) after the software is deployed? If you have a fairly large technical team with a broad skill set perhaps you already have the internal personnel at hand to support, customize and upgrade the system once it is deployed. If you have a smaller tech team, you may have to utilize the professional services of your CMS vendor. This can be costly, but doing it yourself may not be cheap either, even if the real expense is hidden in other line items (like some other department's staff).
How often will you have to train your personnel? Are there e-learning packages at reasonable costs or does everyone have to take a three-day offsite course in a major metropolitan area (read, expensive) in order to use even the simplest features of the CMS software?
What kind of service and support package do you need and how is it priced? Most vendors price their support as a percentage of first year costs. These costs can increase as your site/user base grows.
4. Not thinking strategically about content management.
Probably, there is a pressing reason(s) why you need a CMS. It is easy to focus on these reasons and these reasons only when evaluating software. It is important though to consider what you will need the CMS to support in the future. Do you have plans to syndicate content? Maybe you know that there is a goal to include e-commerce functionality to your site within a year. Perhaps part of your organization's strategy includes frequent mergers or acquisitions (and therefore requires a CMS that scales easily and offers a sound methodology for repository aggregation).
Make sure that you define known (and some speculative) future requirements as part of the requirements gathering process. Otherwise you may find yourself out shopping for a replacement CMS well before you've gotten the return on investment out of the first.
5. Not understanding the parameters of Web content management
What's the difference between Web content management, document management, asset management, and knowledge management? Many vendors blend a potpourri of related solutions into a murky indecipherable brew that they claim can solve any and all of your organizations problems. This is highly unlikely. If, upon hearing the phrase "Enterprise Content Management (ECM)," you experience an overwhelming urge to run for the hills, then I would say you possess sound instincts and bring a high aptitude to the challenge ahead of you.
It is true that some content management systems do address more than one information-management problem, but most excel in one, or maybe two, core competencies. A basic step in the selection process, then, is understanding which of the truly core competencies underneath any given product suite represents the most important functionality for your organization.
Finally, a Web CMS won't write better content, develop better taxonomies, or cure painful systems integration problems. There are separate exercises that can and should take place prior to and independently of the CMS product selection. When relevant, exercises in content analysis, metadata taxonomy development, and hardware / software infrastructure analysis can help clarify what type of content management tool will be required in your Web infrastructure.
Hopefully you'll avoid these mistakes when selecting your content management system. Industry veterans will point out that many of these tenets are valid regardless of the type of software you are choosing. There is some truth to this (although CMS can be unique in the breadth of enterprise stakeholders involved), so don't be afraid to ask for help from those within your organization who have software selection experience, as well outside consultants when appropriate. Good luck and let me know how it goes.