For those who don't know, RFP stands for: Request For Proposal. The purpose of an RFP is to provide an outline of the specifications for a project that you hand off to a number of different vendors in order to receive quotes back from them.
Now, in that statement, there's an inherent directive that often gets overlooked in many RFP's.
Most vendors in our business can recount stories of receiving RFP's from organizations that were for $100,000+ of work and the RFP was 10 pages long, 9 of which were taken up with information about the mission of the organization and details of how the proposal should be structured - leaving the project specifications to one page.
To put that in context, I have also seen 50-page proposals that dedicated 30 of it's pages to project specifications and there were still gaps in the project definition. So, that perspective can help you appreciate that the one-page project spec. really isn't going to provide more than the broadest of broad strokes to the vendors.
The challenge that a weak RFP presents is that it doesn't give vendors an opportunity to quote effectively. Their proposed approach and associated numbers are based on speculation and as such, one vendor’s proposal can vary wildly from that of another vendor. This doesn't give the vendors a fair shake at the project and it requires them to do a lot of strategic thinking for free while not being assured of any work. As such, it's a huge risk.
But even more importantly, it doesn't really give the organization issuing the RFP a good sense of how the vendors stack up against one another. In other words, the whole purpose of the process is undermined.
By providing as much definition in your RFP as you can, you create a baseline from which to evaluate various vendors. Sure, there's still room for them to get creative and suggest additions or revisions to round out their pitch, but if you force them to quote on a well-defined standard and then provide any revisions/additions as separate costs, you'll have a great baseline to compare and contrast them.
That all being said, I realize that there's a flaw in that plan.
What if you don't know what you need and don't have the people in-house to help you figure it out? Web development projects are a frequent offender for this kind of thing and the idea of having to spec out the whole project can seem daunting.
Thankfully, the answer is simple. You're not ready to issue an RFP for the full project yet.
What you need to do is issue an RFP for a Project Requirements Definition. You need to bring someone in to help you define the project well and then help you define the RFP for the actual project. Project planning is a fundamental element to a successful project and if you can't do it alone, be willing to bring someone in to help with it!
Separating that process from the project bid process will allow you to ensure that you minimize risk for everyone. And again, vendors may provide you with tweaks to the project plan/execution, but the specification you put out in the RFP will allow them to at the very least, quote against other vendors and then strategize above and beyond that.
