I helped a small number of clients prepare responses to an information technology RFP issued by the Agency for Heathcare Research and Quality (AHRQ), an agency of the U.S. Department of Health and Human Services, after I posted notice of extension of the bidding deadline and increases to the maximum dollar value of the contracts to be awarded under the RFP. You can view my original post here, and you can view the actual RFP here.
The Project – This huge project involves work to be completed within four (4) major categories (“domains”), and the contracts within each category range from sizeable to jumbo. Skim the RFP yourself to get an idea of scope.
The RFP Document The RFP document itself (not including referenced forms, schedules, rules, attachments, etc.) is 190 pages long and available only as a downloadable document. This is my first criticism. AHRQ should have used an electronic document (eRFP) for this project. More on this below.
Order of Presentation – The first sixty (60) pages of the RFP contain federal procurement boilerplate. Fact is, potential respondents won’t care about any of the boilerplate unless and until they determine they are competent to bid on one or more of the contracts under the RFP. All of this boilerplate should have been placed at the end of the RFP document, or better still, in one or more separate attachments.
AHRQ would have served its needs better by starting the RFP document with a clear and concise description of the overall project and its subparts. Prospective respondents like to see an RFP summary early in an RFP document so they can quickly determine whether they have the high-level competencies necessary to respond. A summary of “category exclusions” would also have been nice. There is no need to force someone to read 80 pages before they figure out they don’t qualify for any work within a particular domain because they lack a critical experiential prerequisite.
Clarity – The clarity and comprehensibility of the RFP document is very poor (in my opinion). Even those well versed in the subject matter of each project domain would have diffuculty understanding the nature and scope of work to be completed for each contract within each domain. The true meat of the contract descriptions does not begin until p. 60 of the RFP, and if a potential respondent would even make it that far (very patient person), they would be disappointed. Where’s the meat? What is AHRQ trying to accomplish?
No Response Template – All of the clients I’ve helped respond to this RFP had the same major difficulty: there is no convenient way to respond. A respondent literally has to create its own method of responding, which means cutting and pasting RFP content, etc. With the technology available today, this is inexcusable. Again, an eRFP would have been the ticket.
No Response Checklist – For an RFP of this magnitude, and especially with all of the federal procurement requirements that apply, AHRQ should have provided a response checklist that covers all required items for any contract under any project domain, as well as required items that are contract-specific. With an eRFP tool, a response checklist is embedded. All required responses, including every required element of each response, are clearly stated, and respondents are prompted to complete entries needing their attention.
What’s the Lesson? – In the broadest terms, the lesson is this. If you want quality vendors to respond to your information technology RFP in numbers (your goal if you want to create a truly competitive bidding process), you have to construct a quality RFP. Tell vendors early on in your RFP what your particular project is about and what technical competencies are required. Also, you need to make it easy for vendors to respond to your RFP. If your process is too difficult or cumbersome, many will give up and never submit a response.
The Bad RFP – Consequences
- Reduced Vendor Response Rate – Fewer vendors will respond, and for two reasons. One, you’ve made it too difficult for them to respond. And two, a vendor might infer from your disorganized and cluttered RFP that you would not be a preferred client. They might sense they would have difficulty working with you. I assume AHRQ extended the deadline for responding to this RFP because it felt it had an insufficient vendor response to date.
- Adverse Selection – Quality vendors, those you want to attract to your project, are ususally busy (economic and market conditions obvioulsy produce some variance). They have plenty of work to keep them busy, and they might not take the extra time necessary to respond to your poorly constructed RFP. Lower quality vendors, those who are often less busy, just might find the extra time to respond to your RFP.
- Deficient Responses – The more difficult it is for a vendor to follow and respond to your RFP, the more deficiencies you will find among vendor responses. When you have to follow up with vendors by issuing follow-on questions and supplements, you increase your internal cost of adminstering your RFP. In the worst of cases, you might have to re-issue your RFP altogether, and if you do this, you may have a dismal response rate the second time around.
- Scoring Nightmare – A disorganized RFP begets disorganized vendor responses. By not providing a structure for vendor responses, a project sponsor will have a very difficult time scoring them.
Modern eRFX Tool – Second- and third-generation eRFX tools are perfectly suited to managing an RFP of this nature. Vendor inputs can be set up as defined-choice (checkboxes, radio buttons, etc.), narrative, or some combination of both. Vendors have the ability to upload attachments and manage their responsive documents within the tool. Additional required forms and addenda can be attached by the RFP sponsor, making it very easy for vendors to review and complete them when necessary. Vendors have an easy time responding, and the the project sponsor’s scoring effort is very efficient, with numerous and flexible scoring and weighting options available.
Comments – My criticism here of AHRQ’s RFP process is pretty harsh. I realize that. AQHR representatives may have several things to say in defense of AQHR’s process, and those comments are welcome. My goal is not to beat up on AHRQ, but rather to provide an opportunity for all of us who touch information technology procurement to learn. And that includes yours truly.
If you do not see a COMMENTS window below, click on the title of this post. You do NOT need to register in order to leave your comment.