Many RFPs don’t simply and directly state, “Use the following header pattern in your response to the narrative questions.” Why don’t funders tell applicants which header pattern to use? Bureaucracy, legal requirements, funder indifference, signaling: whatever the reason(s), we’ve run into a bunch of program RFPs recently that don’t explicitly state what headers should be used (like the Small Business Innovation and Research grants (SBIRs) we wrote about last week). In structuring responses to confusing RFPs, there are two main schools of thought: one is to use the general headers found in the RFP, and then reply to all the sub-questions in paragraph form. The other school of thought is to use the general headers and every sub-header found either the narrative instructions (if there are any) or the review instructions (if there are any of those). Neither approach is necessarily “right.”
The recent ACF Early Head Start (EHS) RFP, for which we just wrote a proposal, offers a good example of this challenge. Like SBIRs, the EHS RFP has, bafflingly, two sets of narrative instructions: on Adobe page 35, under “Approach” and the other on Adobe page 57, under “Application Review Criteria.” Neither is quite canonical—in other words, the instructions don’t say, in big bold type, “USE THIS HEADER SET.” Instead, ACF offers maddening ambiguity. Perhaps this maddening ambiguity is deliberate, but is more likely due to this fact: the folks who write the RFPs never write the proposals in response and, as bureaucrats, likely they simply don’t care.
Regardless, one has to decide whether it’s better to use just top-level outlines, like “1. Community Need and Objectives, 2. Program Design and Approach,” or sub-header outlines, like “1. Community Need and Objectives, a. the proposed service area and location(s) where services will be delivered.” We chose to mostly follow page 57, while still referencing material on page 35. As with SBIRs, though, there is no 100% right answer, because neither the NIH or ACF give applicants one—but both could reject applications that don’t follow the weakly specified instructions.