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.

“…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?

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.