HOT TOPICS: Customer Experience Marketing Automation Social Business SharePoint 2013 Document Management Big Data Mobile DAM

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.


Continue reading this article:

Useful article?
  Email It      

Tags: , , , , ,



Featured Events  View All Events | Add Your Event | feed Events RSS