As an analyst, I like to compare. Everything is compared to something similar to make a point or at least an interesting conversation. Selecting a CMS is compared to selecting a car, implementation to building a house, any town with hills or water to my childhood home town and so on.
I often say that our industry (CMS, portal, intranet, wiki, enterprise search whatever) is young and immature, in particular when compared to other IT segments, such as word processing, CRM or ERP. When I recently read an interesting article by Ismael Ghalimi called Don’t RFP, Just DIY, which covers problems with selecting a BPM (Business Process Management) product and the general state of the BPM market, it struck me how familiar the problems sounded. In fact if you just replace BPM with CMS in the article, it all makes entirely good sense. You can try it with ECM, Portal and so on as well.
According to the article the traditional Request For Proposal (RFP) process is to blame for many project failures. "In a nutshell, customers learn very little if anything when asking BPM vendors to go through such an RFP and bake-off process" says Ghalimi.
Reading the article was a comforting reminder that we should be able to extract learnings from other industries. As we are facing similar problems, it also suggests that what has worked well for other industries, should also work well in ours.
Thank’s for sharing your thoughts, Janus.
Indeed, too much time can be spend on RFP’s. If you are responsible for procurement and handle it as described in Mr. Ghalimi’s post, you would be spending too much of your own and other people’s time and resources.
But I must say that I don’t recognize the representation of a typical RFP process in his post. You write though that, in your experience, much of Mr. Ghalimi’s statements would apply to e.g. CMS- or portal projects you have been connected to. Would you be so kind as to elaborate on that? It would be interesting to hear your view, as I assume you, with your global outlook, refer to projects outside the Nordic region.
To quote Ghalimi on the traditional RFP process as he sees it:
“…huge laundry lists of features suggested by analyst firms and enriched by all possible stakeholders in the organization, submitted them to a dozen vendors for initial selection, invited three of four for a bake-off, then selected the winner based on its ability to deliver a Proof of Concept in a relatively short period of time (typically three to five business days).”
I’ve seen exactly this approach many times in both CMS and portal projects, both within and beyond the Nordic region
To be fair, I’ve seen many different types of RFPs which ultimately serves very different purposes (e.g. selection only or also usage later on in project) or for very different audiences (e.g. vendor only or system integrator only), . Ranging from 5 pages to 100+. I have my preferences, but the critical aspect is that the buyer up-front has clarity on how the decision ultimately is made. How do you define when the proposed solution/system “good enough”?
Stig, what’s the RFP differences as you see them?
Thanks for your insights on this Janus. I agree that an RFP Process *should* allow a customer to compare products and hone in on the one which suits them best, but it’s often the “process” part which is missing. The act of producing the RFP is often the part which is neglected most: the process of gathering, understanding and analyzing the NEEDS of the organization in order to determine the features of a CMS on which to focus. Unfortunately, the act of producing the RFP often end up being a futile attempt to copy and paste all of the possible features of any CMS and put a checkbox next to them for vendors to mark yes or no as to whether they can or cannot provide this functionality. Similar to your referenced article’s suggestion about BPM tools, most CMS tools provide essentially the same feature sets, so vendors’ bids (responses to the RFP) often end up describing how *similar* they are to their competitors, rather than pointing out their strengths or unique qualities in the context of the needs and interests of the customer’s organization.
Since the typical bid-to-RFP page ratio is about 5-to-1, customers would be well-advised to do perform some serious soul searching to determine their needs, and write as short an RFP as possible in attempt to understand how each product (and the vendor themselves, since this relationship will be a long one) will ensure that each of those needs are satisfied successfully. After providing sufficient context, the author should ask questions which elicit thoughtful responses with examples and scenarios (no binary answers allowed). Additionally, the degree to which the vendors show interest in the customer’s environment by asking questions in advance or alluding to potential scenarios will provide clues about their understanding of the complexities and unique nature of each implementation and will afford the decision-makers some insight into their approach and consultative tendencies. Finally, a PoC is always essential and should be crafted to gain insight into the vendor’s level of engagement and support as well as the technology itself.
[...] attention is given the actual writing of the Request For Proposal,. I have argued that the traditional RFP process is to blame for many project failures. However, the email where the RFP is attached, is also important, as this is the first thing the [...]