Selecting a web CMS: The most common mistakes in RFPs

From my archive - originally published on 27 January 2010

I've seen a lot of Request For Proposal (RFP) documents for CMS projects over the last couple of years. Often they can be difficult to respond to in any meaningful way. The following is a review of the most common mistakes...

Too many requirements

This is probably the most common mistake of all. When writing an RFP it's very easy to get into the mind-set of not wanting to leave anything out. This can lead to a bloated list of requirements that does not work as a means of distinguishing between different CMS vendors and suppliers.

This kind of requirements bloat can act as a red herring in the selection process as you are not focussing on what you really need.  It can lead to the selection of larger, more expensive platforms in an attempt to meet every single requirement in the list, rather than a cheaper, more focussed alternative that meets your core requirements.

Prioritisation is key for any requirements list. No platform will meet every single requirement exactly. The trick is to determine which requirements are the most important and spend time seeking to understand exactly how can be met by each platform.

Any CMS selection exercise will involve basic, canonical requirements, such as "must run on Windows 2003 Server". However, it's important to look at requirements gathering in terms of identifying selection criteria and seek to understand the criteria that are genuinely important to you. 

Requirements that are too generic or vague

Not only does a generic requirement imply that you don't fully understand the requirements yourself but it  encourages generic and uninformative  responses.

Consider the following requirement:

"The CMS must integrate with back-office systems."

Which back-office systems, exactly? What processes does this have to support? This requirement is far too vague to be of any use as pretty much every CMS out there provides for some kind of back-office integration.

Simply asking whether or not a requirement can be met will not help you to distinguish between different CMS suppliers. This style of  "check-list" requirements will elicit a similar style of responses - i.e. generic and unhelpful. Most CMS providers have developed a stock response to these kind of generic requirements that addresses them on some basic level.

The trick is to ask "how" a platform meets a requirement. Using a narrative style of requirement writing will help to provide context and requirements should be backed up with some use-case information explaining the background behind them. This will help to elicit a similar response, where providers will supply a description of how they will meet the requirement rather than a plain statement of compliance.

Solely focusing on functional requirements

Some RFPs get so lost in huge functional lists that they miss some of the the wider, more intangible issues in  CMS platform selection including:

  • How well are the vendors performing financially? Are they likely to go bust in the near future?
  • Is there a large pool of developers for the platform, or will you be tied in to a small number of suppliers?
  • How does the platform fit with the development skills and platforms in your organisation?

It's also worth considering some "awkward" questions - e.g. "What is this platform not appropriate for?". They do at least force the vendor to think about the response rather than reaching for the boiler-plate response.

Failing to understand the problem

Most people who select a web CMS are doing it for the first and possibly only time. Part of the challenge is understanding what you are trying to purchase and how it can help in your content management. After all, effective content management is as much about process as it is software, and without any working knowledge of the issues and pitfalls around content management then there is a risk that an RFP will be seeking proposals for the wrong product.

The web CMS market is very diffused and reliable information about the myriad of different platforms is hard to come by, particularly for somebody with no experience of CMS systems. It can be very easy to fall into the trap of assuming that there are only a few "decent" products or, worse still, jumping towards a large, expensive platform on the basis that "big is best". Paying more for a product does not ensure success, in fact it just tends to add risk to the development. You will run the risk of paying for functionality you do not need and a larger software vendor will just as vulnerable to web CMS market consolidation as a smaller outfit (the uncertain fate of RedDot since it was purchased by OpenText provides a good example here).

From the perspective of risk management, it's best to proceed with caution and start small rather than jumping in to a large implementation that you don't understand and do not need.

Letting technology drive website design

It's important to ensure that a wider website re-design project does not become subsumed into a technology selection exercise. Many web CMS selection exercises are prompted by deficiencies in the current website - the design, content organisation and functionality become so tired that a decision is made to invest in a re-design on a new platform. This re-design is often bundled in with the CMS selection and the risk is that the technology ends up driving the design of the site.

Technology is there is enable the development of a great website rather than define it. Projects that bundle platform selection in with website development risk compromising their website design for the sake of technical convenience. The two don't have to be completely separate activities, but, at the very least, the selection of a web CMS platform should be subordinate to the strategic objectives of the website.

Pre-selecting a CMS platform

Some CMS procurement exercises are, in fact, a process of rubber-stamping a pre-selected platform. Don't do this - it is a monumental waste of everybody's time. If you have selected a platform, then take the time to find a good implementation partner rather than burning time on a pointless CMS selection exercise...