Common Debrief Comments (And how to avoid them)
by Bob Fielder
I’ve reviewed scores, if not hundreds, of proposal debriefs over the past 15 years and some clear patterns have emerged. Below are some of the most common types of debrief comments that I’ve seen and some straightforward methods to avoid them.
“Failed to consider the complexities of the application”
You don’t know what you don’t know. By far the most common type of debrief comment stems from the fact that most proposal authors are not experts in the application to which they are proposing. You may have a great idea for a component or subsystem-level technology, but do you really understand the target operational environment? Do you understand, and have you enumerated, the technical risks that you will face? The reviewers understand them and you will lose credibility if you ignore or fail to mention a critical technical challenge or propose insufficient mitigation strategies.
Recruiting a subject matter expert (SME) to the team is invaluable in addressing this deficiency. Often, a prime contractor or system integrator can provide excellent SME support, as well as define system integration requirements. In other cases, including someone with operational experience in the field may be the best answer (e.g. for military or energy-related hardware). For medical-related proposals, having SMEs that cover every element of your project is critical.
“Weak commercialization strategy”
How will you get there from here? Very often, a commercialization strategy is written as: “Our widget is good for the XYZ market which is a $XXB industry.” And that’s it. This is insufficient. It’s not enough to simply cite the size of your target market. You need to describe specifically how you are going to enter that market. How will your technology be integrated into specific applications? Is your technology applicable only to new systems being produced, or can it be retrofit to existing systems? What are the costs and technical barriers associated with implementing your technology, and how does it pay for itself?
“Lack of detail in the work plan”
Don’t expect reviewers to believe you; convince them. It’s almost impossible to include too much detail in the work plan. It is critical to describe “how” you will accomplish each task. Describe methodologies and expected results in detail, leave nothing to guesswork. If you’re going to conduct environmental testing, then cite the governing reference and procedures, and list the equipment that will be used. If you’re producing a new material, then list the fabrication process in detail.
It’s also important to describe the scientific basis for each aspect of your project. Describe the fundamental enabling characteristics of your chosen methodology. What is the technical basis for your work? Cite prior research and design your work plan to build on that research to accomplish your objectives
“Failed to respond to the solicitation requirements”
Answer the mail. This is simultaneously the easiest error to avoid, as well as the most egregious to commit. The very first step to vetting any topic or request for proposal should be to break out each requirement individually and asking yourself “can we do this?” If not, then can you recruit the required expertise to fill in the gaps? Often, a specific approach will be specified in the topic description. Does your solution match that approach? If the answer to any of these questions is “no” then it’s time to walk away. Submitting a proposal that does not address the specified requirements will not only be dead on arrival, it will also damage your organization’s credibility.
When available, talking to the technical points of contact is the best way to avoid this error. Alternatively, you can also refer to other SMEs in the field to gain a better understanding of what the requirements mean, and how they originated. In the opening sections of a proposal, I like to cite each and every requirement individually, state that our solution will meet these, and (most importantly) state HOW our technology will meet each requirement. Reviewers are very busy, so don’t make them hunt for this information, highlight it up front, preferably on the first page.