Tips on Working with RFPs
One of the time-tested ways of buying computer-related goods and services is to use a Request for Proposal ("RFP"). If your organization has never used an RFP before and you're considering a major investment in your computers or software, you should give some thought to an RFP. RFPs are of particular importance when you’re contemplating a major investment such as a managed services or SaaS agreement, when you’re looking at major long term investments of both time and money.
An RFP is essentially a request for potential vendors to make offers to provide a service or product that matches your basic specifications and budget.
While I've helped create and have worked with RFPs that required looseleaf binders, I've also helped to create some that are rather short. While governments may have requirements that lead to extremely formal and legalistic RFP processes, in the private world, you can create your own rules for the RFP process. You don't have to create a monster document, unless you choose to create a monster to suit your needs.
In fact, in the world of private industry, you can and should disengage yourself from the image you might have about government RFPs and their formalistic process. Hey, we get to make the rules.
If you don't want to be "required" to award the contract to the lowest bidder, then don't. We will just write the RFP in such a way that you have no such requirement.
If you want vendors to submit all their questions in writing with the question and answer going out to all bidders to keep the playing field level, then make that the rule. If you prefer to take informal phone calls or have a scheduled bidder's conference, then do that. The overriding point is that in private industry there is no right or wrong way to do an RFP. It's your game. You make the rules-- subject to one important proviso.
As with everything else you do in business, you only have one reputation to go around. While I tell you that you can set the rules anyway you want, I warn you that whatever rules you set, you should abide by them and not change them whimsically as the process progresses.
Conceivably, you could set yourself up for some kind of lawsuit if you play fast and loose with your own rules, but that's really not the big issue. You would almost have to work at it to end up on the wrong end of a lawsuit over an RFP. The real issue is your reputation.
The Basic Format
Experience has taught me that the time, money and effort invested in writing an effective RFP on the front end can and will save you time, money and effort at the back end of the contracting process. An RFP is an effective way for you as you to tell your vendor what it is you want and what you intend to invest to make it happen.
The most important component of an RFP is your detailed explanation of required functionality. You'll want to describe things like your operational requirements, performance standards, acceptance testing criteria, the operating environment including hardware, operating system and other software, your size and scalability requirements, delivery needs and other related details.
Your tech lawyer should be sure that your RFP includes some basic protections for you. For example, you'll want it to be clear that the issuance of the RFP commits you to do nothing. You pay no costs associated with creating the response to the RFP, you don't have to enter into any contract with any of the potential vendors and you won't provide any materials or labor.
From the Vendor's Perspective
While you don't want to ignore the rules your potential customer has created, you should construe every ambiguity in your favor to gain some advantage over your competitors. You need to use everything you know about your potential customer and read the RFP in context.
If you have contacts within your customer's organization, use them. An informal phone call or use of the appropriate social network, handled properly, might just give you the edge. Be careful here though. You don't want to cross any lines and do anything improper, but if you can, use your back channels to your advantage.
You might call your biggest fan in your customer's organization and ask if it's okay to discuss the RFP. Invite them to say "No." Often, when you're outside the realm of legalistic government contracting, you'll find that informal conversations may be welcome.
Once you get permission to start the conversation, ask away. Never lose sight of that cliché, "Information is power." The more you know about their wants, needs, expectations, predispositions and whatever else it is that you can learn, the bigger the advantage you have over the competition.
Your response should get some level of legal review. As much as anything, the purpose of this legal review is to insure that you haven't somehow created unintended legal obligations with your response. I can assure you that your customer has left themselves wiggle room for the final negotiation. You just want to be sure to do the same.