RFP Part 2

In my previous posting, I expressed my view that the prospective vendor should be willing to participate in demonstrations geared to highlight specific functions or tasks. This time I'd like to expand that thinking.

In a traditional RFP, you provide a list of required features and functions. The potential vendors review the document and reply with an equally tedious document wherein they state what their solution does. If they have need for further definition, they send a request for information back to you and we start going back and forth until the particular issue is defined to the satisfaction of all involved.

This dance is repeated with each of the potential vendors you invite to bid on your project. Very time consuming for all involved. Of course, if you had brought on a consulting company for this process, they'd be willing to run this process for you; of course, you'd be billed for their time and efforts.

I've seen this process on several occasions where the RFP took on a life of it's own and the customer lost valuable time and money while the consultants and vendors went to the dance.

So, how do you get through this in a more efficient manner? There's a few things that you can do:

1) Do a very good job when you define the deliverable. Your RFP document needs to be very clear, contain no ambiguities and be realistic. Don't develop the package in a vacuum; enlist the cooperation of all departments who will use or bene3fit from others use of the solution.

2) Your consultant (if you are going to spend a few million dollars and/or change the way your business functions, you really need to bring in an expert) needs to understand the project; more than just understand it, they consultant needs to be fluent in speaking to vendors about your organization and the project.

3) Be prepared to push the vendor into demonstrating key functions early on. You just may be able to reduce the list of potential vendors by asking them how they intend to address specific issues.

Let me offer an example that illustrates that third point. A few years ago I worked on an ERP refresh project for a fairly large construction company. At the time there were 72 packages available that were potentially a fit for the client. It could have been a daunting task to process RFP responses from even half those on the list.

To reduce the list we first eliminated those packages that did offer certain processes we needed to cover. Next pass we removed those vendors who were not currently supporting firms of a similar size and market niche. Finally we sent a package to each of the remaining vendors an invitation package. We identified our team, the client and our goal. There were a few vendors who declined gracefully, admitting they didn't want to pursue the project at that time.

After 3 passes we had a field of 12 to work with. I felt that this was still too many so we developed a suite of specific tests; unique tasks that had we knew to be problematic. My thinking was that if they can't address these, we were no better off going with them than we were in keeping the existing package in place.

Of the 12, we dropped as they couldn't handle some of the payroll tasks we identified. Letting them back out of the project early on saved us both time and money.

Managing the potential vendor list early on shortened the project schedule by at least 3 months. We were able to keep the client's energy focused on planning for the migration and ensure success.

To summarize, the RFP process shouldn't be a long, drawn out affair. You need to clearly define the goal, communicate the details and work to narrow the list of potential vendors a quickly as you can.