CMS A TO Z

Many companies and individuals are daunted by their search for the perfect CMS. They commonly make the search into a much bigger ordeal than it needs to be, often spending too much time evaluating the options, and not enough time launching their new site.

In my experience, thre are a few common mistakes that tend to bloat the process and slow the decision-making to a crawl.

If you are in the middle of this kind of process, perhaps it's time to take a moment, take a breath, and take some advice from someone who has been there.

#1 - Not Knowing What Will Actually Be Managed

Many times, groups will begin the search process without really understanding what they are going to be managing. Of course the standard page content needs to be managed, but what else?

• Do you need to manage pdf documents? What do you need to do with them?
• Do you need to manage member or client data? How?
• Do you need manage products? What about them?
• Who will manage the site? What level of expertise do they have?
• How often will the site be updated? Which parts will be updated?

In other words, why do you need a CMS in the first place? What business problem are you trying to solve, or what business process are you trying to make easier?

#2 - Overly Simple Criteria

Here is a common list of criteria we see in RFPs related to a content management system:

• Allow us to update our content via the web
• Allow us to upload photos into a photo gallery
• Allow us to mage our

Turns out that nearly ANY cms will allow you to do these things. This set of criteria will lead to literally hundreds, perhaps thousands of options.

Instead, the criteria should focus on things that will truly differentiate the available options, and will allow you to at least rule some of them out.

Instead, the criteria should be focused again on your specific business problem or businss process. And the criteria should be less generic and more specific to the people who will actually be using the system.

• Our customers will be logging into this system to download templates that will be stored in PDF and Word formats. We will need a way to allow these customers to create an account and then download the documents they need.
• Mark and Jennifer will be maintaining the list of documents. They are familiar with online forms, but do not have any experience with writing HTML. They will need a way to upload the documents in PDF and Word format and organize them according to which types of customers will need them.

These kind of criteria allow you to verify that the functionality provided by a specific CMS will satisfy the needs of the actual users instead of fullfilling some laudry list of generic functional requirements.

#3 - Overly Complex Criteria

On the other hand, it's not such a good idea to create such a specific list of criteria, that you rule out ALL cms options.

We have also seen RFPs that stretch on for pages of bulleted functional requirements with no distinction between them about how important each "requirement" is.

Here again, you run the risk of getting something that technically meets the requirements, but doesn't meet your needs.

Your best bet is to focus on the primary business requirements and the actual users.

If you are submitting the RFP to a number of vendors, it may be a good idea to limit the requirements to the absolutely required pieces. IF you make your list too long, then you will likely miss out on submissions from companies who are a better fit to solve your problems (at a better price), but might not have all 500 of the features that you have listed.