One Person, One Proposal: Don’t Split Grant Writing Tasks

Would-be grant applicants often look at the dizzyingly long, arduous road to a finished proposal and think, “There’s gotta be a better way than assigning one person to write and assemble the entire beast.” They consider the RFP for a while and hit on a brilliant strategy: divide up the proposal like you’re cutting a pizza! One person writes the needs assessment, another the organization’s ability to operate the project, a third the evaluation, and so on.

Don’t do this. It’s a fundamentally bad idea, like sailing near the Sirens on Sirenum scopuli.

The temptation to work in parallel when you should work in serial is obvious: less work for each person. This would make the proposal development process like an assembly line, where dividing up the labor will result in greater productivity. But writing a proposal is more like a novel or poem than building a car, as the unified structure of a single mind is necessary for coherence of form and unity of content. Very few novels are written by more than one person, and even fewer novels that are any good are written by more than one person; as far as I know, zero novels that are genuinely great have been written by partners or groups.

That’s because the novel would be written in different styles, each style would have a different aim, the characters would act bizarrely, one part would be lyrical and another part plot-driven, and whatever meaning might be derived from the novel would be a muddled mess. Good novels are incredibly hard for one person to write, and two people would be even worse. Committee reports are so notoriously boring that there’s a term for ideas that get expressed in them: death by committee. There’s another expression in a field where more opinions lead to worse outcomes: too many cooks spoil the broth.

So what happens to organizations that write proposals this way? If you divide up the proposal, the sections won’t match. The project description won’t mention how the project will tie into existing efforts because someone else did that section. The RFP may ask for the project’s goals in three different places, and each of those will be different. The evaluation and project description will stare at each other like Martians and Earthlings in the fairly good 1953 version of H.G. Wells The War of the Worlds. Writing styles will clash like Germany and Russia at Stalingrad—the result will not be pretty. If it were merely aesthetically ugly, that would be acceptable, but it will probably also be incoherent, which is not.

The same set of problems apply to revising. There is a temptation to give five copies to five people and let a single person or small group of people make those revisions, which will lead to problems just like those described above. That’s why we demand a single set of changes for each draft we produce, with no exceptions. In other words, we don’t want one set from the Executive Director, another from the Board President, and a third from the Program Manager; with all those corrections, we’ll a) waste a lot of time trying to understand them and b) get conflicting revisions from different people. If we didn’t work this way, the result would be proposals that are confused, choppy, and don’t make enough sense because they lack consistency.

Occasionally we get hired to straighten out proposals that have been written and edited in parallel, and we almost always get a mess that we edit for consistency as best we can, but the end product is almost never as good as it would have been if we, or a competent single author, had simply written it from the beginning.

Technology increases the temptation to split writing and editing tasks among many individuals, especially for people who work in tech fields and are used to collaborative software development. Such software is all well and good for many arenas, but it hurts more than helps for writing, where individual styles vary widely and so does content. There’s an entire discipline out there attempting to explain how to get software developers to work together; Fred Brooks covers the subject in The Mythical Man Month, Timothy Lister and Tom DeMarco mention it in Peopleware, Joel Spolsky and Paul Graham discuss it in various places, and version control systems proliferate because software developers need them. Famous ones include Subversion, CVS, and GitHub. They could all be adapted for writing projects, but they probably seldom should be because they’re more likely to be misused. They also bring an organization perilously close to the methodologies Spolsky mocks in Big Macs vs. The Naked Chef, which ought to be required reading for anyone who wants to split up writing tasks (notice that Spolsky uses cooking metaphors, which I also do in the fourth paragraph of this post).

With a proposal, you’re writing a novel, not an operating system. If no one in your organization can write an entire proposal on their own, you should hire someone who can—either a consultant, in which case you’ve come the right place, or an employee, who can write proposals over and over. There are pros and cons to each, which I’ll write about further in a future post, but having multiple writers in a single proposal is an unambiguously bad idea, which experience has taught us and other grant writers. In fact, it’s so bad that Isaac probably could have noted it in The Danger Zone: Common RFP Traps.

Some applicants—especially those staffed by people inexperienced in the grant development process, such as businesses seeking Department of Energy (DOE) grants—attempt to split proposals anyway, which is likely to lead to a disastrous result. This is one of those lessons that, like touching the hot pan, everyone seems to need to learn the hard way, but when they do, we’ll be standing by with bandages and skin grafts, depending on the severity of the proposal burn.

One thought on “One Person, One Proposal: Don’t Split Grant Writing Tasks”

  1. Pingback: The more you do it the better you get: Why Americans might not work less « The Story's Story

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>