Do ya feel lucky today punk, well, do ya?
Clint Eastwood once famously asked this rhetorical question of an unlucky criminal who didn’t know how many bullets “Dirty Harry” had left in his gun. A bit rough for proposal work, but the metaphor holds–when it comes to compliance, are you going to let luck determine whether you comply with requirements or are you going to ensure that you’re compliant?
There is no one method to proposal management, writing, processes, or methodology. Ask 10 different business how to run a proposal project and you’ll likely get 10 different answers. And that is, as it turns out, okay. Some prefer the Shipley method, others prefer something a bit more flexible, but whichever proposal road one takes, there’s one thing that all proposals need to have in common to have a chance of winning, and that’s compliance with the requirements. That’s right: compliance. Sounds simple enough, right? But this is, in truth, where things can get pretty tricky.
What is compliance, after all?
Well, that all depends–not only on the RFP, but on customer expectations (which aren’t always the same as evaluators’ expectations). Those who work in the proposal business are often faced with myriad “shall” requirements, but they’re not always just in the SOW; these days they seem to be, well, everywhere and littered throughout the requirements documents. Do you address all of them? Again, that depends. Today’s procurement requirements tend to be pretty chaotic and unstructured, and that means that the old model–where Section L=instructions, Section C=SOW requirements to be addressed within Section L framework; Section M=evaluation factors–doesn’t always apply. I suggest that you attempt to address them in one way or another–if there’s room, address them specifically, if possible (that’ll leave no stone unturned). With some of today’s draconian page limitations, however, you may be limited a “blanket compliance statement” that you comply with all requirements up front, and address only the SOW or “task” requirements with specific solution explanations.
But what does that entail?
If you’re dealing with a Lowest Price, Technically Acceptable (LPTA) procurement, compliance can be a simple process of providing “shall” to “will” responses (i.e., no persuasion required other than a low price). If you’re dealing with an RFP that is evaluated based on more than price (i.e., technical, management, past performance) you generally need more just a “shall” to “will” response. Some RFPs specifically call out this requirement. I recently worked on an RFP with instructions that stated “Phrases such as ‘standard procedures shall be employed’ or ‘well known techniques shall be used,’ without a specific Government or industry reference, shall be considered inadequate and unsatisfactory.” In simple terms, the government is saying “provide a detailed explanation of specifically how you comply with requirements (including benefits of your solution to us).” Doing anything else puts you at risk for submitting a non-compliant bid.
Great! … How do I do that?
One of the first things to do when you start a proposal is to determine where all the “shall” requirements are and how to address them. It’s not always easy to find them all, but one approach is to take the RFP document(s) and search and replace all “shall” requirements with bold, upper case versions with the word SHALL and then sending out this updated version of the RFP to the team. This will help determine what’s important/required by the customer by providing your team with a “new baseline” set of requirements make it much easier to see what’s important to the customer. As a team, you should also set a baseline what what constitutes a compliant response (something that typically comes to light of day–for better or ill–during the first review). Determining what compliance is can be challenging, but it’s something that every team should agree on–unfortunately, it’s not always straightforward. Insight from the customer, knowledge of the evaluation team, previous bids with the same customer–all of these can be useful for knowing what’s really important to the customer and what’s considered compliant. Without this insight, it’s better to be safe and address the shall requirements with as many relevant specifics and benefits of your solution as possible. In another post, I’ll explain how you can address “shall” requirements in your proposal template.
So remember, take care to address the “shall requirements with specifics and benefits. Otherwise, you’re just relying on luck for determining compliance and then you have to ask yourself one question: do you feel lucky enough to be compliant…well, do ya?