The Way Things Work

ENT, August 16, 2000 by Greg Scott

A few months ago, I had an experience that reminded me why I don't like requests for proposals (RFPs). I was on the consumer side of the process this time. My job was to help concisely defined the project, help select the vendors and appropriate equipment, and make sure everything was rolled out, connected, and working properly.

We decided to use an informal process to select vendors, and I figured I had enough technical expertise to evaluate the quality of all the proposals. We didn't want vendors to spend a ton of presales money that would come back into the cost of the project, plus in fairness, only one vendor would get the work, and I didn't want the other vendors through that.

We asked vendors to use their creativity and ingenuity to come up with an approach to the project. The vendors all submitted proposals and we carefully looked over each one. We pocked a vendor and they started delivering their solution almost immediately.

That was when the trouble started. The same day the winning vendor started work, one of the losing vendors protested. Threats and accusations of insdier dealing were cast about, and things got uglier by the minute.

We ended up halting the whole project in its tracks. What I found particularly galling was the vendor with the best plan got punished for being responsive and creative, while one of the losing vendors damaged the project by complaining that the process was unfair and that we didn't put together detailed bid specifications.

Should we have done a formal RFP? In a typical RFP, the customer, often with the help of an army of consultants, work for several months or years to write detailed specifications and dozens of questions for vendors to answer. They specify the exact process and format vendors must follow when submitting proposals and they go to great lengths to appear objective. Competing bidders generally get a chance to ask questions at a public bidders' conference, where they can submit questions formally and in public. Attorneys are often involved and various committees deliberate at length before finally arriving at a decisionl.

Any who has been involved in a major, formal RFP effort understands the problems with this process. It is huge project to write a major RFP, then many become obsolete by the time they are written. And since RFPs presumably define everything for the project, the process allows no means of informal communication between vendors and the customer.

Despite the appearance of objectivity, most RFPs are often biased in favour of one vendor because that vendor helped write the RFP. The bias is usually subtle, where a detailed specification or procedure favors that one vendor at the expense of everyone else, or where the allocated time to submit detailed proposals is ridiculously inadequate. This, is turn, contributes to intense, behind-the-scenes political battles that pit customer factions against each other and various vendors. The decision making process is usually much more chaotic and political than anyone will admit in public. Finally, the RFP process doesn't allow for vendor creativity. A vendor with a unique or innovative solution has no opportunity to present it. Because it doesn't match the specs.

The informal process has its share of problems. In this case, the winning vendor lost because they spent money on a job that they earned fair and square, and then lost through political shenanigans. My customer lost because they won't get the project done for at least several months. My customer's customers lost because the delay inhibits my customer's ability to expand. The losing vendor lost again, even though it won its protest, because it harmed its reputation in the community by publicly complaining. Everyone involved lost, even though we tried to be open and honest with everyone. I'm just a skinny bald guy from Minnesota, but it seems to me that there must be a better way. I don't have the answer yet, but I'm going to give this lots of thought.-Greg Scott, Microsoft Certified Systems Engineer (MCSE), is chief technology officer of Infrasupport Etc. Inc. (Eagan, Minn.). Contact him at gregscott@infrasupportetc.com.