Blogs

Those darn RFPs - can’t live with them and can’t live without them. A friend sent me a blog about RFPs and how they are useless and a waste of time. The writer of the blog goes on to say that companies that write RFPs usually don’t understand the technology they are writing an RFP for and the “so called requirements are bogus;” companies that write RFPs steal ideas from the proposals they receive so therefore you need to careful about what is in your proposal; and vendors that win RFPs are generally the biggest vendors in their field and already have a “lock” on the deal. Jeez Louise…like I haven’t heard this before. (BTW, I have written a book on writing RFPs (http://tinyurl.com/3z4doyv), and I have written many RFPs, so I consider myself somewhat knowledgeable.)

An RFP is a process – a starting point so to speak – that a company will use when they want to have different opinions and solutions presented to them. It is a given that the company writing the RFP may not fully understand the technology and all that goes with it. Vendors should recognize missing or poorly stated requirements as an opportunity to begin the dialogue and to explore with the potential customer what the business problem is that they are trying to solve (through the question and answer period and then in the presentation and demo period).

I’m not sure what the alternative to an RFP could be but I do know that any complex purchase, such as an ECM system, needs at least the following (whether in an RFP or not):

1. A set of business, functional, and technical requirements. Without these types of requirements defined and used to baseline the project, there is no starting point and consequently no finishing point. As a vendor I would have mixed feelings about entering a contract with no requirements or loosely/poorly defined requirements. No matter what I did (as the vendor), and how I justified it, the customer will at some point begin to question whether something was really needed or if I was just gilding the lily at their expense. And the trouble will start………
2. A project plan. Without a good understanding of the actual technical requirements, it would be difficult for the vendor to do a project plan. Without a defined and agreed to project plan, the implementation will quickly deteriorate and lead to many problems for both the customer and vendor.
3. Reality based pricing. Without the solid technical requirements, which lead to a project plan, there can be no real pricing. How many companies are willing to give a vendor a blank check? How many vendors would get nervous not knowing whether the budget was $200K or $800K?

The RFP process can work well and can achieve the results needed if both parties understand and participate in the RFP process. On the vendor side, if the RFP doesn’t make sense or has some glaring holes in it, ask questions. Most RFP writers (including me) welcome questions and use the questions to further their understanding of the technology. The number and type of questions about the RFP can also help you (the vendor) to understand how well informed the RFP team is and this will help you to fine tune the writing in your proposal. I followed a simple document imaging RFP and there were over 150 questions asked (mostly technical), which made me understand how poorly educated the RFP team was and what hurdles they were trying to jump over.

As a vendor, I would have used this information to write a “teaching” proposal (for the RFP with so many questions) in which I provided more explanatory material than normal, perhaps provided more background material in an appendix, and ensured that any complex technology was broken down into its component parts. In other words, “Hey, I’m here to help - not make you life more difficult.”

As to RFPs that are poorly written? Without a doubt there are poorly written RFPs as well as good RFPs. The blogger who wrote about how bad RFPs are may not take into account that RFP writers are generally the people who do the business operations (the workers and supervisors) and the IT department and both groups have their regular “day” job in addition to being on the RFP team. Compare this to the vendor’s sales team whose sole and only mission is to know the product, know the customer, know the many and varied applications, and sell the product.

For the vendor, remember that a good proposal will only get you in the door and to the next step, a bad proposal will shut that door.

But we still have the basic question, is an RFP really the best instrument for purchasing large complex systems? What are your thoughts on this?

Bud Porter-Roth
www.erms.com