It was of some interest to me a couple of weeks ago when I read on the AIIM Expert Blogs some comments about Requests for Proposals (RFPs) and Bud Porter-Roth’s reply (http://www.aiim.org/community/blogs/expert/Those-Darn-RFPs-2524), with which I agree. However, as I am once again involved in another software RFP, and have responded to several this year, I thought I would stress a component for consideration that is important in the RFP “process.” That component is the role of the RFP as a communications playbook. Unfortunately, both sides, the issuer of the RFP and the respondents, often seem to use an RFP as a combat framework document. Kind of like the parameters (ropes) around a boxing ring. Each side is throwing some exploratory punches while they dodge the defenses of their opponent.
First, the organization issuing the RFP often tries to load the document down with every possible organizational “requirement” imaginable. I once received a 36 page RFP that had only 3 actual pages of functional and technical requirements! The rest of the RFP was about the history of the organization, the numerous largely irrelevant laws that the respondent must adhere to, many numerous largely irrelevant bureaucratic workflows, and considerable procurement “boilerplate” that seemed oriented toward eliminating small business from even taking an interest in the RFP. Was some of this relevant? Probably in the long run, but it was the first 33 pages of the document. The last 3 pages that described what the software must actually do were minimally specific and seemed to almost be an afterthought. It was a prescription for a disaster.
Second, vendors seem often to be completely out of touch with the sentiments and stated needs of RFP issuers. When told that demonstrations are to be only about the functional and technical components of the software and not corporate overview slides, they will send a marketing director to “impress” the potential client. This marketing director will often provide the usual corporate market share profiles or accounts of a dizzying array of bleeding edge technology available in their software options. But when asked specific questions about the software modules of actual interest, the sales person will answer technical questions with “I’ll have someone who understands things better get back to you.” This may even occur after the vendor “responds” to the RFP by copying and pasting boilerplate marketing “information” into their response that can often be found in white papers on their corporate Web site. Where is the communication? Both sides often fail in their respective roles.
Third, regarding software demonstration meetings, RFP issuers seem almost arrogantly insensitive at times to the time and energy it costs vendors to respond to RFPs and provide demos. I have seen RFP issuers provide completely inadequate connectivity for online demonstrations that guaranteed a vendor could not actually illustrate the software’s capabilities. And worse, I have often seen software vendors arrive to demonstrate to a selection “team” where those few individuals in attendance spent most of their attention time “multitasking” with laptops and cell phones in the demo rooms. This shows the vendors that there is no coordinated consensus of interest in the procurement and they may be wasting their time.
Fourth, RFP respondents often seem to have great difficulty illustrating with credibility that the software works and has been implemented. It seems difficult for them to find “references” or provide examples of software installed and working well. Obviously, it is easy to “burn out” references with excessive referrals. However, how can a vendor of a product expect new customers to welcome being the “guinea pig” that is used for implementation testing? Without any significant examples of the software being used, vendors should understand why potential customers may balk at buying what seems to be an untested system. Want to really make a vendor uncomfortable? Ask them how they use their software in their own organization and watch them squirm! Does this promote confidence on the part of software buyers?
So, there is plenty of blame to go around on both sides of the communication framework called an RFP. All involved parties need to do their part if it is to assist progress toward successful sales, procurements, and implementations.
John Phillips