In almost any project, the path between “a good idea” and the “final exciting result” contained a proposal. It may have been a proposal to obtain access to scarce resources (like telescopes or accelerator beams), or it may be have been a proposal to obtain other more prosaic resources (i.e., money, to pay for the needed personnel and supplies). Whatever the nature of the proposal, however, I guarantee that the competition was ridiculously stiff, and that the odds of having any given proposal accepted were quite low (for reference, in most astronomy contexts, over-subscription rates tend to be factors of 5-10). These unfavorable odds can be incredibly demoralizing. They also can have profoundly negative impacts on a talented scientist’s career, if the odds never manage to tip in their favor.

Given the inspiration of the looming Hubble Space Telescope deadline, I thought I would share some of my “big picture” views on crafting successful proposals, expanding significantly on the more succinct advice given in an earlier post. While I’ve developed these opinions based on my experience in astronomy, I suspect they’d apply to many other fields, both within and beyond science. So here goes…

A Proposal is a Highly Structured Rigorous Argument

In its most abstract form, a proposal is a piece of persuasive writing that lays out a convincing case that the proposed research is:

important

feasible

efficient

By “important”, I mean that the project must rise above the level of “good to do”, and instead be seen as “must be done”, even by people who don’t work in the field. By “feasible”, I mean that there must be a clear path to a definitive scientific result. By “efficient”, I mean that the particular approach you’ve taken is the optimal one for reaching the important goals you’re targeting (i.e. aim for “Studying X provides the cleanest test of Important Science Y” and avoid building a proposal to study X when studying Z is clearly a more direct approach to Important Science Y — even if you worked on X for your thesis.)

You should lay out your arguments for Every. Single. One. of these cases before you write a single word of latex. Why? Because proposals live or die not on the beauty of your prose, but on the structure of your argument. If the reviewer does not believe that you’ve made the case for importance, feasibility, and efficiency, you’re done.

Here’s how I do this. Although I’m sure it will seem remedial to many of you, and reveal me as the anal geek that I am, I start a stupid ASCII file with two sections:

Selling Points

Potential Weaknesses to Shore Up

I then start filling out each with short bullet points listing every possible argument for or against what I’m proposing.

The selling points should be fairly easy, since you’re likely to write proposals for things you are inclined to think are awesome. Do, however, avoid the pitfall of conflating “important to me” with “important to Science”. Just because you would really like to know more about some property of something you’re interested in, doesn’t mean that other people will naturally share your enthusiasm. Keep your eye on the big picture.

The “Potential Weaknesses” section can be a bit trickier, since you need to channel your inner crabby reviewer. Think of every nit-picky, outside the box criticism one could throw at your idea, and every area where a reviewer could get confused. (As an example, here’s a list of some of the self-criticisms I came up with for an HST proposal for NIR observations of nearby galaxies a few years back: “What about AO from the ground?” “Why this many targets — how many do you actually need?” “What about dust (i.e. is 1 NIR filter OK)?” “Are the models really in need of improvement?” “How can we claim to do galaxy science while simultaneously arguing that the models aren’t yet up to it?” “Are the results confused depending on fraction of O-rich vs C-rich AGB?” etc).

In short, the “Selling Points” section is about demonstrating “importance”, and the “Potential Weaknesses” section is about assessing “feasibility” and “efficiency”.

After you’ve got an initial list, you have to step back, evaluate, and edit.

Go through the selling points and prioritize. Decide what the “main message” of your proposal is, based on which bullet points speak most effectively to the larger importance of what you’re proposing. If your ideas are strong, you’ll usually find that several of the most compelling bullet points will group together and can be ordered to tell a single story. You’ll also find that some of the bullet points will not naturally fit within that narrative. Identify this subset of arguments that are “nice, but not compelling”. You’ll want to be sure to minimize these in the proposal, to avoid their distracting from a more central idea. I speak from experience when I say that you really do not want to confuse the reviewers about what your proposal is about (i.e. It’s better to have something like “Dark Matter! Dark Matter! Dark Matter! and by the way it also tells you something about planets, frogs, and quark stars” rather than “Dark Matter! Planets! Frogs! Quark Stars!”, since the latter leads to complaints from the reviewers that while they believed your dark matter ideas, you had not fully fleshed out a compelling case for the frog science.)

For each entry in the “Potential Weakness” section, write down any brief ideas about addressing those concerns (something like “Make figure showing evolution of models with time” “Check number of stars expected and compare to sizes of Galactic samples”, etc). You don’t have to come up with definitive answers, but you should lay out a road map for what you need to do to make your experiment look feasible and efficient.

At this point, I sometimes make a third section and list a few figures that seem like they support the key scientific ideas, or that shore up some of the obvious weaknesses.

Now that you have this silly little ASCII file (which you shouldn’t spend more than a day on, if that), send it to your collaborators. Get their feedback about what they think the strongest selling points are, what their additional concerns are, and what arguments they would use to shore up weaknesses. Expand the file accordingly, so you have a record of everything that you think needs to go into the proposal. You’ll probably find that it’s a huge time savings to get this to your collaborators in this form, before you have a 10 page latex file with embedded figures. If you do the latter, your collaborator will likely come back and say “You know, I think the reviewers are going to be way more interested in frogs”, at which point you have to chuck out weeks of work. With this method, you get feedback quickly (since they have to skim a very short list of bullet points), and you don’t have a lot of sunk costs if you decide to overhaul the arguement.

At this point you’ll have a document that summarizes your rhetorical argument. Your case will be laid out so that you can easily evaluate it on its scientific merits. So, before you dive into writing, you need to step back and decide if you’ve actually constructed a strong case. Sometimes, it will become obvious that there are too many weaknesses to address, and that it’s going to be an uphill battle to convince anyone that this needs to be done. If that’s the case DON’T WRITE THE PROPOSAL! I have probably a half dozen of these ASCII files where I spent half a day deciding that I didn’t, in fact, have a compelling project, and I’d be better off investing my time elsewhere. That’s OK! The exercise of structuring your argument first is designed to be fast, so you don’t sink much time in before you decide whether to continue or not.

Once you (and your collaborators) are convinced that you do in fact have a strong case, you need to start building the actual text. I frequently will estimate the number of paragraphs I expect to have for my scientific justification (usually 2.5-3 per page), and then make an enumerated list showing how the argument will flow through the paragraphs. This exercise helps to keep the text following the structure of the argument, so that it builds to make the main points. It also helps me to figure out when I’m trying to cram too much information in.

If you’ve gone through all of the above, you’ll find that the proposal will almost write itself. You will have cleanly separated “generating text” from “generating a compelling project”, such that you know exactly what you want to convey, and what the text needs to accomplish. Generating lovely English sentences at this point is much easier.

Great advice. I’m in the midst of writing a proposal and this post solidifies things that have been swirling around in my head, thank you!

http://gnomonicablog.com Fernando Curiel

Find it very similar to what I try to do on proposals (we are physicists I guess) with a few twists. The most important is that I need to do a step back for a couple of days: Might be inefficient but it is usually enlightening about a blind spot that is not evident, even to your collaborators, on the first run. This is frequent when all of you want the same thing… Great post, at least I am not the only anal geek around…

Egad. Brilliant, but, egad! Your proposal outline process is much more detailed and better than anything I’ve done, I just have side comments. In the face of high oversubscription rates, like 1/5 to 1/15, and panelists who just don’t have time to read the proposals in great detail:

– Somebody on the panel has to love the proposal for it to get close enough to the top. You want it to be in the must-do, unique capability category.
– Don’t get bogged down in the details. You do need to nail down the feasibility and dispose of possible weaknesses, but tell a story. Too many proposals are about the properties of Thing X without reminding the non-Xists why they should care about Thing X.
– Don’t put the kitchen sink into the proposal. It gives the reviewers something to argue with.

Also, don’t get teed off when the proposal gets rejected and the comments are moronic. Everybody gets those. It is incredibly annoying, but the main reason your proposal got rejected is that nobody really loved it. Then somebody on the panel wrote down some comments that don’t make sense because they didn’t want to write “I’m sorry, I just didn’t love your proposal enough.”

At the same time, if you’re reviewing MY proposal, I don’t want to see those moronic comments from last cycle!

http://mingus.as.arizona.edu/~bjw Ben

Also, long after the proposal is accepted and the project done … I have a (very intelligent, cannot ignore) collaborator who reliably comes back with the comment on nearly-finished paper drafts, “This is very nice work, but what we really need now is a detailed study of frogs instead.” Do you have any tips on _that_?

And yeah, looking at it all written up like that, I’d say “Egads” too. But really, it’s less than a half a day of work, and frequently less if you’ve been mulling the ideas over for a while.

http://www.grantpros.org Jason Shechtman

As a career grant writer, I must say – this is an awesome tactic! Thank you!

John R Ramsden

If you have collaborators, wouldn’t it be a good idea for everyone to start by doing this exercise in isolation, and then comparing notes and merging the best results of this joint effort?

After all, many heads are better than one, even if it may be better for one person (“you”) to be responsible for the final proposal, to avoid a possible detrimental “designed by committee” effect.

Torbjörn Larsson, OM

Bookmarked!

“wouldn’t it be a good idea”.

I was _very_ tempted to say that you could start a stupid ASCII file filling it with selling points and potential weaknesses over any proposal for how to do these methods. So much so, that I eventually gave in.

Sandra

“…you don’t have a lot of sunk costs if you decide to overhaul the arguement.”

Unsolicited Advice XIV: When crafting an article on how to craft a proposal, overall credibility will be diminished when the word ‘argument’ contains a superfluous ‘e’.