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...

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

1. important

2. feasible

3. 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:

1. Selling Points

2. 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.