One of the best things about working in our industry is that there’s always something new to learn. It’s never boring!
After many projects, I still learn new things with every one.
On a recent project, I ran into a new situation. I think this lesson learned is worth sharing.
It started while evaluating proposals submitted in response to a request for proposal (RFP) that I’d created for my client. The RFP included sections on system capabilities and necessary features, as well as one that outlined installation and support requirements.
In response to a question about a typical installation plan, one of the proposals referred me to an attachment. I couldn’t find it, so I contacted the vendor and asked for it.
Instead of a “typical” plan, the vendor provided a full-blown scope of work (SOW). Normally, I don’t see a SOW until the final solution has been determined and we’re in contract negotiations. So it was unusual to see it at this point in the process.
In reading the document, it became apparent in the first couple of pages that the SOW didn’t match the RFP specifications. Key requirements, such as call recording, hadn’t been included in the SOW. Other types of work, such as placing the phones, were a customer responsibility (even though the RFP made it clear the vendor was supposed to do this).
“Houston, we have a problem!”
In another situation, ignoring the client’s requirements stated in the RFP could easily result in the elimination of the proposal from further consideration.
In this case, I talked it over with the client and it wanted to give the vendor a chance to make corrections. So I dug into the document, noted all of the issues that I found, then sent it back to the vendor asking for adjustments in configuration and pricing to match the RFP’s requirements.
The price more than doubled. Ouch!
So what lessons did I learn?
While it’s normal to review the SOW during contract negotiations, in this case seeing it during the proposal evaluation phase was extremely valuable.
The vendor’s SOW made it clear that there was a huge disconnect between what the client and vendor were expecting. It’s always better to understand this (and get it corrected, if that’s what you want) before giving “final” numbers to upper management.
I wouldn’t want to be the one who had to ask for twice the money after having received approval for the project budget.
And here’s an old lesson that was reinforced yet again:
Include your RFP and the vendor’s response in the final contract AND be sure that those documents have precedence if the terms of the contract conflict with what the vendor promised in its proposal.
If you’re in the situation where you don’t discover a disconnect, you can go back to the proposal and show the vendor where it agreed to your requirements. Including the documents, with precedence, in the contract legally obligates the vendor to meeting your requirements.
If you don’t see the SOW until you’re negotiating the contract, give it your full attention. The RFP spells out expectations from a buyer’s point of view. The SOW shows what the seller plans to provide.
If they don’t match, it’s far better to iron out the differences before you sign a contract -- while you still have the leverage and the ability to change your decision, if needed.
"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communications technology professionals serving clients in all business sectors and government worldwide.
