The Website RFP (Request for Proposal) and RFQ (Request for Quote) process seems to make sense for companies with a critical development project that they need completed.

What they don’t realize, however, is that the standard RFP process actually costs them more money in the long run and doesn’t necessarily effectively identify the most qualified developer for the project. Let’s face it, the skills needed to put together an impressive RFP response and proposal are very different than the development skills that will actually get the job done properly.

That’s why we’ve chosen not to respond to 95% of the RFPs we hear about, yet we still continue to grow and prosper as a development agency. We even manage to land some of the opportunities that we don’t bid on.

Let me explain:

What goes into a Website RFP on the client’s side?

To put together a quality RFP, a company generally needs to invest many hours in documenting the following:

• The basic requirements of the project.
• The target audience for the completed project.
• The project timeline.
• The selection criteria for the winning response.

All of this is good in the respect that the client should determine most of this information before selecting a development partner, and doing so makes it easier to effectively choose the right one.

The trouble, though, is it typically requires a professional software development business analyst to thoroughly identify the nuanced requirements, use cases and details that are so critical in actually being able to accurately bid on a project.

What goes into responding to a Website RFP on the developer’s side?

A typical thorough RFP response can easily grow to 30 or 40 pages in order to completely address the client’s project requirements as laid out in the request. This is especially true when the requirements are not tightly defined (and all options need to be explored and addressed). Additional time is spent outlining the development process that will be followed and sharing relevant business cases in an effort to convince the prospect that our development firm is the very best of the many firms who may be applying. We’ve invested upwards of 60 man hours into creating formal responses (and sometimes we never even hear back despite being more than capable… Ouch!).

Obviously, prospects don’t pay developers for the time they spend responding to open RFPs, so that means 60 hours of unpaid work that may or may not end up resulting in paying work down the road.

From a business perspective, that’s tough to swallow.

My RFP epiphany:

Despite realizing the craziness described above, as a professional web developer and president of an established web development firm, I’m sure I’ve responded to hundreds of RFPs over the years. It just seemed like a necessary evil in order to land the available jobs that were out there.

But then, I had my epiphany:

I realized that I could offer a no response and explain my reasons to prospects, many of them could benefit greatly from putting aside the RFP process as well.

Here’s why:

The RFP process for web development projects is outdated and costly.

When RFPs first came into vogue, they were the most organized and practical means a company had to find out who was willing and available to work on a particular project, compare their qualifications for the job, and receive competing bids in search of the best value.

But these days, a quick note to your professional network looking for referrals – or even a simple Google search – in combination with some basic interview skills can determine if there is enough of a rapport for both parties to continue considering working together. Additionally this approach has the advantage of requiring considerably less cost and time from both parties.

Taking this route has many advantages beyond time and cost savings:

• You’re starting your search with far more information at your disposal
• You have the opportunity to personally engage with prospective developers one-on-one
• (Perhaps most importantly) You can locate higher quality developers who charge less

Let me explain that last one a little further:

Developers who rely on RFP responses have to charge more.

As I mentioned earlier, responding to an RFP involves many hours for no pay. It’s a gamble in the first place, because you have no way of knowing for certain if you’re going to be chosen (and if there is even truly a legitimate opportunity available). But it’s always a loss in the respect that, even if you get the job, you’re starting out at a deficit because you’ve spent all that time up front responding to the RFP.

In order to maintain a profit so that the firm doesn’t bid itself out of business, developers that rely on RFPs have to significantly raise their hourly rates to make up for what they spend responding (and the risk they take).

There’s no other way they could maintain profitability and stay in business.

An example from real life:

I have a good friend and colleague in Chicago who gets nearly all his work via RFPs. He has dedicated staff whose sole job is locating RFPs to respond to and developing responses. And he does very well.

I know, because he subcontracts a large amount of his work to my firm.

Now, it would only make sense for him to subcontract to me if he were still making significant profit on the job even after paying my fees. It would be bad form to reveal specific dollar amounts here. But suffice to say, he charges far more than I do even though – by his own admission – my firm does work that’s just as good as what he could do in-house, and even better in some of our areas of expertise.

So what if his RFP-wielding clients found my firm via a trusted client referral and worked with us directly instead of through my friend’s higher cost agency?
They would save time and money across the board, and they’d probably get the project done faster simply by removing the RFP process from the timeline.

Getting down off my soapbox…

Sure, I have some pretty strong opinions on this subject. I’ve made the personal and business decision to refrain from responding to most of the RFPs that come our way, and I’ve found it to offer excellent benefits for my team as well as our clients.

There are still RFPs I come across on occasion that I’ll make a conscientious decision to invest in, despite everything outlined above. If you’re interested in my 8-step vetting process to determine which RFPs are worthy of this investment, you can watch a video on the subject here:

Web Development RFPs: Should You Respond?

If you’re a company with a web development project currently in the RFP stage, or soon to be, do yourself a favor and contact us just to see the difference when the process is viewed critically. We think you’ll be impressed.