A Legit Article

Why Website RFPs Cause Big Problems for Great Organizations

By Marc Carson · Friday February 6, 2015

Just to put this post in context, I have been building high-quality websites for private and non-profit organizations in government, tourism, health care, philanthropy, and the arts for over 15 years now. I consistently receive high marks from my clients on the quality of support, training, and design that I offer.

Sadly, it has been my experience that most request for proposal (RFP) driven website efforts are unnecessarily costly and result in an inferior end product. In fact, after their RFP-driven projects have ended, some of my clients have used executive authority or other non-RFP means to hire me directly to improve their new websites (I offer this example not to boast, but to illustrate how RFPs look from my professional perspective).

Typically I only follow up on RFPs that are a few pages long, do not ask for sensitive business information (see below), and do not self-prescribe specific solutions.

While I understand that RFPs are meant to assemble a range of comparable service offerings—even if I dispute the effectiveness of that strategy—I feel that this is an unnecessarily risky process for all involved. Why? Here’s what is working against RFP authors:

• High demand for web talent means that more talented vendors do not often reply to RFPs; this applies especially to the more detailed RFPs. If an experienced vendor does not reply to an RFP today, another potential client with fewer requirements will probably be in touch with them tomorrow.
• Experienced vendors prefer to work with as few stakeholders as possible. An extremely formal RFP process communicates the idea that there is a huge bulk of administrative overhead that must be overcome, with multiple stakeholders in multiple departments. This kind of situation is risky for vendors.
• RFPs often request private or business-sensitive information that potential applicants would prefer not to divulge in digital form or otherwise, because of information security concerns.
• RFP authors’ assessment of their own needs is often off-target or based on flawed information. This is not their fault; the requirement to assemble respondents with easily-comparable offerings incentivizes authors to make guesses or express themselves using industry terminology.
• RFPs typically do not reveal an understanding of the importance of an ongoing website evaluation and refinement loop, and mostly focus on first-stage development as an end in itself.
• I have been disappointed with the type of respondents I meet at RFP conferences. It is not uncommon to find a room full of people who are simply good at writing business cases and hiring the cheapest subcontractor.
• RFPs have an extremely poor industry reputation. Please see norfps.org for more links and information.

Please feel free to share this article if you know of others who may benefit.

Marc Carson