It is easy to see why most companies struggle with the CMS selection process.Themarket is flooded with hundreds of products and there does not appear tobe 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 listis 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 moneyinvolved in implementing a CMS and high visibility of most content management initiativesmakes the risk of selecting the wrong one downright intimidating.

Theresult is that companies often find themselves stagnating in ananalysis-paralysis cycle -- frustrated by their lack of progress butafraid to move forward.Stakeholders start to lose patience re-hashingrequirements and wasting their time sitting through demos withoutknowing what they are looking at.

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

Prioritize Vision before Detail

In the absence of any real strategyfor selecting a CMS, the tendency is to stick with safe activities likecollecting requirements. It feels inclusive to ask people what they wantand it doesn't cost anything.And if collecting requirements is a goodthing.Collecting morerequirements must be an even better thing right?Wrong.

Thereare diminishing returns in collecting requirements.After a certainpoint requirements start to get esoteric or minuscule and cost ofmanaging and prioritizing them outweighs their value.Eventually, youwill have a specification for a system that is impossible to buildbecause some of the requirements contradict each other.Furthermore, aCMS is usually part of a larger initiative that will alter how you workand invalidate many of your requirements.

Stop collectingrequirements after you have enough information to rule out a significantsegment of the marketplace.The most powerful filters will address thearchitecture of the system and characteristics of the productecosystem. I call these Leading Requirements.

Use the followingsteps to construct your list of leading requirements:

  • Filter for Relevant Technologies.
    Your firstfilter should be based on the technologies that you are able to support. For example, if your technology infrastructure (assets and people) isbased on Microsoft, you can rule out all of the Java based products.Ifyou don't have any technology infrastructure (and don't want one)consider working with a supplier that provides the application as aservice (either a SaaS product or a trusted integration partner thatwill host and maintain the application for you).It doesn't make senseto build new technology competencies just for a CMS.
  • Filter for Your Budget.
    The second filter isusually price.Don't waste your time looking at products you can'tafford.However, that doesn't necessarily mean that you should rule outproducts that are well under your budget.In the content managementworld, more doesn't always mean better. Paying for features that youdon't need isn't just wasting money, it can over-complicate thesolution and jeopardize usability. Ultimately more can mean far less -- especially if itdooms the adoption of your new solution.
  • Filter for Business Functionality.
    Thethird filter is functionality — but not a feature-by-feature level.Thinkmore at the problem domain level and you get groupings of features thathave been implemented in such a way as to facilitate a certain type ofbusiness operation.For example: lets say your organization wants tomigrate to a centrally hosted platform but allow different groups tomanage their sites with a high level of autonomy.Each division has itsown web developers that should be able to develop presentationtemplates to achieve a distinct branding and layout.There are a lot ofdetailed requirements packed in here like "local roles" where a usercan have a powerful developer-level role on one of the sub-sites but just be a contentcontributor or visitor on the other sites.Different CMS products canachieve this functionality in different ways (some more elegant thanothers).But at this stage of the selection, you just want to know ifit 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 itor not, the CMS market is still geographically segmented.Unlikeoperating systems and databases, products that are big in Europe, mightnot be big in the U.S.Generally, you want to stay away from productsthat your local talent pool does not know and that have support hours thatdo not overlap with your business hours.That said, there are a numberof 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 mightgo above and beyond to make you a good local reference.Your localsystems integrator may also get additional support to get their partnershipoff to a good start.

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

Learn fromReal Experience

Prior to jumping into the RFP/RFIprocess, do some talking with your peers and learn from theirexperiences.By peer, I mean someone who has completed either asuccessful or unsuccessful project similar to yours.

Learning Opportunities

Don't just look for recognizable brands. A well known company using a product for a differentpurpose is not relevant to you.For example, if you are the digitalmarketing manager at Ford, it doesn't matter if GM used a product forblogs 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 whatled 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 andhow to manage your project.

Develop Practical Scenarios

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

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

Further, scenarios will help you visualize how your organizationmight use the product and help you tease out more subjective factorssuch 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.