Tag Archives: Case for Support

The Readership Problem.

Most of the research grant applications that I read make me think that the writer is trying to solve the wrong problem. I’m referring specifically to the problem they are trying to solve by writing the case for support. The most important problem to solve is the readership problem – how to convince the readers who participate in the funding decision that your research topic is important and that your project will make good progress.

There are two ways that writers try and solve the wrong problem.

  1. In the worst case, writers use the writing process to try and solve the problem of what to write. What is the story they want to tell in the case for support? This is a problem that they should have solved before beginning. Trying to work out the story of the case for support by writing it produces a hopeless mess.
  2. Many writers work out the story of the case for support before they start writing but they design their case for support to communicate with the wrong audience in the wrong way. This approach usually produces an application that is fundable in principle – indeed the vast majority of funded applications are like this – but which would have a better chance of funding if it were designed for the readers who will make the funding decision.

Some writers, particularly early career researchers, use the writing process to refine their research topic and then to work out the design of a project that addresses the topic. They are hoping that the writing process will enable them to create a well-defined and well-justified project. It never does. There are two reasons:-

  1. Refining the research topic has no natural end point and most people continue until they have raised more questions than could conceivably be answered by a single project. Worse, the detailed development of the research topic takes so much space that they don’t have enough space left to describe a project.
  2. A detailed set of research questions is a bad starting point for the design of a project because it is likely to be impossible to design a project that answers them. Remember, the research questions in a grant application are really just a sales device, so it is much better to design the project first and then work out what research questions will create the best sales pitch.

Other writers, including most experienced researchers, start with a well designed project and try to solve the problem of cramming as much technical detail as possible into the case for support. They reason that the expert referees who read the case for support will penalise them if they omit any relevant details. They compound matters by seeking advice from close colleagues who suggest further details. The case for support becomes such a mass of detail that they need to reduce page margins and font size and devise ingenious abbreviations so that the mass of detail fits within the page limit.

Cramming in detail does not produce an effective case for support. To be effective, the case for support must make a clear argument that the research topic is important and the project is likely to be successful. And that argument must be accessible to every person that participates in the funding decision. Of course detail is necessary to convince referees of the merits of the argument, but detail on its own is not enough, and even if it were, the referees do not make the decision. They make a recommendation that accompanies the application to the grants committee, which decides whether or not to fund it. A negative recommendation from the referees is likely to kill an application, but a positive recommendation does not guarantee success. An application that fails to communicate its argument to the committee – most of whom do not have time to read the detail and would not understand it if they did – is likely to fail.

To be most effective, the case for support must convince readers with different levels of understanding, who will read it in different ways, that the research topic is important and the project is likely to make good progress. There are three groups of readers who participate in the decision:-

  1. Referees are experts on the topic and will analyse the case for support in detail.
  2. A small number of committee members will have a fairly good understanding of the topic and will read the case for support carefully.
  3. Most of the committee will have only a hazy understanding of the topic and will spend very little time reading the case for support.

Designing a convincing argument, and then setting it out in a way that works for all three types of reader, is the most important problem to solve in writing a case for support. Many academics think the problem cannot be solved, except possibly by a magic formula. In my next post I will explain how my approach to writing the case for support solves the problem.

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. The task of the Case for Support is to make 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.

The Case for Support: Structure Solves its Problem.

Birdy folding bicycle front fork.

The front fork of a Birdy folding bicycle has a distinctive structure that smooths out bumps in the road and solves the bicycle’s main problem, how to fold quickly into a compact space.

This post explains how you can structure the case for support in a research grant application in a way that solves its main problem and enables it to do its tasks efficiently.

A case for support has two main tasks. It has to convince the committee that your research project is important. And it has to convince referees that your project will be successful. However, these tasks are not the case for support’s main problem.

The case for support also has to do several minor tasks. It has to make the grants committee think that they understand your project. It has to convince referees that you are competent to carry out the project. And it has to convince them that the resources you will buy with the grant are necessary and sufficient to carry out the project. These tasks are not the case for support’s main problem either.

The case for support’s main problem is this: most members of the grants committee will not read it, and those who do read it will probably not understand it.  Despite this, the case for support has to convince them that your research project is important. It has to convince them that your project will be successful. And it has to tell them what your project aims to achieve, and how the project will achieve it and how competent you are.

The committee members will not read the case for support but it still has to convince them that your project is important and will be successful. That is its main problem.

My recommended structure for the case for support solves this problem.  All the committee will skim the case for support while your grant application is being discussed, but they will all have read the summary beforehand. So if you give the case for support a structure that gives the right information to someone who skims it, and if you create a perfectly matched summary that ‘primes’ them by giving them the same information in the same words, that solves the problem.

So what kind of structure allows someone who only skims the case for support to pick up all the right information?

A three-layered structure.

As I said, the case for support has two main tasks. First it has to convince the reader that your project is important. Then it has to convince them it will be successful. The ideal structure has three layers, a main structure, a local structure and a fine structure.

Main Structure: Introduction, Background and Methodology.

The most efficient way to convince the reader your project is important and will be successful is to divide the case for support into three main sections.

  • Two of the sections do the main tasks:
    • the background section convinces readers that the intended outcomes of the project are important, and
    • the methodology section describes the project and convinces the reader that it will achieve its intended outcomes.
  • The third section, the introduction, increases the effectiveness of the background and methodology sections by telling the reader the points that will be made in those sections. You write the introduction last but the reader reads it first.

The names that I have given to the three main sections are not fixed. They will vary, depending on the funders’ instructions for the case for support. Whatever those instructions, it is always possible to write the case for support so that it has a background section that describes the state of the art in such a way that it is completely clear that the intended outcomes of your project will be important to the funder, a methodology section that makes it clear that your project will succeed in delivering its intended outcomes, and an introduction. The local structure of these sections, which we discuss next, gives the reader the bigger picture of what makes your project important.

Local Structure: three aims in background delivered by three objectives in methodology.

A good way to help the reader to assess the value of your project is to describe it as consisting of three components, each of which will deliver a clear outcome. If it suits you, or if the funder asks you to state aims and objectives, you can call these three outcomes the aims, and the sub-projects that will deliver them, the objectives.

Breaking the overall research outcome into components like this makes it much easier for the committee to discuss it and analyse it, and it also makes it much easier for you to write the background in a way that makes it clear that your project is really important. If the background convinces the reader that the aims are really important then the project will automatically become important if your description of it convinces them that it will achieve the aims.

Three aims and three objectives is the perfect number. If you have too few aims or objectives it becomes hard to describe them concisely. If you have too many, it becomes hard to remember them. And if you have different numbers of aims and objectives then the aims and objectives will not give the reader a clear picture of what the project will achieve and why it is important.

Because each objective delivers exactly one aim it is easy to write the background so that it convinces the reader that each aim is really important. It also makes it easy for the reader to remember the list of aims and to see that by carrying out the objectives you will achieve the aims.

The background and methodology sections have five subsections each. Three of each set of five are used to link the two sections together, so that the background convinces the reader that every component of the project is important. The remaining subsections have different jobs, enticing the reader to read the case for support, explaining the overall importance of the project, introducing the project and describing what will happen after the project is done.

The three pairs of subsections that link the background to the methodology section work very simply.

  • The background has three subsections, each of which explains the importance of one of the aims. Usually this is where literature is cited to support the case that the project will achieve important aims.
  • Each of the subsections in the background is paired with one in the methodology section, which describes the sub-project (the part of the project) that delivers the corresponding aim.

The background starts with two subsections that entice the reader to read the case for support, and explain the overall importance of the project.

  • The first subsection states the overall project outcome and explains it. If not much explanation is needed, this subsection can be expanded into an introduction for the whole project (see below). For that reason I would always write this subsection last.
  • The second subsection gives the evidence that the project outcome is important. These two subsections are essential preparation for the core subsections that explain how important the aims are. The aims are usually important mainly because they deliver the overall project outcome.

The methodology section starts with a subsection that introduces the project. It also leads into the three subsections that describe the objectives. The methodology section finishes with a fifth subsection that describes what will happen after the project is done. This could be be dissemination, impact, or even a new project.

Fine Structure: Key sentence followed by justification.

Each of the ten subsections described above has the same structure. It begins with a single sentence that summarises the subsection. These are the ‘key sentences’ that are the skeleton of the case for support. The rest of the subsection fleshes out the key sentence, supporting it and increasing its impact. For key sentences in the background, the ‘flesh’ will consist mainly of evidence from the literature. For key sentences in the methodology section the ‘flesh’ consists mainly of details about what will be done in the project.

Within each of these sections, the punch-line of each paragraph is on the first line, and the remainder of the paragraph explains or justifies the punchline. This post explains the advantages of this assert-justify structure. The most important advantage is that if you leave space between your paragraphs, someone who skims your text will read the first line of every paragraph.

You can read more about the key sentences in these three blog posts.

The Introduction

The first draft of the introduction can be done by copying and pasting the key sentences. You may find it necessary to add some linking and signposting, so that they form a coherent narrative. When you write the main sections of the case for support you will edit the key sentences so that they link smoothly with the sections they introduce, so it will be better to leave the introduction until after you have written the background and methodology sections. This post describes the introduction.

The perfectly matched summary

The summary should be perfectly matched to the case for support. This will cause anyone who reads the summary and then skims the case for support (most of the committee) to feel that they understand the case for support completely. If you use the key sentences as a skeleton for the case for support in the way that I recommend, they will make a perfectly matched summary. This post discusses the summary.

I hope this post convinces you that my recommended structure equips the case for support to solve its main problem. In a future post I will discuss my recipe for producing a case for support that has this structure.