Having prepared and responded to numerous requests for proposals (RFPs) across many governmental and nonprofit sectors, I’m always surprised by the amount of RFPs that do not include a proposal response format. When an organization has not included a proposal response format, it leaves the potential respondents scratching their heads. While a Q&A period can help alleviate some of the confusion, the answers often come too late to have a meaningful impact on proposal content and structure.

Proposal format can be broken down into two subcategories: (1) physical requirements and (2) proposal structure. Physical requirements are the mechanisms for ensuring that the proposals look the same and all responders provide the same amount of information. Proposal structure is the content and order in which the proposal is presented.

More often than not, I see that organizations are very specific with the physical requirements of the RFP response, such as typeface, font size, pitch, line spacing, margins and page count. While I appreciate precision, some of these technical requirements have carried over from the typewriter days and have no real application in the most common word processing programs. But, on a whole, most organizations provide enough physical requirements to alleviate guesswork among proposal respondents.

The proposal order is more of a mixed bag. Some organizations are very orderly and provide tables with fixed fields so respondents will only answer what is asked and respond in a predetermined fixed space. This gives organizations confidence that their proposals are being compared apples-to-apples with other respondents’ proposals. To be successful with this type of proposal, the responses require adept writers who are able to select and present the most pertinent information. There is no “see what sticks” approach to responding.

On the other side of the spectrum, there is no structure, and the RFP does not give the respondents a response order. Recently, I was looking at an RFP that had no determinable items for a proposal response. I could not discern between items that were to go into the proposal response and items that were to be delivered once the contract had been awarded. To frustrate matters further, there was no Q&A period to provide more clarity. These unclear requirements, coupled with a short turnaround time and no Q&A, means that the organization is going to receive a kitchen-sink approach from many respondents since none of the responses are going to be in the same order and none will address the same topics. Comparing responses will be unnecessarily difficult for reviewers.

A well-written RFP that includes both physical requirements and proposal structure is necessary for quality responses. Without a cohesive RFP, the organization will have an exceedingly difficult time reviewing responses side-by-side and ensuring that their requirements are met upon award.

To learn more, download our white paper, Lessons Learned From a Government ERP Failure.

Posts You May Like:

Rebuilding Trust After a Failed Software Project

Rebuilding Trust After a Failed Software Project

Failed software projects often disrupt operations and erode trust among employees, stakeholders, and clients. Rebuilding trust requires transparent communication, accountability, and a comprehensive recovery strategy. Transparent communication, employee engagement,...