There is a common misconception that developing a compliant proposal is relatively easy — you just follow the instructions in Section L of the Request for Proposal (RFP), the way Dorothy and Toto in The Wizard of Oz followed the yellow brick road.
But this is not necessarily true. What makes RFP compliance so hard consists of a whole host of things, administrative and/or technical, that have the potential to derail your proposal.
In the following paragraphs, we discuss those things, and the steps you can take to keep your proposal on the compliance track.
1. There are requirements in other sections of the RFP that must be met to develop a fully compliant proposal.
You will need to read the RFP in its entirety and create an annotated outline that addresses all requirements. Look for the following in other RFP sections: Security (facility, personnel, and data); Key Personnel (labor categories and position descriptions, including education, experience, certifications, security clearances, and U.S. citizenship requirements); Company/Work Location (within a specified number of miles of the customer site); Travel Requirements; and Government-furnished Equipment (responsibility for maintaining inventory), to name a few.
You must then address all requirements in your proposal in order to be fully compliant.
2. RFPs almost always contain ambiguous statements and conflicting instructions.
You will need to find a way to deal with the ambiguities in the RFP. The first way to deal with ambiguities is to ask the Government clarification questions during the Question and Answer period.
If the ambiguities cannot be completely resolved through the Q&A process, you will have to address them in your proposal to avoid the possibility of being found non-compliant.
An example of an ambiguity is an RFP that contains 65 Performance Work Statement (PWS) elements and Section L requires that 22 of the 65 be addressed in the proposal. However, Section M states that the proposal will be evaluated on the offeror’s capability to perform all 65 PWS elements. A possible solution to this ambiguity is to address more fully the 22 PWS elements and develop short responses to the remaining 43 elements so that the company’s capability to perform all 65 elements can be sufficiently evaluated.
Grab a copy of our KSI Advantage Capture & Proposal Guide.
3. Section M (Evaluation Factors for Award) often contains requirements over and above what is provided in the Section L Instructions.
You will need to build answers to any unique evaluation criteria into your proposal response. For example, if Section M includes a statement saying that the Government will evaluate your ability to manage risk on the proposed contract and there is no requirement to discuss risk management in the Section L instructions, you will need to add a discussion of risk management to the proposal in order to be fully compliant and maximize your evaluation score.
4. It is often unclear where the Statement of Work or Performance Work Statement elements are to be addressed.
Section C (the Statement of Work or Performance Work Statement) is usually a separate document that describes the work your company or team is to perform to fulfill the requirements of the contract. Figuring out where to put all of this in the proposal is often a challenge.
Items that are clearly technical should be placed in the technical response in the section that tells you to “demonstrate your capabilities to perform the scope of work”. You can list the SOW elements in order or group them in some logical fashion, depending on available page count. Make sure that you identify the SOW/PWS elements by header and by number so that evaluators can find them and adequately score them, for example, (PWS 3.2.3, Help Desk Support). Non-technical elements can be placed in the management response (for example, program/project management, risk management). These elements should also contain headers and numbers similar to those in the technical section.
Additionally, there are some PWS elements which can be addressed in either the technical or management section of the proposal if no specific instructions are given as to their location. Quality Assurance/Quality Control is a prime example of this.
You can include a quality assurance discussion in the technical section as it relates to specific work to be performed (for example, software engineering) and have a more global discussion about your quality management process at the program level in the management section. However, all quality activities discussed in the technical section must support the overall quality management process in the management section and vice versa.
To absolutely ensure compliance, a little redundancy might be the best approach here, since it is conceivable that the technical and management sections of the proposal may be split in two and reviewed by different evaluators, both of whom may be looking for quality assurance information in their sections.
5. Your proposed technical solution cannot meet all requirements of the SOW or PWS.
Failure to meet the technical requirements contained in the RFP is a compliance issue that will most likely result in the rejection of your proposal.
One way to avoid this is to review the RFP as soon as it is issued, develop an Excel spreadsheet containing all requirements, and review the list to determine whether the company can meet all requirements. If not, you will need to find a teaming partner or partners who can meet the requirements your company can’t perform or you shouldn’t bid. Your teaming partners should be willing to help write the sections of the proposal for the work that they will be performing, since they have subject matter expertise and past performance in these areas.
Similarly, if the RFP requires a specific technical approach to performing the work with performance parameters that you or your teaming partners cannot meet, (for example, hardware/equipment with specific outputs/tolerances that your company doesn’t have), your proposal will be deemed non-compliant.
6. Your past performance lacks sufficient size, scope, and complexity similar to the work to be performed in the RFP.
Failure to adequately demonstrate that you have performed similar work on contracts of the size, scope, and complexity of effort required by the RFP, (i.e., relevant past performance) will also make you non-compliant and may result in the rejection of your proposal. If the RFP specifies past performance only from the prime contractor and you do not have the minimum number (usually three contract references within a three- to five-year period), you shouldn’t bid.
If past performance includes the prime contractor and subcontractors, you can use relevant past performance from your subcontractors to meet requirements, as long as subcontractor past performance, when combined with you company’s past performance, meets the relevance criteria required by the RFP.
7. Your key personnel and/or technical staff do not meet the labor qualifications, education, and experience requirements of the RFP.
Failure to meet requirements for key personnel and other technical staff can also result in the rejection of your proposal. To make sure your proposed staff meets requirements, develop an Excel spreadsheet with all the labor qualifications, education, and experience requirements for proposed staff, and review resumes against the spreadsheet to identify any voids.
Interview the proposed staff members whose resumes are deficient to see if they have inadvertently left important information out of their resumes that can be added to meet requirements. If, after the interviews, the proposed staff members are unqualified to perform work on the contract, new candidates with the right qualifications, education, and experience must be quickly located.
As a general rule, it is easier to ensure administrative compliance (adherence to instructions) than it is to ensure technical compliance (the proposal meets all RFP requirements). Technical non-compliance of the type discussed here cannot be “written away” by a staff of creative writers. Rather, technical compliance is best achieved through a robust capture process that identifies requirements early in the business development cycle such that the company and/or team can fill known voids and develop a clear strategy for winning well in advance of RFP release.
Similarly, the capture process can be used to identify requirements that the company or the combined team absolutely cannot meet, allowing for a timely (and appropriate) “no-bid” decision.
This article was originally published July 2014 and updated September 4, 2019.