... I've never responded to an RFP in order to get a new client. But I have assisted clients who were responding to RFPs in their markets, and I hope you'll find my pointers generally applicable.
Have you ever landed any new business from an RFP?
Discussion on:
View:
Show:
I?ve written more than 20 RFPs for various clients, responded to way more than that, won more than my share mainly getting new clients, and assisted my RFP clients? managing their selected vendor?s (more frequently successful than usual) implementations many times.
Unlike most RFP participants, I?ve had the inclination and orientation to take advantage of my experiences, coupling with my legal training to analyze the acquisition process, learn the right lessons, and refine them into effective repeatable methodologies that I use with clients, write about including my Discovering REAL Business Requirements for Software Project Success book, and teach in public and private seminars.
Many if not most RFPs result in failed projects, which invariably are blamed on the selected vendor. As Chip?s article accurately implies, inevitable failure is created usually and unknowingly by the RFP issuer. Capable vendors stay in business in large part because they compensate for buyers? deficiencies; but this also builds many vendors? (somewhat deserved) reputations for over-reaching.
The biggest cause of RFP failure is the buyer?s inadequate definition of their own REAL, business requirements, which are what the vendor should be proposing a product and/or service to satisfy. Instead the buyer tries to specify the expected product or system, which often turns out not to be what they actually need.
Such mistaking a product/service for one?s requirements is common in the software (and other) industries but often is aggravated by RFPs. For instance, many buyers mistakenly assume the vendor will know their requirements, and too many (soon to fail) vendors fall into the trap of believing they indeed do know perhaps better than the buyer what the buyer requires. In other cases, RFPs are simply thinly-veiled efforts to get around an-intended-to-protect-them formal buying process, usually in order to buy a particular product the buyer already has decided upon, which too often turns out not to be what's really needed.
The successful vendor responding to an RFP is one who not only wins the business but also delivers promised products and services that actually meet the buyer?s needs.
I?ve found the key to vendor success starts with focusing on the buyer?s REAL business requirements, showing specifically how the vendor?s products/services will satisfy them, presenting an informed task plan that understandably will deliver on time and in budget, and then carrying through as promised.
Unlike most RFP participants, I?ve had the inclination and orientation to take advantage of my experiences, coupling with my legal training to analyze the acquisition process, learn the right lessons, and refine them into effective repeatable methodologies that I use with clients, write about including my Discovering REAL Business Requirements for Software Project Success book, and teach in public and private seminars.
Many if not most RFPs result in failed projects, which invariably are blamed on the selected vendor. As Chip?s article accurately implies, inevitable failure is created usually and unknowingly by the RFP issuer. Capable vendors stay in business in large part because they compensate for buyers? deficiencies; but this also builds many vendors? (somewhat deserved) reputations for over-reaching.
The biggest cause of RFP failure is the buyer?s inadequate definition of their own REAL, business requirements, which are what the vendor should be proposing a product and/or service to satisfy. Instead the buyer tries to specify the expected product or system, which often turns out not to be what they actually need.
Such mistaking a product/service for one?s requirements is common in the software (and other) industries but often is aggravated by RFPs. For instance, many buyers mistakenly assume the vendor will know their requirements, and too many (soon to fail) vendors fall into the trap of believing they indeed do know perhaps better than the buyer what the buyer requires. In other cases, RFPs are simply thinly-veiled efforts to get around an-intended-to-protect-them formal buying process, usually in order to buy a particular product the buyer already has decided upon, which too often turns out not to be what's really needed.
The successful vendor responding to an RFP is one who not only wins the business but also delivers promised products and services that actually meet the buyer?s needs.
I?ve found the key to vendor success starts with focusing on the buyer?s REAL business requirements, showing specifically how the vendor?s products/services will satisfy them, presenting an informed task plan that understandably will deliver on time and in budget, and then carrying through as promised.
That's what an RFP is for: find someone who can meet the buyer's requirements. Good points.
Interesting read as I deal with a lot of RFPs but I am the 'prospect' (never been called that before!). These points are pretty much spot on.
Another piece of advice ... if the prospect gives you a rating model such as A - fully compliant, B - partially compliant, C - not compliant ... don't reply A unless you have the requirement fully met in an existing commercially available product i.e. not in development or beta testing (using software as an example).
Don't put A all the way as we know you are fibbing and you will be found out
Another piece of advice ... if the prospect gives you a rating model such as A - fully compliant, B - partially compliant, C - not compliant ... don't reply A unless you have the requirement fully met in an existing commercially available product i.e. not in development or beta testing (using software as an example).
Don't put A all the way as we know you are fibbing and you will be found out
... I'm helping one of my clients fill out an RFP response and they're asking me "How can we find a way to answer A on this one. We really need an A here." My response is, "first, you have to have an A, and then you can put one down."
It's like the dog chasing the car -- what would he do if he actually caught it?
It's like the dog chasing the car -- what would he do if he actually caught it?
I disagree with some of your comments about the technology component of the RFP... "but I?ve seen RFPs that specifically dictate certain database or operating system choices".... A client should clearly specify what technologies they want to see used in "their" solution. Ultimately, it is the clients solution, not the vendors solution. If the client's existing IT infrastructure is built on certain technologies, it only makes sense to seek out a proponent who will use them. As an example, we are an almost 100% MS shop with Windows Desktop, Windows Servers, MS Exchange and MS SQL DB and we let proponents clearly know we want a solution that uses these components and technologies. If a vendor brought forward a solution that used Oracle DB, Lotus Notes, Adobe AIR and some SUN Solaris servers we would not be interested.
How would a proposed solution from this RPF be supported. Two options.
1) $$Pay$$ the vendor (for ever and ever) to support it.
2) Acquire or invest in in-house expertise to support this new technology. $$$$$
In either case, the longer term cost of this RFP solution has just sky-rocketed.
Bottomline... A RFP solution implementation should not singularly chanage or drive the direction of your technology infrastructure no matter how much a vendor thinks that their solution is the 'best solution'.
How would a proposed solution from this RPF be supported. Two options.
1) $$Pay$$ the vendor (for ever and ever) to support it.
2) Acquire or invest in in-house expertise to support this new technology. $$$$$
In either case, the longer term cost of this RFP solution has just sky-rocketed.
Bottomline... A RFP solution implementation should not singularly chanage or drive the direction of your technology infrastructure no matter how much a vendor thinks that their solution is the 'best solution'.
I agree with you that there have to be limits on what technologies can be employed, but in my experience this is often taken to extremes. "We're an MS shop" says that they won't even consider putting in one Unix server even if it could save them a ton of money. I'm not saying that going non-MS would be the right call, I just think that failing to weigh the option is not being diligent.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
