- Is the Cisco MARS mission going to abort?
- First iPhone worm spreads Rick Astley wallpaper
- 10 stunning 3D buildings made with Google SketchUp
- Open source software ready for big business
- Four reasons to buy (and one reason to avoid) the Droid
The request for proposal (RFP) process has been the bread and butter of purchasing organizations for decades. IT organizations aren't strangers to the process, typically sourcing a significant amount of IT spend through RFPs.
Overall, the process is a good one. Customers document their requirements and needs, vendors are qualified and solicited, and customers compare and contrast vendors to ultimately select the finalist. The process is relatively straightforward, too. An RFP is issued, proposals are evaluated, a vendor is selected and a contract is negotiated. There's also a sense of safety in using the RFP process in that, because it's a competitive process, the customer can assume that he or she is getting a "good deal" more often than not. Unfortunately, what customers don't know is that the RFP process widely used today is fundamentally flawed, and those customers are leaving sizeable concessions on the table by using the process.
In the RFP process, there are two interrelated events: vendor selection and negotiation. Vendor selection implies a formalized competitive bid by which vendors are objectively evaluated and selected based on pre-defined criteria. Negotiation is the process by which two parties have an exchange to reach an agreement. While the events are interrelated, they are sequentially distinct in the RFP process. In other words, a vendor is selected and then a price and a contract are negotiated. That is an extremely flawed sequence of events-negotiations are severely compromised when a vendor is notified that it has been selected prior to beginning negotiations. In that case, the customer loses nearly all leverage because the vendor has been selected. This is the "selection/negotiation" or "begging" RFP model, and is a model very commonly used by customers and purchasing organizations.
Under this model, at the point of selection, the finalist vendor correctly assumes that the other vendors have been eliminated and possibly notified as well. In other words, the vendor's competition has been eliminated by the customer and not by the vendor. If the vendor's sales representatives are shrewd, they will drag out the negotiations, seeking to lengthen the time from the point of the finalist selection to the start of actual negotiations. In doing so, the vendor causes the customer to make a time investment, and selecting another vendor is that much more difficult. After a while, the customer has a vested interest in bringing the deal to a close and, if the vendor is opportunistic, the customer will leave concessions and value on the table. (For more on negotiation, read Price Doesn't Matter.
Simply changing and overlapping the sequence of the vendor selection and negotiation events yields dramatically different results while keeping the rest of the RFP process intact. This change of event sequence, or the negotiation/selection RFP model, implies that the negotiation process begins parallel to the vendor selection process but prior to actual vendor selection. The purpose is to prolong the customer's leverage during the vendor selection process and "pre-negotiate" the price and contract before leverage is materially eroded. Negotiations under this model begin in earnest when a "short list" of vendors has been determined. After the customer has selected two or more finalist vendors, the remaining vendors are notified. The customer then parses the best attributes of all of the finalist vendors' offers, includes any additional concessions desired, and communicates the parameters of the cobbled deal to the vendors. The vendors are subsequently instructed to provide "best and final offers," or BAFOs.
Partner Content
Blue Stripe Software
www.bluestripe.com/
Improving Application Performance Troubleshooting
Diagnosing why an application is slow is hard, at times taking days or weeks to isolate and resolve. This paper explains the challenges involved using current management tools, provides a 'wish list' for application management and analysis, and explains the need for an application system-wide approach that monitors entire applications, not components.
Download Whitepaper
Virtual Vigilance: Managing Application Performance in Virtual Environments
This paper highlights the impact of virtualization on application performance. "Managing Application Performance in Virtual Environments" states: "Best-in-Class organizations are predominately taking actions around improving visibility across both physical and virtual systems, assessing the business impact of application performance and understanding interdependencies of applications in virtualized environments."
Download Whitepaper
Application Service Requests: The Missing Link for Pragmatic ITSM
Forrester Research analyst Glenn O'Donnell and BlueStripe co-founder Vic Nyman discuss a breakthrough approach to application problem management. Learn the new approach for ITSM problem management, which provides: Rapid isolation of application slow-downs to specific components for quick problem resolution, 24/7 monitoring for proactive notification of potential issues before end users are impacted and much more.
Register for Webcast
Comments (2)
A very good articleBy tuomoks on March 7, 2008, 5:52 pmThis article brings out some important issues which for some reason come up time to time. Having experience on both ends, creating RFI's / RFP's and answering to...
Reply | Read entire comment
Rajat Dhameja RFPBy Anonymous on April 21, 2008, 3:31 pmThis is really helpful. I was just wondering how often is it when the customer loses leverage after vendor is aware about its strength and selection. I have developed...
Reply | Read entire comment
View all comments