We always encourage our clients to focus on the reviewers. This means avoiding fatigue, creating an easy-to-read proposal, and developing a rapport with your program contact. Reviewers will ultimately determine the outcome of each proposal. For this reason, it is critical our clients pay attention to the reviewer’s needs and study the criteria for what reviewers view as a successful vs unsuccessful answer to each question within the proposal.
Writing award-winning proposals is tricky work. Even if you have followed all the rules and accurately filled out each required section, whether you get funded or not still comes down to the final decision of the reviewers reading your proposal. Reviewers are human and as a result, can experience burnout. Proposals, depending on the type and agency, can range in length from 20 pages to over 100 pages. Reading even five of these in a submission window let alone 50-100 can cause reviewer’s eyes to cross in what is referred to as “reviewer fatigue”. Applicants have no way of determining or influencing the order in which their proposal will be read or the reviewer that will read them. This makes it imperative to guard against common mistakes that contribute to reviewer fatigue and offer a clear, concise proposal that addresses all reviewer questions. For best results, be direct and focus on these five aspects when creating your proposal: Who, what, where, when, why, and how.
Reviewers need to know who is doing the work and what makes them qualified to do so to put their stamp of approval on a proposal. Determine your team early and speak to their experience and credentials in the proposal. List who will be doing what task, who each team member reports to, and their specific role and responsibility within the project. Always identify all team members by name. If you have to change personnel later on there are methods and forms you can use to do so with relative ease, but “to be determined or to be hired” for a position instead of a designated employee will instill far less confidence in a reviewer. Try to avoid leaving positions open even if it means changes down the road.
Tell reviewers “what”
It may sound obvious, but be sure to include what you are doing in your proposal. Many applicants spend too much time defining the problem and the shortcomings of the current industry standard when what reviewers are really interested in is what activities the project entails and the minimum viable product that will be the outcome. Be sure to clearly indicate what your idea or product is, what you will be testing to determine success, and what the end result will be.
List the primary performance site where activities will take place. This is mandatory in 100% of proposals. The majority of proposals will also anticipate a detailed list or summary of the resources and equipment at that location. What do employees have access to at this site? Are there nearby resources like additional labs, research hubs, or university affiliate programs that can be used to augment research activities? In addition to listing hardware, be sure to list software programs the team will use to complete the activities. Include CRMs and workforce platforms like Asana, survey programs like Google forms and Salesforce, and virtual meeting software like Zoom. Yes, “remote” is a performance site. Just be sure to list what each remote participant will use to do the work and how and how often the team will collaborate.
Most funding opportunities have a window of time in which project activities are expected to take place. This varies widely by opportunity but one constant remains-reviewers want to know how you have blocked out time to accomplish all activities within the stated project window. It is best to break out anticipated activities by month to allow insight into your work plan. Having a timeline makes the project appear more organized and well thought out and reduces any questions reviewers may have about activities being completed in a timely fashion.
Tell reviewers “why”
As with “what” this may sound obvious and remedial, yet it is often overlooked by applicants. Why is this project or product important? Is there an unmet customer need? Can it benefit society or industry in some manner? Reviewers need to know why the project matters. If there is any question as to the logical reasoning behind carrying out the activity the reviewer will likely score that proposal poorly.
This is both the most important and most overlooked answer in proposals. How will you determine proof of concept? How will you measure success? What experiments will be used to determine the success of the project? It is not enough to simply say “the team will test product function”. That implies absolutely nothing. Will ergonomics be tested? Will the accuracy of an algorithm be tested to determine if it reaches a certain level, say 85%? If you are using a model or equation show your math. If you are using a certain type of test, name the test. If a subcontractor will be performing some of the testings, state where, when, why, how, and for what cost.