An RFP is a B-A-D Way to Find a Web Vendor

Posted at July 6, 2011

There are a lot of articles online discouraging the use of the Request for Proposal (RFP) to select a Website design (or any type of services) vendor. Many of these articles are written for businesses or large procurement departments, imploring them to find more effective and time-efficient ways to develop a new vendor relationship.

Consider this blog post the equivalent for churches.

Typical Structure for an RFP

Most Website RFP documents follow a boilerplate format.

  • A little bit about our church
  • What we want to do with our Website (very general)
  • Requirements we have for the chosen vendor (very specific)
  • Our budget
  • Our schedule
  • How and when to respond to this RFP

The RFP will often prescribe very strict standards on the format of the response. Sections often must be named with specific wording, a certain number of copies must be delivered, and questions can only be asked/answered via Email before an announced due date. If a vendor passes the “first cut” then they will be “invited” to a fixed-length conference call to pitch the solution to the church committee.

Proponents prefer this approach for a number of reasons:

  • Because of the inherent structure, the RFP produces proposals from vendors that are fairly uniform.  This makes it easier to compare apples to apples.
  • Regardless of vendor size or experience, they are competing on a “level playing field” which gives the smaller guys a chance.
  • Proposals based on an RFP should contain real responses to the project description, not just sales-oriented lingo. Thus, the committee can better visualize how each vendor would approach their project.
  • Vendors who cannot compete within the prescribed budget will self-eliminate, thus producing a crop of competitors who can work within the dollar range given.

Who Gets the RFP?

Most churches send an RFP to at least three organizations. Typically these would include the current Web vendor (out of fairness), along with other competitors. Some of these competitors might be known via a mutual reference or a prior work experience, but often they are blindly chosen through quick market research. (The pastor might see another church Website he likes, and ask the committee to send an RFP to that church’s Web provider for a quote.)

Vendors receive the RFP document attached to an Email, inviting them to participate. For most, this will be the first time they’ve ever heard from this church at all.  The vendor must then make a decision as to whether they want to participate and write a proposal.

Inherent Problems

Despite the perceived benefits cited above, the RFP process carries many risks and pitfalls. If having the most successful outcome is your main objective, then you should think carefully about whether an RFP will get you there. Consider these concerns:

  • You’re defining your problem, then telling the prospective vendor to solve it. Unless your church’s expertise is in Web/media development, then is it possible that you might need help defining your online ministry strategy too? For example, you might have had problems on your old site with a message board system that was under-used, and allowed too much spam. Your response? Tell any new vendor that they must provide a quote for a new, secure message board system. But what if the problem is really that your church members don’t want to use a message board system anymore? Giving your vendor the freedom to work with you on a more effective online ministry platform would yield a much better result. But you can’t get there from here in the context of a blind proposal.
  • The bidding process is often wired to a specific vendor before it even starts. All too often (and we are talking a majority of the time), your church probably has a good idea of who you plan to use. It’s this company’s project to lose. But in the interest of “fairness”, “transparency”, “accountability”, or whatever, you go out and get 3 extra bids. Those other 3 vendors never really have a chance, since the deck is stacked. But they don’t know it. At best, this is an expesive marketing research project for your team. Realistically, it’s a waste of time for all parties.
  • RFP structure discourages creativity. Do you want your vendor think outside the box? Then don’t put them in a box!
  • RFPs are better suited for procurement of physical goods, not for services. Use an RFP to pick your paper towel vendor. Not your Web designer. A Web design project entails many variables, lots of ways to solve the same problem, and lots of creative opportunity. Different firms will approach things very differently. It’s honestly tough to get a true “apples to apples” comparison from proposal documents. When the Sistine Chapel’s Ceiling Adornment Committee convened in 1508 to choose an art vendor, they probably didn’t send out RFPs with a list of “must-have” colors and symbols to include on the ceiling. (Surely that type of critique was saved for later, in the comp review conference call.)
  • The RFP process short-circuits the marketing and sales process that most vendors use for the rest of their clients. The best Web firms will post sample designs, video demos, hands-on demos, and comprehensive feature/pricing lists online publicly. Requiring them to re-write this material and send it to your company on a stack of dead trees only reduces the usefulness of the information.
  • Projects are about relationship; RFPs are about mechanics. Some of the most competent firms are also the hardest with which to work. The RFP process removes much of the “touchy feely” part of the sales process. True, you need to vet each vendor’s qualifications. But for the same reason that you should never hire a person without a face-to-face interview, you should look for ways to bring more conversation into the vendor selection process. Not less.

The Effect

Most of the complaining about RFPs seems to come from the vendor community. True, true. But the church community also should consider the downsides of the RFP.

  • RFP documents take time to write and distribute. For volunteer committees (especially), this is precious time that could be spent on strategy, content development, or a thousand other things that move the ministry forward.
  • The mandatory response times, evaluation schedules, and vendor selection meetings create lots of unnecessary work for the committee. See previous point.
  • The decision to issue an RFP may be a mask for other dysfunction or politics. If you find yourself issuing an RFP so that someone’s feelings don’t get hurt… or so that you can gracefully reject a vendor who wants your business… or so that you can silence the loud person in your committee who only wants to use one company… then you may have bigger problems lurking. Everyone benefits when these true issues are exposed and handled early in the process.
  • You won’t get the best solution. This doesn’t mean that the vendor you choose isn’t the best one. They might actually be the right firm for the project. But in the RFP process, you’ve already boxed them into a certain format and budget. Good vendors will tactfully push on these boundaries to guide you, but many of them will take your RFP as gospel and merely fade back into order-taker status.
  • You might pay too much. We routinely get RFPs from churches who tell us they want to pay thousands of dollars for us to build them tools to make forms, take donations, stream sermons, integrate with Facebook, etc. We’ve already done all of that, and we offer it for $99! But when the church gets it into their head that this type of stuff “must be complicated” and “must cost a lot of money”, they will discard low-price solutions because of the entrenched price-to-value prejudice.

Alternatives to the RFP

Here are several ideas that can still yield rich data on each prospective vendor, yet create a more collaborative, budget-conscious, and creative end result.

  • Check each vendor’s Website for pricing and features. If they don’t list pricing, that may already be a red flag (but not always). Compile your own spreadsheet of features and benefits you care about, so that you can assimilate all of the information you collect into one format.
  • Talk to current clients. In a 5-minute phone call (or a quick Email exchange) they will give you more unvarnished and real-world data about the vendor than you could ever hope to collect in a written proposal.
  • Committees: assign each committee member to research one vendor and report back. Use a checklist or structure so that everyone is looking for the same characteristics.
  • Consider first paying a vendor ONLY to help you define initial project requirements. Many design firms will help walk you through the discovery process, and possibly some information architecture work, for a lower fee than the full project. This is a great “try before you buy” approach that can save you money in the long run. If you give this assignment to your front-runner vendor, and things work out, then you have a huge head start. If things go sour, then at least you emerge with a more well-informed strategy.
  • Ask for a demo or free trial. Some systems aren’t well-suited for free demos, but in most cases there will be a way for you to get your hands on the tools. If the vendor is proud of their technology then they will find a way for you to use it, because the Website management tools should sell themselves. A risk-free 30-day trial can be a good way to ask your support staff to give it a spin, and tell you if they think it will work for them.

For Additional Reading

Here are some additional links you might want to check out on this topic:

And here is a great article written from the opposite perspective:

blog comments powered by Disqus
©2014 SiteOrganic LLC

Switch to our mobile site