Tag Archives: Research Grant

From an Idea to a Research-Project

You have a research idea. You would like a research grant to enable you to pursue your idea. What do you do?

A grant application is a request for funding to carry out a research project. In order to write an application you need to have worked out the details of a project. An idea, even a brilliant idea, is not enough. So here I deal with that missing link: I explain how to use a research idea to work out the details of a research project.

Research Project

The details of the research project are the starting point for writing a grant application.

Why the Detail?

There are two reasons that you need to include details about your project in your case for support.

  1. The funder needs to judge whether your project will achieve enough to merit funding. To make such a judgement they need to know what research you will do. Usually they will want a moderately detailed description of what you will do, when you will do it and how you will do it so that they can assess the likely outcome of the research in relation to the grant you are requesting.
  2. The funder needs to judge whether the grant you are requesting is necessary and sufficient to enable you to do the research. Typically they want to know what resources you will use to do the research and whether the resources will be provided by the grant or by your institution.

How to Work Out the Detail

The easiest way to work out the details of your project is to imagine that you already have a grant and are ready to start research. You can start planning your imaginary project straight away. You simply describe what you will do to pursue your idea until it delivers something that the funder will be interested in. You can use this approach to flesh out a vague idea or to catalogue the details of a very specific idea. The only rule is that you have to end up with a description of a project that the funder will judge is worthy of funding.

It is better at this stage to write too much detail rather than too little. You should try to include enough detail to demonstrate that the activity will definitely lead to the outcome you intend. Don’t get too hung up on specifics. Most funders are looking for a plausible description of how you will use the resources they will provide to do productive research, rather than a detailed set of commitments to do specific actions on specific dates.

As you write about the research activities, you should include information about personnel, timing and resources. Say who will carry out each activity, when they will do it and what resources they will use. You can use this approach to compile the list of resources you will be requesting in the grant, or if the resource-base is predetermined, to ensure that you will make effective use of it.

It will be important to divide the project into three parts, so that you have three work-packages to frame your PIPPIN sentences. You can choose whether you build the project from work packages or divide it into work packages after you have built it. Whichever you do, you should ensure that the work-packages are created by compiling sets of research activities that produce clear outcomes rather than lumping together activities that occur within a particular time-frame or in a particular place. This is particularly important in collaborative projects: if each work-package takes place in a different institution it can give the impression that the collaboration is just a smoke-screen.

How Not to Do It

It’s really important to avoid the trap of refining the idea before you generate the project. It’s an easy trap to fall into because it seems obvious that you need to refine the idea, clarify the hypotheses you want to test, establish the research questions that need to be answered, and so on. These are the starting points for the narrative that justifies the research project to the funder, so why wouldn’t you start working on them straight away?

The answer is simple: the more you refine the question, the harder it becomes to devise a project that answers the question. The more work you do on the question the more likely you are to fall into the trap of the never-ending grant application. If you want the project-design task to be tractable, you shouldn’t do any work on the question until you have used your project to define it.

Creating the Research Questions

Once you have created the project, you use each work-package to generate a research aim or research question. If your work-packages don’t achieve research aims or answer research questions, you need to work on your project design until they do. This approach may seem artificial, but it is much easier than starting with a set of aims or research questions and trying to design a work package to answer each of them. You may find it difficult to create a research question from your work-package. You can be certain that it is much harder to design a work package that answers a research question that you have generated independently of it.

The Case for Support Problem

The Case for Support is the single most important document in a project grant application because it is the document used by the grants committee to decide whether or not to award a grant. It usually consists of a review of the research that leads up to your project, and a description of your project. The challenge you face in writing the Case for Support is to cover these two topics in a way that makes a convincing argument (case) that your project deserves funding (support).

Most of the committee have very little time to read the Case for Support and are not experts on your research topic, but their collective assessments carry more weight than those of the one or two more knowledgeable committee members who read it carefully. 

Referees, who are experts on your research topic, also read the Case for Support and send written reports to the committee. Bad referees’ reports will kill a grant, so the Case for Support must contain the technical detail that referees expect. However, a Case for Support that impresses the referees and is impenetrable to the committee is very risky because the referees do not make the decision. 

The committee, which is dominated by members who have have very little time to read the Case for Support and no expertise in the immediate subject area, discusses the Case for Support and makes a collective decision. Consequently the Case for Support must excite readers who are unfamiliar with its technical language and have very little time. But it must also impress the referees who read it carefully and expect to see technical detail.