<!-- Content Here -->

How to Select a CMS

A while back, I wrote a post on selecting a CMS. I have since gotten requests for more step by step instructions. While, the process is not so formulaic that it can be written into a recipe, this is the Content Here approach. This methodology is optimized for the complex content management projects. Some of the steps require a deep background in the content management marketplace or help from an expert. But here they are.

1. Document the content types. Before doing anything, you need to know about the content that is to be managed: its structure, frequency of creation and updates, and who is responsible for it. Usually, this is a good time to visualize better ways of structuring, organizing, and managing content assets.

2. Document the scenarios. Write short, narrative-based scenarios describing what the system will be used for and how. Stay away from implementation specific details as much as possible. For example, rather than say "the user clicks a 'check spelling' button and the system lists misspelled words," say "the system notifies the user of misspelled words." This leaves it open to the product to determine the best way to meet the requirement - is it with color underlining as the user types?

3. Document the legacy systems. Most Content Here clients require integration with legacy systems. It is important to understand them, how they are deployed, and their interfaces. A diagram showing the existing enterprise architecture and how the content management platform fits in is very helpful.

4. Filter by technology. While content management is all about usability, start by developing a short list of products that are technically capable of meeting the requirements. The biggest reason for doing this is that evaluating for usability is such a subjective and intensive process and it is impractical for both the customer (and the vendor) to demo more than a couple of products (you will see this later on). You might have some non-functional constraints like the system has to be customized in Java or run on Windows. To do this step effectively, you really need to be immersed in the marketplace and know the different products and who is using them for what. Buy a CMS Watch report (WCM or ECM) or hire a consultant (like Content Here) or, better yet, do both. Based on the questions that I get, I think that sites like CMS Matrix are more likely to confuse you than help you.

5. Filter by price. If a product is way beyond your price range, you should either filter it out or see if there alternative licensing models that meet your budget.

6. Engage with the vendors. If you have been following the steps 1 through 5, you should understand your content management requirements and have a short list of 3 or so products that would all probably work in your environment. The next step is to find the product that your users will feel the most comfortable using. Hopefully, the software vendor understands your needs and will partner with you to meet them. If two products are very close functionally, I tend to go with the vendor that will be more helpful in the initial implementation and beyond. This is where I think the traditional RFP process is broken. Rather than create a formal procurement process that tries to compare "apples to apples," you want an informal, interactive process that will highlight the differences between the vendors and their approaches. You want to share as much information with them as you can. If you don't trust a vendor, they should not be on your short list.

7. Prototype and learn. Because each vendor on your short list has a good chance of winning the deal, and you are not giving him a 100 page RFP to answer, he should be willing to invest the time to build a prototype that will demonstrate how his product will support your content types and usage scenarios. If an open source product is on your short list, consider building your own prototype or paying a systems integrator to do it (this will give you an idea of what it is like to work with the systems integrator). You should evaluate the prototype as actively as you can. Ask what can be changed and how. Ask the vendor to give you access to the prototype so that users can play with it at their own desks. Have your users think outside of their normal day to day and be innovative. Teach them about best practices in content management.Hopefully, the prototype demonstration was like a training session so the business users are comfortable finding their way around the system. If you intend to have your technical staff help with the implementation and/or maintenance of the system, now is a good time to request the developer documentation and access to the customer support site. Schedule a technical session where the prototype builder walks through the code and configuration that he did to build the prototype.

8. Project what an implementation would look like. To get an idea of the total cost of the solution, do a project planning exercise of what it would take to implement the solution and customizations and migrate your content. You will be better off if you plan for an iterative deployment where the first release supports the bare essentials and subsequent releases layer in more functionality. This is especially the case when your users are new to content management or have been using a limited toolset. They will learn so much about their needs from the first release and have wonderful ideas for improving and extending the system.

There you have it. Eight easy steps to select a CMS.