When a Reseller’s Proposal Doesn’t Meet Specs

I was poring over the minutiae in an RFP (request for proposal) when I found the bad news. The computer that was proposed for a disputed contract did not, in fact, meet the requirements. Because of the way the contract was written, the reseller would have had to provide an upgrade at its own expense to satisfy it. That upgrade could cost millions.

Fortunately, the reseller in this case wasn’t actually my client. I was working as an expert witness for the attorneys in the case, and in a few days, I would have to testify as to whether the reseller’s response to the RFP was actually, well, “responsive.” To their dismay, it wasn’t. While I’m still not allowed to discuss the details, I can say that the dispute revolved around the way in which the proposed computers updated their BIOS.

Unfortunately, the reseller could only blame itself. This was a very large potential purchase, and the buyer had gone to a lot of trouble to make clear specifications. In addition, the buyer had held a formal, open question-and-answer session and provided the transcript of that session to everyone submitting a proposal.

Questions and answers that came in later regarding the RFP were distributed to everyone. There was no mystery here, but for reasons that remained unclear, the reseller bid computers that clearly did not meet the specs.

One of the reseller’s managers thought the reason was that technically, the difference in how the BIOS was updated was meaningless, but the reseller had asked a question on that issue and was told that its solution wasn’t acceptable. But they proposed it anyway.

My guess is that the real reason was that the proposed solution was a lot less expensive and would work just fine, or so the reseller assumed. It may also have been that the computers being proposed were new to this reseller, who wanted to make a big impression on the hardware vendor.

How are sellers dealing with fallout from a PayPal outage? Click here to read more.

Eventually, the reseller won the contract, and the win was challenged by all of the losing resellers, most of whom pointed out that the winning proposal didn’t meet specs. I was retained to review the proposal and show that it really did meet those specs, if it did. Unfortunately, it didn’t, and I couldn’t honestly say otherwise.

The reseller was then faced with withdrawing the proposal or substituting computers that did meet requirements at the same price. They’d spent a lot of money winning the contract, and they didn’t want it to be a waste of time. On the other hand, substituting a different component was possible as long as the reseller didn’t mind losing money on each one purchased.

The result was a lose-lose situation for the reseller. There just wasn’t a good answer. In this case, the loss per computer wasn’t great, and the reseller figured that the price per computer would drop quickly as volume picked up, and chose that route. But for the first few months of the contract, it meant losing a lot of money. That loss could have been avoided by paying attention to the requirement in the first place, and by proposing a solution that met requirements instead of going for a low price and hoping no one would notice.

One of the final actions I took after the court was out of the picture was to spend some time with the reseller showing them how to prepare a compliance matrix, in which you make one axis the RFP requirements and the other how the proposal meets the requirements.

This is something the reseller should have done but didn’t know about. Had they done this, their proposal would have met requirements. Even better, they could have included the matrix with their proposal and removed all doubt.

This, of course, would have meant that I didn’t get retained as an expert witness, but in the long run, it would have saved everyone a lot of money. As much as I loved that work, it probably would have been better if I hadn’t been needed.