Following up on a post a couple weeks ago about applying for U.S. government grants, I had the pleasure of putting together an NSF ITEST grant application with about a dozen colleagues. Briefly, ITEST is:

The Innovative Technology Experiences for Students and Teachers (ITEST)* program was established by the National Science Foundation in direct response to the concern about shortages of information technology workers in the United States. The ITEST program funds projects that provide opportunities for both school-age children and teachers to build the skills and knowledge needed to advance their study and to function and contribute in a technologically rich society. The ITEST program also funds a National Learning Resource Center to support, synthesize and disseminate the learning from the program to a wider audience.

This is a fairly ambitious project, about US$1.5 million over three years. We assembled a collaborative group consisting of a senior professor at a local college, a couple of non-profit executive directors, a local economic development guru from our mayor’s office and a local school board president. All of these folks will get a piece of this grant. We used BaseCamp as our project manager.

Our applicant organization of record was the Vermont Software Developer’s Alliance. This is the organization which, if we receive an award, will administer the grant. This is no small responsibility, and we included a full-time program manager/curriculum developer as a staff person for vtSDA within the grant application.

Grant writing is “on spec” or speculative. You don’t get paid upfront for writing grants. This makes the whole proposition quite a gamble, and the investment in time and aggravation can be significant. I recall being somewhat taken aback when a fellow applicant told me that, for his SBIR Phase II grant application, he had two staff people working on it for three months. This was significantly more time than we put into the ITEST application, and my guess is that it will show. The process wasn’t entirely smooth, and here are ten things I wish we had done better.

1. Start Early. I wish we had started earlier for a project of this magnitude. Six months is not unreasonble, 12 months would have been even better. The reason for this is that to successfully compete for grants of this magnitude, you need a program. If the program doesn’t exist, (and why should it, that is why you are looking for grant money), you have to essentially imagine the program in sufficient detail to be able to coherently describe it. Grantwriting is essentially a sales job, and you have to have a value proposition and/or a product to be able to sell.
2. Exploit the strengths of your the software. BaseCamp has strengths and weaknesses. A notable weakness is the word processor; it is fine for light work but not helpful for the kind of formatting with tables, illustrations, references and footnotes that a proposal requires. On the other hand, BaseCamp has a useful task list, which allows you to list parts or chunks of the proposal as tasks, and attach a “person responsible” and deadline for the task. This is quite motivating.
3. Have a designated boss. One of our issues was the application couldn’t have come at a much worse time; all of us were deeply into other projects, and of course it is tax season. So no one stepped up to be the boss, we worked more or less as a weaker collective. The boss really needs to have some time to invest, (100 hours or more?) if he or she is going to truly have the whole project scope on their radar. This makes it tough for volunteers. For those who prefer a less hierarchical title, maybe “shepherd” would be a better designation than “boss”.
4. For BaseCamp users, exploit the BaseCamp “revision system”. This allows you to upload revisions of previously existing files on top of the older files, and which preserves the older version file. You can add notes to each revision, so you can see at a glance what changes were made by each update. We didn’t entirely master this concept, and ended up with several dozen separate files scattered over a three page listing of files, when things could have been more compact. Sharepoint might work better for this, as it allows you to “lock” or check out a file, just like a real revision system.
5. Integrate the moving parts. Going back to the idea of the shepherd, somebody needs to take the individual components of the proposal and integrate them together so that they all fit. This includes the budget and budget narrative; if you describe a position in the program narrative, you need to make sure that the same title is used in the budget line item. In our case, we actually had no less than five sub-projects or sub-programs, all which integrate beautifully and complement each other. I hope were able to effectively illustrate how well they fit together and how each sub-program contributes to the overall project.
6. Stay on top of the grant guidelines and the website quirks. Turns out that the NSF FastLane site becomes the “choked commuter artery” several hours before the application deadline, even if the deadline is 5PM local time. If you are still trying to upload PDF files at 3 on the east coast, those lucky folks on the west coast are at it too, and it bogs down the server until nothing works. You don’t get much sympathy from the NSF at this point either, their advice is simply to start early and make sure you’ve everything uploaded before 2PM local time on the east coast.(Irrelevant aside: Is this a problem because java server pages don’t scale?)
7. Use Instant Messaging. I’m in Vermont in my home office. John is 30 miles away in his office. Peter is in Florida taking a day off from his vacation. Everyone has two or more phone numbers which may or may not work. We’re all working on this for two days before the deadline. Instant messaging to the rescue! We can say who “has” a particular file, or briefly find out what the status is of something or ask a quick question.

I’ll add the other three suggestions next time.