SOUTH DAKOTA

SCHOOL OF MINES
& TECHNOLOGY

Search
Directories
Current Students
Faculty & Staff
Local Weather

ATM Guide to Generic Proposals

The Proposal: Because you don't get if you don't ask!

Effective proposal writing is your key to research success. Writing proposals takes considerable time and effort and a well-written proposal will show this effort by presenting a clear, concise and navigable overview of your intended project. Your proposal will not only serve to advertise your research agenda, it will also provide you and your team with the framework for your particular project's management plan when and if it gets funded.

Proposal Guidelines

The criteria for submitting proposals to funding agencies varies from one institution to another. Two such examples for submitting proposals are at the NSF web site http://www.nsf.gov/publications/pub_summ.jsp?ods_key=gpg and the NASA web site http://science.hq.nasa.gov/research/research-opps.html & http://www.hq.nasa.gov/office/procurement/nraguidebook/. (Note that NASA embeds its expected formats within the individual announcements).

For real world proposals, it is important to be responsive to both the Request for Proposals (RFP) as well as holding true to the agency's required format. Even changing the font or margin size to something too big or too small can cause a proposal to be disqualified. You should also always talk to the program manager about your proposal before submitting it. You can get both direct and subliminal feedback that can be the key to a successful review process.

Although most proposal formats vary in the manner in which the overall paperwork is submitted (e.g., budgets, approvals, current and pending funding), the gist of the proposal bodies are quite similar. Most proposals require the following in the project description: (Slightly sarcastic but brutally honest comments are in the parenthesis - they will the comments passing through the reviewers' heads as they read it!)

Abstract

The "one-paging" of your project. This is where the reviewer is introduced to your work. ("Should I even bother to read this?" "Is this relevant to the particular call?" "Am I qualified to evaluate this proposal?") Just as you must catch and hold someone's attention in the first minute of a request, phone message, etc, this section is key to your success in the subsequent sections!

The Project Description

Results from Previous Support

A Brief Summary of you Track Record with That Program. (Are you a safe risk?) For this proposal you won't need this unless you have explicitly done advance work in this area.

Background information: (Why should the reader and funding agency care? Do you know the key working and science issues?)

This section introduces the reader to your project. You should have a strong control on the literature of the questions involved. Quality time at the library is a MUST!

For starters, it's a good idea to hit the reader on the head with what you are planning to do up front. Do this in a single well-written sentence, and don't be coy. I have read a number of professional research proposals where I was still left after multiple reads, wondering what exactly this person was wanting to do and why.

From there, discuss the question you are trying to solve? (Clearly no one is going to give you money to not solve a problem.)

How has it been approached in the past? (Who has tired it before? How did they do it? Did it work? What makes you think it can be done better? Has one aspect of past work been ignored and if so, why does it need attention?)

HAS it been approached in the past? (Why hasn't it been tried before? Was it not possible before a recent developments? Was it possible but not effective or efficient?)

What is the summary of what you want to do?

Should the project be funded in the first place? (Is something of significant value going to come through this work. "How does this advance the frontiers of knowledge?" How is this valuable to the taxpayer?)

Why should that particular agency fund it? Solicited proposals are often very "mission oriented" with some almost looking like they are bidding-out a specific contracts. The Request for Proposal (RFP) will normally provide background information on the support documentation for that particular program and project. READ IT BEFORE EVEN STARTING WORK IN DEVELOPING YOUR PROPOSAL. Not only will it keep you from writing an "orphan" (a proposal-without-a-sponsor that is dead on arrival regardless of its scientific and technical merits), it will contain the magic words needed to bring the proposal into the pack of proposals that are recognized as relevant to that RFP.

Method of Approach (How you are going to tackle the problem?)

This section is a detailed description of the science behind what you plan to do.

What is the science approach?

What makes you think this is going to work? Some of this applies to the Background section as well.

What is needed to accomplish this?

What is the anticipated result? ("Always 'know' the answer before you ask the question")

Project Management (How are you going to carry out your mission?)

This is normally part of the main body of NSF proposals but NASA proposals can have this as section separate from the "Project Description."

Who is going to work in the project? Are they qualified and experienced in the work? For most class and thesis projects, this one is easy: it's you and you alone for this project!

How is the labor to be distributed? Are they well suited for each task? Once again, this is you. All you.

What infrastructure is needed for this project? (Do you have what it takes on hand to do what you propose? If not, how to you plan on acquiring it!)

What is your timetable for results? This is very important in real proposals and especially for this project due to the time frame! I recommend Gantt chart and a written section describing your timeline.

How are you going to disseminate this knowledge? (How do you plan to educate your colleagues and civilians about your discoveries? This contains the "Educational Component" required in many proposals these days.)

Bibliography

Just as you'd have in any paper, thesis or technical document. Make sure that all references cited in the proposal are here. Make sure they are correct.

Sketches of the Principal Investigators (PIs)

These are often our vita, in outline or prose form. (Who is this person and what has he done in the past to justify funding?) NSF now requires an rigid outline from for your vita that has your education, professional posts, strategically chosen publications and related professional activities. These should be no longer than two pages for the real deal. One page should cover you here.

Budget (They want how much?! Where does it go?)

For most local class-based proposals, you wont need this or the following sections. But for reference, project budgets are itemized by personnel, material, travel and other line items. This is what one revised budget section from a funded proposal looked like this. This section also contains information on overhead (how much money the university takes), how our salaries are calculated and how many man-months the investigators will be working.

Current and Pending Support (How much do these people have on their plate already?)

You won't need this either. But in a standard proposal for external review, this shows how committed you are at present and what you expect in the coming months. Pending support is normally included and should include this proposal. One can also use this to read between the lines as to the PI's general success in getting by using this section.

Facilities

Sometimes this section is embedded in the project description but NSF (afterwhich this guide is based) has this as its own seciton. This section is a simple prose outline of the operational facilities that will host the project. IAS has its own boilerplate discussing its facilities including the support staff, academic programs, computational cluster, the analytical chemistry lab to the T-28 aircraft. We normally take this boilerplate and "spin it" to emphasize what resources will be used in any particular project.

Letters of Support

Many projects will need help from colleagues or resources not specifically mentioned or directly under control of the PI. To make sure that such items and personnel references in the proposal are not "vaporware," it's often a good idea to include signed letters of support (scanned and inserted into the document) showing that these units and organizations are indeed on board. These letter of support should explicitly identify what support is being offered and leveraged (otherwise the letter may be removed by the program manager who oversees the proposals).

Endorsements

Once again, not needed with in0house ATM proposals. But for externally-funded proposals, this insures that there proper safeguards in place to make sure that the money will be spent properly. Though this last section of the proposal rarely impacts the scientific review of the proposal, both the funding agency and the contracted organization (the larger university) will be the ones actually handling the monies, not you, and for them, this section is critical. The funding agency needs to have confidence that auditing measures are in place to make sure that the funds are properly used. Fortunately, it's a boilerplate provided by Graduate and Sponsored Programs and fits most to all proposals we send out.

Reading Winning Proposals

IAS keeps all proposals on file. Your advisor can help identify several examples of good proposals (and maybe one or two that should never have been written in the first place).


Contact: William Capehart

This page has been visited 328 times since 04/03/2006
http://sdmines.sdsmt.edu/sdsmt/ias/courses/proposals Last Modified: 04/04/2006

 
     

© - 1994-2009 - SDSM&T - All rights Reserved.