A Request for Proposal (RFP) is a common way to initiate a web project. The idea is that all of the basic information can be presented to solution providers and the resulting proposals can be evaluated by some objective criteria. Unfortunately, this process is deeply flawed and often leads decision makers away from good decisions.
First, the problems with RFPs:
- Understanding what you want is the hardest part. It's safe to say that no one understands what they want when they start a project. The most important part of a project is defining what you want, and you need the help of your web partner to do it correctly. So the first premise of an RFP is already bankrupt — you don't know what you want people to respond to.
- You are choosing a team, not evaluating a document. The focus on the RFP (and the P's it generates) is false. Successful projects are created by good teams that have good information and good management. These are the most important critieria for success. You can't evaluate teams if you are focused on evaluating documents which were prepared against an incomplete — and probably incorrect — understanding of the project.
- Objective criteria blinds you to common sense. I can't tell you how many RFP's I've seen that are accompanied by a scoring system for responses. You get 2 points for this and 5 points for that. This is insane, regardless of whether you share the fact with recipients. See #2. Your job with an RFP is picking the right team. Pretending you are being objective with point systems keeps your eye off the ball.
So what if you want to initiate a web project? What should you do?
- See who works on the sites you admire. This will help you with your list for #2 below. It also keeps you focused on work that is "live", well-known and functioning.
- Go visit web shops. Make or find a list of your Top 10 local web shops and visit them in person. Your goal is to ascertain the quality of the people and process. You can't tell this from arbitrary words on paper. Go see for yourself.
- Hire someone to help you flesh out the requirements. You should neither expect nor want someone to do this for free. Failed projects always start out with incomplete requirements.
- Then, maybe, if your choice still isn't clear from #2 and #3, write an RFP.
And now, finally, advice for actually writing an RFP.
Keep it vague. Remember we are choosing teams. Do not describe detailed functionality of the system. We just want respondents to know the overall goals of the system. If there are technology constraints, enumerate them. If there are budget or timeline constraints, describe them. You want to know the skills, track record and reputation of the respondent, not get a section-by-section response to the problem domain. You should describe the problem domain (e.g. website, content management tool, business application) but also provide opportunities/invitations for respondents to offer additional approaches.
Keep it simple. Focus on describing the problems, not on anticipating the solutions. Avoid prompting for information that won't directly impact your decision. Do not make respondents jump through hoops. Complicated RFP requirements can discourage qualified and desirable companies from responding. With the exception of large agencies, few companies have a staff dedicated to responding to RFPs. Instead of getting a great selection of experts, you may get a selection of talented RFP response teams instead.
Keep it free-form. You want repondents to demonstrate their approach in their response. You should give almost no guidance to the type of response you desire. The right shop will be the one that demonstrates their expertise in the response itself. If you have to tell them what you need in a proposal, you are dealing with amateurs.
Clockwork is considering doing X. While we have a pretty good idea of what we want,
we are smart enough to know that we need help. We are seeking a partner that has
extensive knowledge about X and can point to examples of successful projects with
happy clients in situations similar to X.
If interested, please respond and let us know your approach to a project like this.
Also specifically include the following:
Name of company.
Name(s) of owners.
Number of full-time employees.
Examples of work most representative of X.
If we like what we see we will look forward to visiting your shop to discuss this
in more detail. Please indicate interest by mm/dd/yyyy.
We look forward to hearing from you!
See how easy that was?