Long RFPsI repeatedly mock vendors on several topics on this blog, including their non-constructive habit of sending very long proposals. Yesterday I received a 122 page RFP for review from a higher education institution which reminded me that vendors are not the only ones to blame for long proposals.

How come some of you can’t make the RFP short? A long RFP does not guarantee a high-quality response and some successful vendors might simply be too busy to respond to lengthy RFP’s. Short RFP’s really are considered best practice. Let me highlight some of the common symptoms and bad habits I have come across:

  • The real priorities are unclear. Most customers really don’t know what they want and why they want it. To compensate for this lack of objectives they add everything they can think of to the RFP.
  • Preventing risk or misinterpretation. Some believe that a long RFP is the only way to mitigate risk and prevent misinterpretation of requirements.  Some will also add a great deal about legal requirements. My short response to this: Keep it simple and remember that quality always beats quantity, also in a RFP.
  • Avoiding dialogue. If you go ahead and try to envisage everything the vendor might possibly ask, you will end up with a very long RFP. Intangibles such as community, live product demonstration and roadmap are often underestimated and requires dialogue.
  • An excessively long description of your organisation. Many write lengthy paragraphs about themselves, their strategy, corporate history, office locations, management structure, financial results and where to park. For the purpose of a CMS project, I’ve never understood why you need more than half a page to describe who you are. If you want, add a URL to the “About Us” section of your website.
  • A long list of functional requirements. This is the worst culprit and in some RFPs these can be more than 100 pages. It can be a constructive internal exercise to write your requirements, but it is quite a detour when it comes to a CMS selection. Functional requirements can force you into selecting an unnecessarily complex system and you normally don’t learn much from the vendor responses. Instead we recommend no more than 10 short scenarios at around half a page each.
  • Too many technical details. To please your IT colleagues who might not be running the CMS selection, you give in and let them add a boring section on the IT architecture with detailed diagrams, security infrastructure overview and database designs. Most vendors will have seen this many times. Instead, tell the vendors what makes you different (e.g. antiquated version of a database) and if you have any specific technical requirements, e.g. Python. This is another section that should be less than half a page.
  • The ever extending feedback loop. When the RFP is sent around for internal review, everybody is concerned that their exact needs will not be met, so they add even more details hoping this will ensure that they get what they want from the onset. Nobody internally will try to make the document any shorter except if you designate an experienced project manager.

As a rule of thumb, a vendor will never make their proposal any shorter than the RFP. This means that if you issue a 100 pg. RFP to 10 vendors, you can expect to receive more than 1,000 pages for your perusal. Have fun!

Thanks to Martin Risgaard (@Risgaard), Philippe Parker (@proops) and Zahoor Hussain (@izahoor) for valuable input.

Learn more

If you are working with CMS as a big part of your job, then consider joining our CMS Expert groups. CMS and all the related challenges is also a regular topic in many other J. Boye groups for web & intranet professionals.

CMS is also a hot topic on the web content management conference track at J. Boye Philadelphia 12 on May 10.