Tag Archives: Aims

Key Sentences are a PIPPIN for Communicators

Pippin: “An excellent person or thing”, Oxford English Dictionary

A few years ago I found that writing a summary in the form of a set of key sentences is a good way to start writing a complex document with a specific set of requirements, like the case for support in a grant application. Since then I always start a case for support by writing a set of key sentences and I teach workshop participants to do the same, with mixed results. Most workshop participants find it very hard to produce key sentences that work well, and sometimes I wonder whether a different approach might be better. Recently I have come to realise that the most important advantage of the key sentences is the help that they give the reader.

Key sentences create a framework for the case for support that makes your main points accessible to every reader and places the detail that supports your arguments where readers will find it. Consequently, even if key sentences don’t help you to write a case for support, you should use them to structure the case for support when you have written it.

The key sentence framework gives a document a hierarchical structure, so that it starts with the most important point of the document, states the main points, and then fills in the details. Each key sentence states one of these points, starting with the most important, and continuing with those that support it. The key sentences comprise the introduction to the document; they state every point you want to make, beginning with the most important.

The rest of the case for support consists of a series of sections, each of which begins with one of the key sentences, and continues with the detail that supports it. The key sentences reappear in the same order as they appear in the introduction, starting with the second. This means that the introduction states every major point you make in the document, in the order in which you make them. Each of the other sections repeats one of the points, helping the reader to remember it, before supporting it with the detail that will convince critical readers to accept the point. The first key sentence doesn’t reappear after the introduction because its job is to start the first section, the introduction.

It makes sense to give each section a hierarchical structure too. The first paragraph of the section summarises the section by stating the points you want to make in the section, the section continues with paragraphs that make those points in order. The paragraphs are also hierarchical: each one begins with its topic sentence, which states the point of the paragraph, and continues with the sentences that support or develop it.

For a research project grant application there are ten key sentences. I have named them so the initial letters spell the word PIPPIN, which the Oxford English Dictionary defines as “An excellent person or thing”. Other kinds of grant application, such as fellowships, need a slightly different set of key sentences because they need to make a different set of points. The PIPPIN sentences are:-

  • Promise – a one-sentence overview of the whole case for support. It should say what the research project will achieve, in a way that is both accessible and convincing.
  • Importance – this sentence tells the reader what is it that makes the project important to the funding body you are applying to. This sentence should give evidence that the project will help achieve one or more of the funder’s strategic aims.
  • Problem There will be three sentences that state problems that your project has to solve in order to fulfil its promise. There will be three problems. These sentences are part of a device to convince the funder that the project will be a success. The ‘Implementation’ sentences (see below) complete the device.
  • Project There will be a one-sentence summary of the project to say whatever you need the reader to know if they only read one sentence about the project.
  • Implementation There will be three sentences that describe the main work-packages in a way that makes it clear that each work-package solves one of the three problems. This convinces the funder that your project will work.
  • Next This sentence says what will happen when the research is done. It could be about ensuring impact or exploiting other opportunities created by the project.

I designed the PIPPIN key sentences to meet the needs both of the grants committee, who decide on the ranking of the grant, and of the referees, who write an expert report for the committee. The differences between their roles mean these two groups read the grant in different ways.

The grants committee don’t have time to read the case for support carefully, and most of them will find the specialist jargon of your field impenetrable. So the PIPPIN key sentences state the things committee members want to know as clearly as possible. The sentences are repeated more than once so that the jargon they contain becomes more familiar. The introduction tells exactly the same story as the full case for support, and uses the same words.

The key sentences also form the core of any summaries that are attached to the application form, including the lay summary, the technical summary and the aims and objectives. Some members of the committee may read these summaries instead of the case for support, so using the key sentences ensures that these people read the same story, in the same words, as those who read the case for support. Even those who read the case for support will probably read one of the summaries first. Using the key sentences in the summaries makes these readers more likely to understand the case for support when they read it.

The key sentence structure also makes the referees’ job as easy as possible. Referees read the case for support actively, looking for detailed evidence to support the main points that they noted on reading the summary. When the key-sentences reappear in the introduction, they reassure the referee that the case for support will deal with all the points listed in the summary. When they reappear again in the case for support, the key sentences guide the referee to the evidence they are looking for.

The pippin key sentences work to ‘sell’ any kind of project. They can also be adapted to sell similar activities, like my grant-writing workshops. I am also working on a set that sell my formula for a case for support.

If you have a different kind of grant application you may need a different set of key sentences. For example, in a fellowship application you would need a key sentence about what makes you a suitable candidate, and one about what makes your institution a good place to hold the fellowship. In grant applications where you have to write about your track record, you should create a key sentence for each point you want to make. In fact, key sentences are a good way of giving structure to any document that you want the reader to be able to read quickly and summarise easily. You create the summary as a set of key sentences and then you use the summary as a framework to organise the document. It’s unlikely that your set of key sentences will be the same as PIPPIN, but you will definitely find them to be an excellent thing.

Given all the benefits of the key sentence structure, you might question why anybody should structure a case for support in any other way. I don’t know the answer, but if you want to make your case for support easy to read you should create a set of key sentences and use them as a framework to organise the text.

Lists: Keep them Short; Use Bullets.

Oxford college eights training early on a November morning

This picture, which I took a few weeks ago,  reminds me of a story I heard when I was an impressionable undergraduate. Like many such stories, it sought to celebrate the extraordinary mental capacities of Oxford dons. The story was about overhearing  a snippet of conversation between two dons walking in Christchurch Meadow, which is on the left bank of the river in the photograph. The snippet was “…and ninthly….”.

The snippet encapsulated the idea that an Oxford don could perform the extraordinary feat of constructing and delivering a list of nine separate arguments, during a spontaneous conversation. Indeed the story leaves open the possibility that there were more than nine arguments because the conversation continued after the snippet.

The commonest mistakes in research-grant writing arise from the implicit assumption that the grant will be read by superhumans with the extraordinary mental capacity of this apocryphal don. Superhumans may read your grant application, but they will not make the decision, so you should not write for them. The decision will be made by a grants committee. They are ordinary people.

A grants committee cannot follow a long list of arguments. And if they cannot follow your arguments, they will ignore them. A big part of the task of writing a grant application is making sure that what you write is clear enough and simple enough for the committee to appreciate it and understand it.

This post explains that lists in a grant application should obey two rules:-

  • Lists should have fewer than five items.
  • Lists should be formatted, for example by using bullets, so that each item stands out.

Lists Should Have Fewer than Five Items

This rule is more generous than the rule I use myself. When I write a list in a grant application, I get nervous if it has more (or fewer) than three items and I find a way of reducing or expanding it it to three items. Before I tell you how to expand and reduce lists, I should explain why three is the perfect number of list items.

Three is the perfect number of list items because it is the minimal list. It is enough items to justify creating a list, but not so many that a speaker (or listener) is likely to forget an item or get the order wrong. The first step of the decision process is a short oral presentation of your grant application to the committee, who probably haven’t read it but who will probably try to read it during the presentation. If you have a few lists in your application (such as your research goals and your work packages) it allows the presenter to use a bit of rhetoric and to give the impression that they are giving a complete picture – “first …., second…, and finally….” without exceeding their ability to replicate a complex and poorly understood argument.

If you feel you need a list and you only have two items, you must expand your list. You can either split one of the items in two, or break down your topic in a different way, so that you arrive naturally at a three item list. In a grant application you probably need lists for the following categories:-

  • Research goals.
  • Aims
  • Objectives
  • Research questions
  • Hypotheses
  • Work Packages

If you have more than three items to list, you must get rid of some of them. You can omit items, combine items or create hierarchical ‘lists of lists’. In the example above, aims, hypotheses, and research questions are all different ways of expressing research goals and so you would only use one of them, unless the funding agency asks you to use more than one, which several of the UK research councils do. For example, the Social and Economic Research Council ask you two write about your aims and about your research questions, as if they were completely different. I always make it clear that each aim is also a research question.

Lists Should be Formatted

The reason lists should be formatted is very simple. The reader should be able to separate the items and see how many there are at a glance. If a list is written without any formatting, separating the items requires careful inspection. Most readers of a grant application do not have the time to do this. And they won’t.

Why did I relax my rule in this blog post?

Finally,  I should explain why, if I truly believe that three items is the perfect list length, I relaxed the rule for this blog post. And why did I then break even the relaxed version of the rule in writing the post: one of the bullet lists has six items.

I relaxed the rule to make it easy for you. My consultancy clients always complain when I try to persuade them to follow the strict three item rule. I don’t want you to complain, so I will allow you to create lists of four (or two) items in your grant applications if you want to. But you should bear in mind that if your grant application is competing with one that I have written, mine will have perfect, three-item lists and yours will be at a disadvantage.

I have put a six item bullet list in this blog post because it is a blog post, not a grant application. I do not want you to be able to tell all the details of my blog post to your friends in a conversation. I want you to stumble and forget some of the details so that you will tell them that they have to read the post themselves!

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.

Seven Deadly Sins of Grant-Writing: Sins of Omission

3WiseMonkeysA couple of weeks ago I described deadly sins that grant-writers commit deliberately. This week I am dealing with sins that are just as deadly but much harder to avoid. The sins of omission just creep into your writing without you noticing and  you have to make special efforts to remove them.

The sins I want to deal with are Complex Sentences, Long Paragraphs, Poor Flow and failing to match the background to the project. They all meet  the definition of sin that I coined last week: “Anything that makes it hard for a committee member to pick up a clear understanding of the rationale of your research project, what it will discover and why that is important,  is a sin. So is anything that makes it hard for a referee to get a clear picture of the detailed reasoning in your argument and the detailed description of your intended research activities. Referees and committee both work under time pressure, so anything that slows them down is also a sin.”

Complex sentences are really difficult to avoid. They appear spontaneously in your draft. Most people can’t avoid writing them whenever they are trying to write something difficult – like a grant application.

That’s OK. Writing complex sentences isn’t the end of the world. Not unless your first draft is the end of your writing process. You must expect your first draft to be full of sins and you need to cast them out. You need to hunt through your draft and convert all the long, complex sentences into short, clear simple sentences. As a rule of thumb, you should redraft any sentence longer than 30 words or containing more than 1 verb or beginning with a digression – a phrase that is introduced by a word like “although”. And if it’s the first sentence of a paragraph you also need to make sure that the main message of the sentence fits on the first line.

It’s OK for complex sentences to appear in your first draft because that is usually the easiest way for you to write it.  But it’s not OK to leave them there. You have to replace them with simple sentences. This may involve breaking them up, or turning them round and it will take time, but you will get quicker with practice. Your final draft must be easy to read, and to speed read. Most of the people voting on your grant application will speed-read, or skim it. So if what you send them is full of complex sentences that have to be decoded carefully then they will not get your message, and you will have less chance of getting funded.

Long paragraphs are bad for two reasons.

  • I pointed out in my last post that most of the people scoring your grant will speed-read your case for support. Speed-readers read the first line of every paragraph provided there is white space between them. The longer your paragraphs, the less you communicate with speed readers.
  • Long paragraphs are usually very hard to digest. They are usually a sign that what you are writing is either very complex, or just a bit disorganised. The few readers who really want to read the detail in your case for support will find it hard.

If your paragraphs are longer than about 5 lines, try to break them up. If they are not too disorganised it will be fairly straightforward but if they are disorganised it may be easier to attend to the flow first.

Flow refers to the sequence of ideas that you present, sentence by sentence and paragraph by paragraph. Within paragraphs, good flow occurs when each sentence connects naturally to its successor. There are several ways of achieving this. If you have never thought hard about it (and I hadn’t until a few months ago), Google will find you countless sources of advice. I recommend that you read the Using English for Academic Purposes Blog, which has a section on paragraphs and flow.  The basic approach is that  you should always start the paragraph with the topic sentence, the one sentence that sums up the paragraph. Then, to  get good flow within the paragraph you make sure that the first sentence leads naturally to the start of the second sentence, which leads naturally to the subject of the third sentence and so on. This makes it easy for the reader to read through the paragraph without having to pause and analyse the wording to work out what you mean, or having to keep several ideas in mind in order to follow what you are saying.

Flow between paragraphs is also important and again Google throws up hundreds of ways to help you make it smoother. I think that the best approach here is to reverse outline, as suggested on the Explorations of Style blog, which is full of good advice on how to make your writing more readable.

Failing to match the background to the project is a sin against Derrington’s first commandment. You won’t go to hell for the sin but you may enter the purgatory of grant rejection. The commandment requires that before you describe your project and the outcomes it will produce, you use the background section to make the case that we need exactly those outcomes. It’s a pretty basic selling technique. It persuades the customer that they want what you are selling before you describe what you are selling. I have explained before how you use key sentences to create a structure that implements the technique by creating a background section that deals with the outcomes in the same order as the description of the project, and that explains, outcome by outcome, why we need them.

The key sentences also give you the best way to fix a mismatch between background and project. Basically you create the key sentences and then you use them to re-organise your text. And then you use them to write an introduction.

If you read a few successful grant applications you will realise that the sins are not fatal: most successful grant-writers commit them. However, the sins all make it less likely that you will get funded because they make it harder for time-pressed committee members and referees to do their job. Of course you may be lucky enough that the committee sees the merit in your application despite you making it difficult. But why take the chance?

Seven Deadly Sins of Grant-Writing: the sins of Commission

By Pieter Brueghel (http://gnozis.info/?q=node/2792) [Public domain], via Wikimedia Commons

The_Seven_Deadly_Sins_-_Pieter_Brueghel

The first rule of writing is that you must think about the effect you want to have on your intended reader.  From this perspective,  a research grant is one of the easiest writing tasks imaginable: the effect you want to have is very simple and the readership is well-defined. This makes it very easy to work out that there are some things you should never ever do. Almost all grant-writers do them. These are the deadly sins of grant-writing.

To help you understand how bad these sins are, I will describe the effect you want to have and the readership before I list the sins.

The effect you want to have and the readership.

Obviously the effect you want to have is to get funded. For this to happen, your  main readership, the grants committee, must understand your aims and believe that they are important and that your project will fulfill them. Then they must rank your application high enough to fund it. Typically the committee will read your application in parallel with about 80 others and to get funded you need them to rank it the top  15 or so.

Few if any of the committee will be familiar with your research area. Mostly they will be struggling to understand what you are going to do and why it might be important to do it. They won’t spend long reading your application. A couple of them may spend as much as an hour on it because they will be tasked with explaining your application to the rest of the committee. Most of the others will probably just read the summary and ‘speed read’ (glance through) the case for support during the discussion. At the end of the discussion they will all vote on your score.

Your application will also be read by referees, who tend to be more knowledgeable about your research area and who will probably spend a couple of hours on it but they will not contribute directly to the decision. They will read your application in detail and write an evaluation of its strengths and weaknesses for the committee to consider. They probably will not read any of the applications you are competing against.

Anything that makes it hard for a committee member to pick up a clear understanding of the rationale of your research project, what it will discover and why that is important,  is a sin. So is anything that makes it hard for a referee to get a clear picture of the detailed reasoning in your argument and the detailed description of your intended research activities. Referees and committee both work under time pressure, so anything that slows them down is also a sin.

It may be helpful to distinguish sins of commission, things that you do deliberately, from sins of omission, things that you do because you just can’t help it. All seven sins make a long post, so  I’ll  leave the sins of omission to next week.

Sins of commission

  1. Elegant variation, using synonyms to avoid repeating yourself, is my top sin. It’s not the worst, but  it is the easiest to avoid. I have heard many reasons why you should say things in different ways when you repeat them. None of them applies to grant-writing.  Elegant variation is bad for two reasons.
    • First, it cuts down on repetition. Repetition is good in a grant application because it helps the reader to remember what you are writing about long enough to join in the discussion. It also helps them become familiar enough with  your technical terms to feel comfortable using them.
    • Second, synonyms are dangerous because members of the committee may not realise that they are synonyms. They will get hopelessly confused.
      People justify elegant variation in a variety of ways. Most of them are wrong and none of them applies to a grant application. Trust me.
  2. Aggressive space-saving is bad in all its forms, shrinking margins, shrinking font size, removing white space between paragraphs, and coining new abbreviations. They all make the reader’s real problem, reading and understanding your text, harder. And the reader will not love you for that. It is better to cut text than to cram it in and make it unreadable. Removing white space and coining abbreviations are particularly bad.
    • Removing white space makes speed-readers (most of the committee) lose the plot. Completely. Normally a speed reader will read the first line of every paragraph: their eyes automatically land on the edges of the white space at the top of the paragraph.  That means that the speed reader understands your proposal and thinks it is very clear because they pick up all the essential messages – you do start every paragraph with the topic sentence don’t you? Without the white space the speed-reader’s eye movements will go all over the place and they will pick up four or five random phrases from each page.
    • Coining abbreviations can’t do any harm can it? Surely it’s ok if you spell out each abbreviation the first time you use it? Well, no. I mean NO. Imagine reading 80 grant applications, all of them with half a dozen sets of abbreviations. Then imagine trying to re-read the difficult parts to try and understand them. What happens with the abbreviation when you start reading half-way through the grant? I can tell you: searching backwards through the text for the point where the abbreviation is spelled out makes a reader grouchy. Grouchy readers give grants low scores. So my advice is that if you have  to spell out an abbreviation you can’t use it.
  3. Over use of the passive voice – or of any convention that breaks up the natural flow just makes it hard to decipher your meaning. Of course sometimes your meaning is made clearer by using the passive. If you would like some helpful ideas about how and when to use the passive have a look at  this excellent post, which gives very clear advice on when it’s bad and when it’s good, including a brilliant sentence made shorter and sharper by using the passive voice 5 times.

It should be easy to avoid all these sins of commission because they are things you decide to do. Next week I will deal with the sins of omission, which are much harder to avoid.

How to Deal with Rejection 1: What could I have done better?

Are you driven by the question or by the project?

Did you design a project that will answer your question? Thanks to Nick Kim, http://lab-initio.com

Getting a grant application rejected has three things in common with other rejections.

  1. Rejection is slightly less painful if you have other applications still being considered.
  2. Regardless of how painful it is, rejection is an important learning opportunity.
  3. Regardless of the pain and the learning, you need to make sensible decisions about whether, and how, to try again.

I know – believe me I really know – that getting grant applications rejected is painful. In my experience the combination of pain and humiliation can make it impossible to think analytically about the application for weeks or months. However, unless your desire to do research is completely extinguished, sooner or later you have to come back. When you do, it’s really important to learn as much as you can from the rejection and use it to plan the best way ahead.

If you are still consumed with the pain of rejection, you might want to bookmark this page and come back when you feel able to be analytical. However there are three practical  reasons you might want to work through the pain and deal analytically with the rejection now.

  • Dealing constructively with a rejection helps to draw a line under it and resolve the pain.
  • The sooner you start, the better will be the outcome for two reasons.
    • You will do a better job on the analysis if you do it while your memory is fresh.
    • Any plans you develop as a result of the analysis are more likely to be successful if you can implement them before they go out of date.
  • The more times you deal with rejection, the easier and the quicker it gets. I can remember once  (admittedly it was about my 20th rejection) I was able to deal with it in less than a day, rewrite the grant in under 3 weeks and get it fully funded.

If you have got this far I am assuming you want to be analytical. There are four separate steps.

  1. Work out why your grant application was rejected.
  2. Work out how you could have made it stronger.
  3. Salvage useful components.
  4. Get back on the horse.

I’ll deal with the first two in this post and the other two next week.

Work out why it was rejected

Usually the reviews you get back will  say lots of good things and it can be hard to understand why an application with so much going for it could have been rejected. Rejections usually boil down to:-

  • the committee thought the research question wasn’t important enough or
  • the committee couldn’t see how the project would answer the question.

There are three things you should consider here.

  1. It only takes one hole to sink an otherwise perfect boat. It might make it easier to find the hole if you filter out the negative comments and look at them separately.
  2. In most cases the committee discussion is more important than the referees reports but the description of their discussion is likely to be both short and vague. So the hole in the boat my not be very well defined.
  3. Funding rates are falling and sometimes perfect grants, grants that propose well-designed projects that will answer important questions, don’t get funded because there just isn’t enough money.

Don’t be too eager to assume that your grant was perfect. If the funding rate was 30% or better then it’s very unlikely. In fact, most grants that get funded could be improved significantly.

Work out how you could have made it stronger

Regardless of why your grant application was rejected, you should look to see whether it could have been improved. This is particularly important if the reason for rejection is not apparent from the comments: a badly written grant simply fails to convince the reader – the reader may not know why.

You should look separately at four elements:- the description of the project, the background, the introduction, and the summary. As a rough guide you should be clear on the following questions:-

Description of the project

  • Is it clear what you will do?
  • Have you explained the steps that will take you from starting research to having a set of findings that are written up and disseminated?
  • Is the project divided into three or four (i.e. more than two and fewer than five) phases?
  • Is it clear what will be discovered by each phase of the project?

Background to the Project

  • Have you given a good reason why you should do your project? Have you linked it to an important question?
  • Is your link direct (your project will completely anser the question) or indirect (your project will take some important steps towards an answer to the question)?
  • Has the funder stated explicitly or implicitly that this question is important? This is probably worth a whole post. I’ll get around to it.
  • Have you linked the question clearly to each phase of your project by showing that we need to know what each phase of the project will discover?
  • Do other authors agree with your specific ‘we need to know’ statements or are they individual to you?
  • Have you cited publications that demonstrate that your team are competent to produce new discoveries in this area?
  • Have you overstated your contribution to the field?
  • Could other people think this area is a backwater rather than a niche?

 Introduction

  • Does the introduction make all the statements listed in the ‘key sentences‘?
  • Does the introduction state every thing that  ‘we need to know’.
  • Does the introduction state  every thing that the project will discover?
  • Are these statements in the introduction clearly the same as the statements that begin the corresponding sub-sections of the background and the description of the project? They should be recognisably the same statements although they don’t have to be exact copies.

Summary (I mean the summary of the Grant Application)

The summaries of most successful grant applications are appallingly bad. You can see this if you look for the details of successful proposals from the UK research councils or from the European Research Council. However, a good summary helps the funding agency to choose more appropriate referees and it helps the referees and the committee members to understand the research. You should check the following:-

  • Does the summary make all the statements listed in the ‘key sentences‘?
  • Does the summary state every thing that  ‘we need to know’.
  • Does the summary state  every thing that the project will discover?
  • Are these statements in the summary clearly the same as those in the introduction? They should be recognisably stating the same thing although they don’t have to be exact copies.

What Next?

It’s very likely that these two exercises will give you a clearer sense of how you could have given your application a better chance. Next week I will discuss what raw material you can take from a rejected grant application and how to turn it into the basis of future success.

How to Write a Research Grant Application in 2 Weeks

MonkeysAndTypewriters

The key to writing anything quickly is knowing what you have to write.

One of the things that puts people off writing research grants is that writing a grant can be a never-ending nightmare. However, it doesn’t have to be that way.

Last month I helped a client, let’s call him Dr B, to write a research council grant application in 2 weeks. It was interesting for me because it was a model of how to write with the minimum of effort – by either of us. Dr B tells me that he spent only about half of the working day on the application during the 2 week period when he wrote it.  I spent between 2 and 3 hours helping him.

The clock started on September 3rd when Dr B sent me a draft set of 10 key sentences and a  question about whether to follow my advice, to state the  aims and objectives in the introduction, or whether to follow the funder’s guidelines for a case for support which suggests that aims and objectives  form part of the description of the project.

I edited the sentences and sent an email suggesting that Dr B could follow both my advice and the funder’s guidelines. I think that it is essential to state the aims and objectives – and not much else – in the introduction to the case for support and also in the summary, so that the reader knows what to expect. And if the funder recommends that you state the aims and objectives at the start of the description of the research project then its fine to do that although I would suggest that you only format them as Aims and Objectives once. In other places you can use phrases like ‘We need to know’ for the aims and ‘In order to discover X we will do Y’ for the objectives.

I think that editing and drafting my email took less than 20 minutes. It can’t have taken much more because the email logs show my response 31 minutes after Dr B’s query. A few days later Dr B promised to send me a draft on the 15th and we made an appointment to speak about it on the 16th. The draft arrived on time and I spent about an hour and a half reading it and annotating it. Then Dr B phoned and we spent an hour discussing my suggested changes which took him less than a day to implement. We also kicked around some ideas that will be the subject of his next grant proposal.

The key to writing anything quickly is knowing what you have to write. That is why it is so useful to start by writing the key sentences. They define the grant application. Each of them begins a major section of the proposal. These sections justify the bald assertions in the key sentences and make the reader believe that they are true. The key sentences that define the background must be justified with evidence; those that define the project must be justified with descriptive detail.

Writing the key sentences should only take you a couple of hours. If you can’t write the key sentences in a couple of hours then you need to do some more thinking about your project. That can take days, weeks, or months, but until you have done it you are not ready to start writing a grant application.

Dr B is ready. I had an email from him last week. He has been thinking about the ideas we kicked around when we were discussing the edits to his last application. He wants to send me a set of key sentences next week!

 

The perfect introduction

Meeting_of_David_Livingstone_(1813-1873)_and_Henry_Morton_Stanley_(1841-1904),_Africa,_ca._1875-ca._1940_(imp-cswc-GB-237-CSWC47-LS16-050)

Henry Stanley introduces himself to Dr Livingstone

If you write your grant application in the way that I recommend, you should leave the introduction until last. The reason is that, by the time you start to write the introduction, you will already have written everything you need to say in it. You just need to copy it and paste it into the right place.

Here’s how it works. There are five things that you need to say in the introduction to a grant application,

  • what you will do,
  • why it is important,
  • your research aims,
  • your research objectives, and
  • what you will do with the results.

1. What you will do

Your first sentence should say what the outcome of your research project will be. Ideally it will also say something about how you will go about producing this outcome and give a hint of your credentials for doing it.  If you followed the advice in my last post then you will already have written the perfect sentence to do this, key sentence 1. You can just copy and paste it to the beginning of the introduction.

2. Why it is important

Your next sentence should say why the outcome is important. It will do this with reference to an important research question. My last post described how to write this sentence, key sentence 2, introducing one of the sub-sections of the background section. You should copy it and paste it into the introduction.

3. Your research aims

Next you need to state how the outcome of the project depends on about three things that we need to know.  My last post explained how to state this in 3 sentences (key sentences 3, 4 and 5). You should copy and paste these from their positions in the background section of the case for support into the introduction. At this point you may wish to edit the sentences so that you can run them together as a list of aims. Whatever editing you do you should avoid changing any of the technical phrases for reasons I will explain below.

4. Your research objectives

Then you need to say that the research project will tell us each of the three things that we need to know. If you followed the advice I gave a couple of weeks ago or earlier, you will have put four sentences that do precisely this at strategic points in the description of your research project. They are key sentences 6, 7, 8 and 9; copy them and paste them into the introduction.

5. What you will do with the results

Finally you need to say what you will do with the results. You will already have written key sentence 10, which says exactly this and introduces the last part of the description of the project. Copy  it and paste it into the introduction.

Exact repetition of the key sentences increases your chances of getting funded

When you copy and paste the key sentences you should keep the phrases that refer to your research activities exactly the same. It’s OK to change the structure, as long as you keep the parts that refer to research activities exactly the same. For example you might change three sentences saying “We need to know X.”; “We need to understand  Y”; and “We need to  characterise Z” to a list of aims, such as “Our aims are:- to discover X; to understand Y; and to characterise Z”. But you should not change the phrases X, Y and Z or the verbs discover, understand and characterise. 

One reason that you should not change phrases when you repeat is that to do so would be a stylistic error known as  elegant variation. However, there is an important practical reason that exact repetition is good.

The value of exact repetition comes from the way that a grants committee deals with applications. One or two members of the committee have to read each application and explain it to the rest of the committee. Usually they do this by stating  what you will do, why it is important, your research aims, your research objectives, and what you will do with the results. This is quite a difficult thing to do because they will not have had much time to read the proposal and they will have to present several other grant applications the same day: I once had to present 10 applications in a single meeting.

Anything that you can do to make the job of presenting your grant to the committee easier will be welcome. If you write the introduction the way I have suggested, it will be the perfect set of notes for the presentation. What could be better than that?

I frequently encounter  academics who feel that you should change the words when you repeat a message even though the meaning is exactly the same. I encounter two arguments for this.

  • The first argument is that the reader will get bored if they see the same phrase twice. This is not so. For the most important readers the repetition is a useful and reassuring signal.  The members of the committee that decides whether to fund your grant are unlikely to be familiar with the details of your research area and may not completely understand the phrases. Repeating the phrases exactly helps them to see that you are saying the same thing again. To say the same thing with different words is very risky indeed. The most likely outcome is that they will think you are saying two different things.
  • The second argument – which usually follows immediately I give the explanation in the previous paragraph – is that by using different ways of saying the same thing, you increase the chance that the reader will understand at least once. Even if it’s true, it’s no help for the reader to understand once because they will still think that when you repeat the sentence with different words that you are saying something different. It is far better to use exactly the same words because you increase the chance that the reader will remember the phrase, and even if they don’t understand it they may think that they do.

Is your grant application a misshapen monster?

Nuke_fishWhat do you do when your grant application (or your colleague’s) turns out to be a misshapen monster? How do you even know if it has? Can you tell if it’s just a little bit deformed? Read on. This post is about how to test whether your case for support is the right size and shape. Size and shape go together for three reasons.

  • If your grant is a monster then it’s probably misshapen too.
  • Even if it’s a perfectly formed monster, you will need to cut lumps out of it to get it down to size, so you need to check that the cutting doesn’t destroy the shape.
  • If it’s the right size but the wrong shape then you will probably need to cut some parts and grow others.

Incidentally, if you think that the solution to an overlong case for support is to shrink the margins and the font size I have no argument with you. None whatsoever. But you are reading the wrong blog. This blog is about grant-writing. Here are some blogs about typography.

Gross malformations: missing parts

The easiest malformation to spot is if one of the parts of the case for support is missing or the wrong size. In the research funding toolkit book we make the point that a generic case for support has three components.

  • An introduction that very quickly states the main objective of the project, why it is important, the aims, the objectives, and what will be done with the results. This should be less than 20% of the total. The commonest mistake is to omit it completely. Less commonly it is so big that it unbalances the case for support.
  • A background section that makes the reader feel that it is important to do the research in the project by showing how the aims contribute to a big important question. This part should be no more than than 30% of the total. It’s fairly common for it to be hypertrophied – and hideously deformed by philosophical quotations, particularly when people start by writing about the question they want to answer rather than describing the project that they want to do. I have seen a case for support that was 90% background.
  • The description of the research project, which describes the research in sufficient detail to convince the reader that the aims will be met. This should be at least 50% of the case for support. It is often too short and sketchy. It is rare for it to be too long except when the project itself is over ambitious.

Lesser malformations: malformed parts

The parts of the case for support must be the right shape as well as the right size if they are to work effectively. There are two major aspects to this.

  • The background must match the project. Each component of the project (there should be three or four such sub-projects) should have a corresponding sub-section of the background that makes the case that the outcome of that sub-project will meet one of the specific aims of the project. These sub-sections should be in the same order as their corresponding sub-sections in the description of the project and they should be preceded by one or two  sub-sections that explain the importance of the overall objective of the project and link it to the specific aims.
  • The statements in the introduction should be in the same order as the subsections of the background and description of the project to which they correspond. The introduction sketches a picture of the case for support and the other two sections fill in the detail.

The Zombie Grant

If you have generated your draft without thinking too much about structure and particularly if, like most academics, you tend to write statements as conclusions, rather than as assertions to be explained and justified, it may actually be pretty hard to work out what each section of the text does. If you are in this situation your draft is the research grant equivalent of what Inger Mewburn, Director of Research Training at the Australian National University  (AKA @thesiswhisperer), calls the zombie thesis. Let’s call it a zombie grant.

I have explained that you can avoid writing a zombie grant by writing key sentences and using them to impose structure on your draft.  But once you have it, you need to take drastic action to avoid getting sucked into a quagmire. As @thesiswhisperer says says “The worst thing to do with a Zombie Thesis is to do a line by line edit. This is like trying to fight a jungle war – you will find yourself hip deep in mud somewhere, with a sucking chest wound, too far for a helicopter to reach.”

To revive a zombie thesis @thesiswhisperer recommends a rebuilding process based on reverse outlining, which is explained in this blog post. To revive a zombie grant you need a combination of reverse outlining and retro-fitting key sentences which I will explain next week.

Aims and Objectives, why the world needs your research.

the-mountainAims and objectives provide an excellent framework for the case for support in a research grant application.

A well-written case for support states an overarching aim based on a big research question. It shows how this big question gives rise to three or four smaller questions and then describes a research project that will answer those questions. The compelling logic for the reader is that the project deserves to be funded because it has been intricately designed to answer the big question. The truth may be that the intricacy lies more in the writing than in the project’s design. Matching sets of aims and objectives can be crafted to link a pre-designed project to a pre-existing big question.

Before we consider how to do this, let’s be absolutely clear about the difference between aims and objectives. There’s an excellent discussion of the difference in the context of a PhD project,  by Pat Thomson. She defines the aim as “…what you want to know…” and the objectives as “…the specific steps you will take to achieve your aim..”  This definition works perfectly for our purposes.

We can apply this distinction more or less directly in a grant application as follows.

  • Aims are the knowledge and understanding that you need in order to answer your research question. Well-designed aims create clear links between your research project and the big, important question that motivates it.
  •  Objectives are specific research actions that you plan to carry out in your research project. The objectives define the structure of the research project.  This means that if you design your project carefully, it will be clear that your research objectives will fulfil the aims defined by your research question.

The easy way to link up the aims and objectives is to start by describing the research that you want to do and what it will find out. You should divide your research project into (or assemble it from)  three or four sub-projects. Each sub-project will lead to a clear discovery or outcome. Each  outcome generates an exactly corresponding aim. If you want to do a sub-project that will discover how neurones in the cerebral cortex respond to lights of different colours, you have to have the aim “We need to know how neurones in  the cerebral cortex respond to lights of different colours”. Working backwards from the objectives in this way means that aims and objectives match perfectly. No skill is required

The place where skill is required is in tying together the three or four aims and making the case that meeting each of them will make a significant contribution to solving a larger research problem that is important to your target funder. That is where the real skill of writing grant applications lies.

For completeness, in addition to this set of three or four aims with precisely matching objectives, I would recommend another four sentences which are a more complex mix of aim and objective and which would be used to set the context in any full statement of the aims and objectives. So a full statement of the aims and objectives would be as follows.

  • The first sentence, which would be the first sentence of the case for support, would be a one sentence summary of the whole proposal. It would state the overall aim of the project, which is to take us closer to solving the larger research problem, and the overall objective, which is to carry out the research project. This is a very difficult sentence to write but a very important one, for two reasons. First, it gets the reader excited about the project by telling them its aim and its objective. Second, because it tells everything in a single sentence, it can afford to gloss over uncertainties, helping the reader to form a positive view of the project.
  • Second, there is a sentence that states why the research problem is important and which may also introduce the specific aims.
  • Immediately after this sentence you would state the three or four specific aims.
  • Third, after stating the specific aims, you need to set the scene for stating the specific objectives with an introductory sentence that describes the nature of the research project.
  • The three or four specific objectives, stating research outcomes that exactly match the specific aims, would be stated immediately after it.
  • After the objectives, there should be a sentence that says what will be done with the research outcomes. In a sense this is an overall objective which should ensure that the overall outcome of the research project  contributes to solving the larger research problem that motivates the entire project.

Finally I should make it clear that, although it matters for understanding this post, for the purpose of grant-writing,  it doesn’t matter that some authorities, including the Oxford dictionary, do not distinguish between aims and objectives in exactly the same way as I do. What matters in a grant application is how you present the argument that links your project to the important question. Whether you call any individual link an aim or an objective is neither here nor there.