We have been taught growing up that there are two sides to every story. This has never been truer than in the realm of grant applications. Without rehashing all of my college psychology and communications classes, there are basically six parts of a communication thread: the sender, the idea the sender wants to communicate, the encoding of the idea into verbal or written communication, the receiver, the decoding of said message by the receiver, and sometimes, feedback from the receiver to the sender. In the case of writing grant applications, we really do not receive proper feedback. All we know is whether or not we are being awarded. But let us not concentrate on the feedback part yet, we cannot control that. What we can control, is how we encode our message (application) so that the receiver (Peer Review) decodes it properly.
The idea in the case of our grant application is why we chose the project that we are applying for, and why we believe that it meets the highest priorities established by the program. Where most people get lost is in the so-called encoding of that message, i.e. the narrative of the application. It is not for a lack of trying; many times the reason is emotional. Very few people have to write out their feelings or justifications. Most communications nowadays is done verbally, and there is constant feedback during verbal communications. The message sender can read the body positioning, eye contact, and of course listen to verbal feedback from who they are talking to. Written communications are different because there is no chance for the intended receiver of the message to read it with the emotion that it was written in, nor understand completely the context in which the message was sent.
So how can you overcome these communications traps? Fortunately, I'm not here to teach a writing course, there are far more qualified individuals that can do that for you. What I can do it point out some of the easier methods for ensuring that your communications are effective in conveying your message.
- Have your facts straight.
Nothing destroys the logic of an argument faster than flawed data. While not all reviewers are guaranteed to be veteran firefighters, they are from this earth. You don't have to be an expert on a subject to realize that something does not make sense when reading it. With the limited time that the reviewers have to look over your application the last thing you want to do is confuse them, or cite something they know not to be true. Hopefully everyone took care of the research and avoided this pitfall as suggested by my first article.
You should start with an introduction to the department. This establishes a bond with the reviewer and allows them to get a mental picture of who you are, where you are, and what you do. But try to keep it brief. Avoid too much department history by explaining who founded the department, where, and why. The department was formed to provide fire protection where none existed before, this is a common fact about all fire departments. As proud as you may be of that heritage, that's not the purpose of the narrative. You don't want to detract from your true message of explaining your current need and why your solution is more deserving than the rest. While history may have something to do with it, nearly every department in the country started out poor and with little equipment, but it all depends on how that situation was managed. You don't want to take the chance of losing the interest of the reviewers before they even get to the meaty part of the narrative.
The next section can either be just a description of the project by itself, or a description combined with the benefits of the project and the problem the project is solving. It really depends on the project and the solution designed. As long as everything is clear, mixing the description and the benefits can be done very well. As you write, if you feel that coming back to the project benefits in another section would cause you to be overly redundant or reduce the clarity of the argument, then include the benefits as you describe the project. Clarity is a key part of the structure.