Selecting a CMS: How to Build a Short List

It is easy to see why most companies struggle with the CMS selection process. The market is flooded with hundreds of products and there does not appear to be a "safe", market-leading choice.

Ultimately, you want to select a content management system that supports your requirements and that your users will find usable.  But evaluating CMS software for functionality and usability takes time.  You don't want to waste your time getting intimate with the wrong products, yet battling your way to a reasonable short list is easier said than done. There are some shortcuts, here's how to get started.

Don't Let the High Stakes Paralyze You

The large amount of time and money involved in implementing a CMS and high visibility of most content management initiatives makes the risk of selecting the wrong one downright intimidating.

The result is that companies often find themselves stagnating in an analysis-paralysis cycle — frustrated by their lack of progress but afraid to move forward. Stakeholders start to lose patience re-hashing requirements and wasting their time sitting through demos without knowing what they are looking at.

In my consulting work, it is not uncommon for a new client engage me after more than two failed selection attempts. This article will help you get your CMS selection project off to a good start by focusing on how to build a short list of products that you can then actively evaluate.

Prioritize Vision before Detail

In the absence of any real strategy for selecting a CMS, the tendency is to stick with safe activities like collecting requirements. It feels inclusive to ask people what they want and it doesn't cost anything. And if collecting requirements is a good thing. Collecting more requirements must be an even better thing right? Wrong.

There are diminishing returns in collecting requirements. After a certain point requirements start to get esoteric or minuscule and cost of managing and prioritizing them outweighs their value. Eventually, you will have a specification for a system that is impossible to build because some of the requirements contradict each other. Furthermore, a CMS is usually part of a larger initiative that will alter how you work and invalidate many of your requirements.

Stop collecting requirements after you have enough information to rule out a significant segment of the marketplace. The most powerful filters will address the architecture of the system and characteristics of the product ecosystem. I call these Leading Requirements.

Use the following steps to construct your list of leading requirements:

• Filter for Relevant Technologies.
  Your first filter should be based on the technologies that you are able to support. For example, if your technology infrastructure (assets and people) is based on Microsoft, you can rule out all of the Java based products. If you don't have any technology infrastructure (and don't want one) consider working with a supplier that provides the application as a service (either a SaaS product or a trusted integration partner that will host and maintain the application for you). It doesn't make sense to build new technology competencies just for a CMS.
• Filter for Your Budget.
  The second filter is usually price. Don't waste your time looking at products you can't afford. However, that doesn't necessarily mean that you should rule out products that are well under your budget. In the content management world, more doesn't always mean better. Paying for features that you don't need isn't just wasting money, it can over-complicate the solution and jeopardize usability. Ultimately more can mean far less — especially if it dooms the adoption of your new solution.
• Filter for Business Functionality.
  The third filter is functionality — but not a feature-by-feature level. Think more at the problem domain level and you get groupings of features that have been implemented in such a way as to facilitate a certain type of business operation. For example: lets say your organization wants to migrate to a centrally hosted platform but allow different groups to manage their sites with a high level of autonomy. Each division has its own web developers that should be able to develop presentation templates to achieve a distinct branding and layout. There are a lot of detailed requirements packed in here like "local roles" where a user can have a powerful developer-level role on one of the sub-sites but just be a content contributor or visitor on the other sites. Different CMS products can achieve this functionality in different ways (some more elegant than others). But at this stage of the selection, you just want to know if it has been done and how well it worked out.
• Consider the Proximity of Your Partners.
  Lastly, you should consider the regional presence of the supplier. Believe it or not, the CMS market is still geographically segmented. Unlike operating systems and databases, products that are big in Europe, might not be big in the U.S. Generally, you want to stay away from products that your local talent pool does not know and that have support hours that do not overlap with your business hours. That said, there are a number of European vendors that are making a big push into the U.S. market. If there is a real commitment to your regional market, the vendor might go above and beyond to make you a good local reference. Your local systems integrator may also get additional support to get their partnership off to a good start.

Now that you know what your leading criteria are, you are ready to dive into the marketplace…almost. If you issue your RFP or RFI now, you are likely to get flooded with responses from desperate vendors. You will most likely get confused and distracted by the sales process.

Learn from Real Experience

Prior to jumping into the RFP/RFI process, do some talking with your peers and learn from their experiences. By peer, I mean someone who has completed either a successful or unsuccessful project similar to yours.

Don't just look for recognizable brands.  A well known company using a product for a different purpose is not relevant to you. For example, if you are the digital marketing manager at Ford, it doesn't matter if GM used a product for blogs on their R&D intranet.

When you talk to people look for those who have grappled with the same business problems and try to understand what led to the success or failure of the initiative and the role which the product played. If you're lucky you might also learn some tidbits about who to work with and how to manage your project.

Develop Practical Scenarios

Once you've identified your leading requirements and benefited from some CMS project war tales, you will likely have an idea of what products are being successfully used to solve a business problem that is similar to yours. Hopefully, your short list will now be fewer than 5 products.

The next step is to define CMS usage scenarios. Such scenarios will greatly help you decide which of the short listed products are a reasonable fit. These scenarios will go into your RFP and become the script for your product product demos.

Further, scenarios will help you visualize how your organization might use the product and help you tease out more subjective factors such as interface usability.  If your "short" list still has more than 5 products, use the scenarios to filter down further either by reviewing them with your peers at other companies or with a sales engineer from the products on your list. 

For each of these scenarios, you should be asking "How would this product support this scenario?"  Avoid sending out your RFP to more than 5 companies because you will soon be overwhelmed by boilerplate responses.   

Next Up: Scenarios

If you followed these steps, you should be very close to narrowing in on a manageable set of technologies to evaluate.  In a following article, I will explain the process of writing scenarios that expose the relative strengths, weaknesses, and other characteristics of different content management products. Stay tuned.

About the Author

Seth Gottlieb is the founder and principal of Content Here, an analyst firm and consultancy specializing in content technology selection and strategy. With 15 years of experience in software and professional services, Seth has helped businesses large and small improve the efficiency and effectiveness of their content management and publishing processes. He has been a regular contributor to CMS Watch and is the author of Drupal for Publishers among other critically acclaimed reports.

Related Web CMS Articles

• How They Hack Your Website: Overview of Common Techniques
• Web CMS: Adobe Buys Day Software for US$ 240 Million
• Web Design: Top 5 Wireframing Tools
• Drupal vs Joomla: Which CMS is Best?
• Perspectives: What the Adobe + Day Software Deal Means, Part 1

Job Openings  View all | Post a job | RSS

• UI/UX Designer at Nimble
• Account Associate, Inside Sales - Brand/Agency at Facebook
• Technical Web Analyst at Thomson Reuters
• Project Manage at Wireless Generation
• Technical Writer / Software Development at Omnitec Solutions, Inc
• Online Community & Content Manager at CRC
• Web Designer/User Experience Guru at Fog Creek Software
• Vice President at Emanate

Featured Events  View all | Add event | RSS

• Aug 5, 2010 – Webinar: How Combining Enterprise CMS and BPM Boosts IT Efficiency
• Sep 19, 2010 – Oracle OpenWorld 2010
• Oct 7, 2010 – HartmanEVENT 2010 - Social Media & Mobile Usability