I have just finished submitting a proposal to DARPA, the Defense Advanced Research Projects Agency, for my company Rocket Science Technologies. It was a long, grueling effort, first defining the technology and concept we were going to propose, assembling a team , writing the proposal, estimating the program/project, reviewing it, and then finally submitting. It was challenging, as proposals usually are. This one had its own particular difficulties because I had to put together a team not only to respond to the BAA, but who would also be available to work on the project should we win. My consulting company is built on a virtual basis. We have consultants scattered around the country. That wouldn’t work for the proposed program. We needed personnel who could work in a company lab to develop the required hardware. Fortunately, between LinkedIn and some networking we assembled a slam bang local team.

I consider myself a trained proposal writer and manager, having spent more than a decade with a company providing proposal training in support of their own internal proposal management system. I’ve also had training elsewhere with a similar process. The trouble is all of the training relies on the infrastructure of a centralized location, a department in the company (or supplied by an external consultant) that includes proposal and book managers (i.e., managers of the technical, management and cost volumes), editors, and illustrators, as well as a designated area isolated from the rest of the company for the team to work undisturbed. Unfortunately, in many of my recent proposal efforts, I didn’t have the luxury of that kind of infrastructure and support. Certainly not for this last proposal. Still, I think many of the lessons I learned in my formal training apply. It just requires a bit of ingenuity and perseverance to translate to a small team, or even to one-man band grant writer.

Here are some of the do’s and don’ts of writing a proposal/grant application I think you will find helpful that I’ve learned over the years:

Do: answer the question “why you or your company.” Don’t: do not write a technical treatise. One of the biggest mistakes engineers, scientists, doctors, and other professionals make is the belief that immense technical detail will sell a grant reviewer. Nothing could be more wrong. A proposal is a marketing document and is not a technical report. Its purpose is to convince someone to buy your services or product. Furthermore, the trend today is for page-limited, shorter proposals. The BAA I just responded to was for millions of dollars, and yet the page limit of the technical section was twenty pages. Even more telling, the section for describing our innovation was only three pages long. The remaining seventeen pages was a description of our approach to the problem, i.e., a mini-program plan, and a description of our team and its capabilities. The technical description is just a portion of what you need to win the grant. Remember, a request for a grant or proposal is usually issued to solve a problem the issuer has and can’t without your help. You need to convince the reviewer of the benefit of your solution and that you have the wherewithal to solve their problem. The answer is more than the technology. It’s you as a company or a researcher. Your background, talent, and past experience. It’s the approach you’re going to take. You must convince them they can trust you with their money. A technical treatise does not do that.

Do: create a theme. Creating a proposal theme is one of the first things you should do, even if it’s just you doing all the writing yourself. A theme contains customer benefit(s), feature(s) of your product/service/research that provides the benefit, and a collaboration that provides factual backup to prove your claims. Why is a theme important? Consider it your elevator speech, you know, the one you’re trained to give when someone asks you what you or your company does. A theme is a summary statement provided upfront to your customer that answers the question why you or why your company. It sets the tone and points the reader in the direction you want him or her to go. A theme also serves to focus your writing. Everything you do in the technical write-up should support your theme. It is also useful to write a theme statement for each of your major sections, again to focus your writing and to focus the grant’s reviewer on why you should be awarded the grant/contract. Answer the question why they should select you.

Don’t: Do not have the program/project manager/researcher manage the proposal. This was one of the things I suffered through on this last proposal. I was wearing both hats. If you’re a one-person band, so to speak, try to get someone to help with the details. The program/project manager/researcher is responsible for the technical content of the solution, the actual technical solution. The proposal manager is responsible for packaging the solution into a tight responsive document, ensuring it meets all the requirements of the grant RFP. On this recent BAA, because of the nature of the team I was wearing both hats. I found myself writing consultant non-disclosure agreements and consulting agreements while I was trying to writing the program plan and putting the proposal together Those were incompatible activities. Don’t try to do everything yourself, even if the grant seems small enough. Something will fall through the cracks if you do.

Do: make a plan and stick to it. Lay out a plan and a schedule and keep to it. You’ll be surprised how fast the 30 days allowed by the government for an RFP response passes. The plan doesn’t have to be a treatise. It can be a schedule, a proposal outline with page limits for each section, and assignments if others are working with you. (Don’t forget the themes.) You will find if you’re running a team that at some point you will need to say “no more technical work. Finish your writing for review.” There are few things in life that are quite such a hard stop as a proposal due date. Even for taxes you can get an extension. For most proposals you can’t.

Don’t:  do not skip internal reviews. Even if you’re a one-person band you need to have someone review the outline to make sure it meets all the proposal requirements, and to read the proposal at the end. Not just copy edit. It’s best if you can find someone knowledgeable but who may not be the expert in your specific field that you are. See if you can convince them that you deserve the grant. If they get lost in your technical jargon, most likely the requesting agency’s reviewers will, too. In addition, your internal reviewer may also help you make a salient point to support your position.

Oh, and good luck.