What do we mean by a winning Request For Proposal? Any successful systems acquisition starts with a good RFP. Conversely, a lot of project disasters can be traced back to a less-than-stellar one. When you need a new system, it is the prospect of getting that system up and running that gets you excited. The RFP is laborious grunt work, right?
It is important to realize that an RFP may be grunt work, but it does four crucial things:
• Clearly defines what the system needs to do and why;
• Defines the problem in a way that makes comparing the responses possible;
• Lays out the bid environment in a way that makes the competition fair; and
• Ensures that the specification is broad enough to invite a sufficient level of competition and minimize “no bids.”
While you might be tempted to throw together a quick document and get on with the project, the most likely outcome will be ugly. All too often, the project will have either too few bidders or worse, a project with so many misunderstandings and overlooked items that delays and overruns are the norm.
Here are 12 key points to help ensure your RFP leads to a successful project:
1. No matter who writes it, it is your RFP.
Often, companies will hire a consultant to write the RFP for them. There is nothing wrong with that since most likely this is something your staff does only occasionally, and the consultant does it every day. They bring a great deal of specialized knowledge to the task. That said, remember this is your RFP. When it is all done, the RFP needs to clearly define your goals and needs. Your staff needs to be deeply involved in the process, and not just accept a consultant’s “boilerplate” or standard system specification. The quality of the bids you receive will be directly related to the quality of the RFP that goes out.
2. Do not just say what you need, but why you need it.
Far too many RFPs specify the equipment to be bid without any real insight into your situation, why you need a new system or what you are hoping to achieve. Give your potential vendors that understanding and they may suggest alternatives that provide real value. At the very least, you will give the best vendors a chance to explain why their solution goes beyond the spec to solve your problem.
3. Do not try to redesign the system.
Yes, it is OK to specify the functionality you want in a system. But you need to keep those requirements at a very high level. It is easy to slip into specifying the operational details, and that’s when you move from buying an off-the-shelf product to a fully custom one. For example, I have seen RFPs that specify the functions that get displayed on a right mouse click, or the way the LEDs must work on an access control reader. The impact of that kind of detail is significant; it eliminates some suppliers who would otherwise be qualified, and drives up the costs of the ones who choose to bid. If the vendor changes his product to comply, it increases your project risk — both cost and schedule — and can create real problems down the road as you try to upgrade.
4. Do not write the spec around a single product.
Manufacturers publish A&E specifications for one reason: they hope you will take the easy path, copy their spec and lock the bid in for them. While it might be easy, it is not in your best interest. The writers of these specs may start with a generic description of the product, but they are never done until they have found a series of unique features that only they do and have written them into the spec. If you really need one of those features, great. Otherwise, use their specs for inspiration and write about what you really need, not what they can do.
Of course, the exception to that rule is for add-ons to an existing system. If you have a preference to stay with the existing manufacturer for compatibility reasons, or just because you have had good experience so far, say so. But always structure the RFP to allow a vendor to bid an alternate but compatible solution if they wish. You might just find your preferences are overruled by the advantages of a new product.