I receive a work inquiry in the form of an RFP every couple of months. If you're unfamiliar with the abbreviation, an RFP is a request for proposal. It's a document that a client will prepare and post publicly or send out to potential vendors with the aim of gathering proposals to accomplish a project. In certain industries, and at certain business sizes, this approach is common. For example, government projects will often be initiated with an RFP. Without fail, the RFP's that are sent our way go directly to my garbage folder. Its not that I'm ungrateful for the opportunity, just that I recognize a waste of time when I see it. And, though it does have some merit, I don't think it's a great way for a client to get their project completed either. In this post will take a look at the problems with RFP's and suggest an alternative.
The allure of the RFP is that vendors will compete for your business. The idea is that you research a group of vendors and then send them all one document and ask them to provide pricing information and potential approaches. Then you simply select the best one. This way you save time and money in getting your project completed and get the best possible outcome.
The problem is that this approach treats vendors as commodities. Think about that for a moment. There is some serious naivety in that idea. Development projects are tough. They require experience, depth of technical knowledge across multiple domains, project management know-how, and people skills in order to be executed successfully. No two development companies, or developers, are going to be the same in their ability to execute for you for your specific project. For example, I've marketed Blue Bridge as Joomla developers for many years. There are plenty of developers that market themselves the same, but don't have a tenth of our technical capabilities.
Regardless of what a development company can or can't do though, talk is cheap and it's easy to make promises in order to win jobs. Even in the industries where RFP's are common, you'll hear regular complaints that the project is tearing through the budget and lagging behind schedule. This is because RFP's incentivize vendors to promise things that have no correlation with reality.
In addition, most development companies won't take an RFP seriously. The truth is that you have to have a significant workforce in order to roll the dice bidding on an RFP— i.e. at least one full time salesperson. This narrows the pool to full service marketing and advertising agencies. For smaller workforces or niche providers, an RFP signals three things:
I was asked by a local business whether they should focus on finding someone with domain specific experience or just a good developer they could count on and I told them, hands down, go after the good developer. The big challenge in executing development projects is finding a partner that is both capable and reliable (Note the change in describing the provider: from vendor to partner.) My suggestion would be to do the work preparing an RFP requires because, more than any other client, a client with an RFP signals to a development company that they've done their homework. Then, I would extract out the technical details into a separate requirements document and use this and the preparation for the RFP to identify a few development companies that look promising. Finally, I'd I email over the requirements document and do the back and forth about capabilities, schedule, and costs before getting on the phone with the ones who made the final cut.