In Webstruxure’s line of work, we see a lot of Requests for Proposals (RFPs) for content management systems (CMS). Most of them are asking the wrong questions.
Typically, an RFP for a CMS consists of a very long checklist of features – some essential, some preferred – that the purchaser claims to want, and that the CMS vendor therefore has to promise to provide.
It can be hard to know where these lists of features come from. I suspect they are created by sending a group email round the organisation with the subject line “What features should our new CMS have?”, collating and tabulating all the answers, and then turning that list into the response schedule for a CMS RFP. Or maybe there’s nothing more complicated involved than taking the list of features from the organisation’s previous CMS RFP and adding social media support and a Lolcats plugin to the list.
Specifying a checklist of features, and then totting up the number of features each vendor claims they can provide, has a number of advantages as an evaluation method. It’s simple. It’s comparatively quick. It’s quantitative rather than qualitative.
It’s also largely irrelevant to the success or otherwise of your chosen CMS.
CMS projects don’t usually fail because the CMS lacks a crucial feature. They fail because the CMS is too hard, too cumbersome or too slow to update. Or they fail because the staff who are supposed to be updating the CMS are already far too busy doing other things. These are often administrative staff who have had “update the CMS” added to their job description without any reduction of their other tasks. Is it any wonder if they have little time for their new responsibilities?
CMS projects fail because the list of features a CMS has is far less important than whether the CMS will be used.
So that’s what’s wrong. In Part 2, we’ll look at what to do about it.