The Speed-readable Grant Application by David Karlin is the best book this decade on how to write a research grant application. It is available from the author’s website either as an ebook or as a paperback. You can read it in a couple of hours. And when you have read it, you will refer to it for the rest of your research career.
Since before Jacqueline Aldridge and I published The Research Funding Toolkit nearly 13 years ago I have read every book, blog, or website I could find on how to write research-grant applications. At the beginning I did this because I was looking for a book that would help colleagues to write. After I had failed to find anything suitable and we had put my ideas into our book, I was interested in the competition. Until now the reading has been dull work, tempered only by the grim satisfaction that there is no competition. Karlin’s book changes that. It deals only with writing, so it is narrower in scope and shorter than the Research Funding Toolkit, but its advice on writing is more comprehensive, just as clear, and absolutely right. In sum: on the topic it deals with, it is the better book.
Like me, Karlin has seen both sides of the research-grant decision process and has spent 10 years coaching researchers, so it is no surprise that following his advice would lead you to write an application with exactly the kind of style and structure that I recommend. He also starts from the same premise as I do: the composition of grants committees makes it necessary to write grant applications in such a way that an outsider can ‘get’ the main points in a few minutes even though it contains a lot of technical detail. However, Karlin’s approach to this problem is different from mine. I tell you about the structure of a grant application; he tells you about writing style.
Karlin devotes the whole of chapter 2 to his first style point, the need to harmonise terminology: if you repeat anything, you must always use exactly the same word or phrase. This is sensible because this style point is the most important, the simplest to explain, the hardest for academics to accept and the most difficult for them to adopt. It requires a combination of persuasive argument and helpful advice to get academics to accept the point, and a lifetime of vigilance for them to adopt it in their writing.
Chapter 3 discusses headings and their relationship with the text they head, which gives Karlin the opportunity to introduce structure. Like me, Karlin advocates that text should be structured as pyramids. Every paragraph, every section, and the whole grant application should begin with a one-line take-away conclusion. However, he avoids the pyramid metaphor. Instead he uses the much catchier acronym BLUF, which stands for “Bottom Line Up Front”.
Karlin recommends that a grant application be structured as a tree (he calls this arboreal structure). The tree’s trunk describes the main point of the research and the main branches describe the background to the research, and the research itself.
The background main branch divides into sub-branches that state the importance of the problems that the research will solve.
These sub-branches divide into twigs that deal with points of evidence.
The research main branch divides into sub-branches that state what kind of research will solve each problem.
These sub-branches divide into twigs that deal with research details.
I’m not going to try and summarise the whole book here, but the details of the arboreal structure make it very similar to the PIPPIN framework. And the advice in the book is backed up by helpful examples, so I will have no hesitation recommending it to participants in my workshops.
I think the book will be useful for anybody who is trying to write a grant application, whether it is their first application, or the latest in a long series, and whether or not they have been to one of my workshops. I also think the book could be a game-changer for people who start to write a grant application without having worked out the details of their project. I will have more advice for these people in a future post.
It’s very rare to find people who recommend the same approach to writing research grants as I do, so I was delighted when an academic I met on a cycling holiday recommended I read The Pyramid Principle, by Barbara Minto. The book uses the pyramid as a metaphor for a way of presenting complex information. Minto’s pyramid approach is designed for writing consultancy reports but the recommendations are so similar to those in my magic formula that I have adopted the pyramid metaphor in my writing workshops.
The pyramid principle is based on the idea that a complex report is easier to read and assimilate if it is presented as a pyramid. The pyramid begins with the most important part of the report, the conclusion, which should be expressed in a single sentence. It is the point of the pyramid. The principal arguments that support the conclusion come next; they are like the bricks that support the top of the pyramid. Finally the data and subsidiary arguments that support each of the principal arguments follow; they are the base of the pyramid.
Minto’s justification for this ordering of information is that the arguments that support a point are easier to assimilate if the reader knows what point they support. Similarly, the data that support an argument are easier to assimilate when the reader knows the argument. Minto recommends that complex information should always be presented as pyramids.
I suspect that the writers of consultancy reports have a similar readership problem to that faced by the writers of grant applications. The report has to be accessible enough to appeal to generalist senior managers and have enough technical detail to survive nit-picking by experts. The pyramid structure allows the generalists to get what they need from the tops of the pyramids while the experts dive into the technical detail lower down the pyramids. So a pyramid structure would also work for grant applications.
Unsurprisingly, my magic formula for a case for support is a pyramid. The first sentence is a simplified case for support. The first paragraph or two expand this into a ten-sentence statement of the case in the form of the PIPPIN sentences. Then the PIPPIN sentences become the framework for the argument and detail that makes the case.
The sections of the case for support are hierarchies of pyramids. Each PIPPIN sentence opens a section of the case for support, followed by a paragraph composed of sentences stating the points that support it. Each of following paragraphs opens with one of these points, which is followed by the arguments or information that support the point. In this way each paragraph is also a miniature pyramid.
When I teach people to write a case for support I tell them to start by drafting the PIPPIN sentences and then to use each sentence as the starting point for a section, adding the supporting arguments and the paragraphs that make them, like the branches and twigs of a tree.
The difficulty with my approach, and I am sure it also applies to Minto’s, is that not everybody can do it. Some people find it impossible to draft the framework of their case for support before they start writing. Next week I will write about another book that takes a different approach and one which many people will find easier to follow, to produce a very similar result.
I want to explain my solution to the readership problem I described in my last post. The solution is a little bit complicated and at different times I have described it in different ways, trying to come up with fancy acronyms like PIPPIN. However, we can just think of it as a magic formula for writing an effective case for support.
The way the magic formula works is that it creates the case for support as a series of layers. Each layer takes care of some of the needs of the very different groups of readers that matter. The readers that matter are those who participate in the funding decision. Remember, the case for support is the document that either convinces a grants committee to award you a grant, or doesn’t.
Who are the Readers that Matter?
There are three groups of readers who participate in the funding decision, ordinary committee members, presenting members and referees.
Ordinary Committee Members
Most of the votes that determine whether your application is funded come from ordinary committee members who have really deep expertise in areas completely outside the topic of your project. Unfortunately, when it comes to your topic, they probably don’t understand it. They may not even see why anyone would want to research it. You need to convince the ordinary committee members that your project is worth some of the money that might otherwise go to projects on topics that they know are important.
You don’t have much opportunity to convince them because your application is one of a very large bundle that they don’t really have to read. They only need to know enough about it to get through a discussion, in which they can remain silent, and vote on a score, for which there will be a recommendation. They will be much more concerned to spend time reading the applications that they have to present to the committee.
However, you do have a chance. They will want to decide whether to push your score up or down, which they can only do by understanding your application. However, bitter experience tells them that, for most grant applications, understanding does not come easily, if at all. They will want to check if yours is worth the effort. They will probably have a quick look at the introduction before the meeting. You have maybe 30 seconds to catch their interest.
If you do manage to catch their interest by persuading them that the topic of your research project might be important enough for them to want to see it funded, and that your application might be intelligible, they will dig a little bit deeper. They might spend five minutes skimming through your application trying to work out whether your project will make enough progress that it should be funded. They won’t understand your technical terminology. You have write in such a way that they can work out what they need to know from the context.
Presenting Members
A couple of committee members will know a bit more about your topic, and spend a bit longer reading your application. They may even think your topic is important, but they probably won’t be real experts. They will have the job of presenting your application to the rest of the committee, and recommending a score. They won’t have a huge amount of time to read the application because they probably have eight or nine others to present on the same day. You will probably have about an hour to make them expert enough to explain why the problem you are trying to solve is important and to master the detailed evidence that your project is likely to make good progress towards a solution.
Even if the presenting members are enthusiastic about your project, the score they recommend is likely to be quite conservative. A conservative recommendation is inevitable if the presenting members can’t understand the application; they will just follow the referees’ recommendations without much enthusiasm. However, even if they do understand an application, presenting members will be aware that they are not expert enough to know whether your work really leads your field, which means they have to be conservative in their recommendation. Their colleagues on the committee will be aware of their limitations, and so will be sceptical of over-enthusiastic recommendations. In a world of conservative recommendations, the enthusiasm of committee members can make the difference between success and failure.
Expert Referees
Referees are real experts on your topic. They want to see detailed evidence that your topic is important and that the research questions your project addresses are important and that your project is likely to provide answers. They will then make an expert judgement and write a report and recommend a score that accompanies your application when it goes to the committee. They can probably spend several hours reading your application because, unlike the committee members, who get a big bundle of applications at once, referees get sent applications one at a time.
The Layers of a Case for Support
These three groups have very different needs. Any group can kill an application, so you have to write something that appeals to all the groups. It also helps if what you write gives them a common language to discuss the case for support. The magic formula constructs the application so that it consists of multiple layers that work together, to meet the needs of all the groups of readers without alienating any of them.
Top Layer: The Opening Sentence
The opening sentence has three tasks.
It has to catch the interest of the ordinary committee member and make them feel that it might be worth reading a bit of your application even though they don’t know anything about the topic. I always begin the sentence with a ‘big picture’ statement about the goal of the project. It is important to express the statement in language that will be intelligible to ordinary committee members.
It has to speak to the expert in a way that will reassure them that your project has some real ‘meat’ to it despite the rather bland and aspirational ‘big picture’ opening. I try to make sure that the sentence continues with a much more specific statement that builds trust in the methodological rigour of the project and the competence of the research team. Ordinary committee members probably won’t understand the detail here but if the opening statement is good enough they will accept that this is just a more specific version of it.
The sentence must serve as a summary of the case for support, in case the reader chooses not to read on.
Second Layer: The Statement of your Case
The second layer of the case for support is a statement of your argument that you should be funded. The magic formula provides the argument in ten sentences, including the first sentence. These sentences are the first ten sentences of the case for support. I have already talked about the opening sentence. The remaining nine sentences are:-
A sentence stating what makes the topic of the project important to the funder.
Three sentences, each one stating an important research aim relevant to the topic, and a reason that research aim is important. The research aims might be couched in terms of hypotheses to be tested, relationships to be established, questions to be answered or in some other way. But in every case there will be something that could be achieved by an as-yet undefined research project, and a reason that it is important to achieve it. I call these sentences the problem sentences.
A sentence giving an overall description of the project.
Three sentences, each one describing the research in a part of the project, and what that research will achieve. The part of the project might be referred to as an objective, a work package, or in some other way. What the research will achieve will be expressed in the exactly same words as were used to express the research aim in the corresponding problem sentence. Using the same words makes it clear to every reader that all of the important research aims referred to in the problem sentences, will be achieved by the project, , whether or not they understand the terminology used to describe the research aims and outcomes.
A final sentence saying what will happen as the project concludes.
This second layer provides all the readers with exactly what they need: a short simple statement of your argument that you should be funded. The essence of that argument is that your project deals with an important topic, and will achieve important research aims related to that topic. By expressing the research outcomes in exactly the same words you used to express the important research aims, the magic formula ensures that all the readers will understand that the project achieves those important aims, whether or not they understand the terminology used to express them.
This statement of your argument is probably as much as the ordinary committee members have time for, which is why you put it right at the beginning. You would now like to ensure that all the readers believe your argument and remember it. To do this you recycle the sentences from the introduction to create a framework for the detailed evidence.
Third Layer, Structure of Case for Support
The third layer of the case for support is provided by its structure. After the introduction there are nine more sections in the case for support. Each of those sections begins with one of the sentences from the introduction and contains all the evidence that you will draw on to convince the reader that the sentence is true. The section will also have a heading that is a shortened version of the first sentence.
Creating the framework from the same sentences as the introduction has the effect that, just by skimming the case for support, a reader will see that it marshals evidence to support every part of the argument in the introduction. If they already believe the argument, they probably feel no need to read on, which is probably the case if they are just an ordinary committee member. On the other hand, if they want to test all or part of the argument, they can see exactly where to find the evidence.
Fourth and Fifth Layers: Internal Structure of Sections and Paragraphs
The referees and the presenting members want to know what evidence you are using to support each part of your argument. I recommend that you begin each section by stating the main points of the evidence. Then you make each point of evidence in a single paragraph. I also recommend that you begin each paragraph by stating the point you want to make. Then you use the rest of the paragraph to make the point.
The advantage of this hierarchical structure is that readers can find the detail they need if they want to test any of your points, which the referees probably will. However, readers who don’t want to test the detail, which the presenting members probably won’t, can learn what it is and then skip over it by looking just at the beginnings of the sections and the tops of the paragraphs.
The structure of the sections and paragraphs ensures that any reader can check the evidence you are using to support your case, at any level of detail. The fact that you make repeated use of the sentences you used to summarise your argument in the introduction helps readers to find their way through the evidence, and, incidentally, helps to make sure that they remember your argument and that they all express the argument in the same terms.
Sixth Layer: Summaries
Not all members of the committee will have time to read your case for support. To ensure that committee members who don’t read the case for support know its argument, I recycle the sentences of the introduction in any abstract, summary or statement of aims and objectives that forms part of the application form.
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.
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.
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:-
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.
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.
Referees are experts on the topic and will analyse the case for support in detail.
A small number of committee members will have a fairly good understanding of the topic and will read the case for support carefully.
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.
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.
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.
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.
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.
I decided several years ago to launch on-line research-grant workshops purely as a convenience measure. Over the last few months I have created the materials for a fully on-line workshop. As the on-line workshops launch, I am a little bit surprised to realise that they are better in almost every respect than the face-to-face workshops that I have been delivering for the last five years.
I suspect that on-screen I am less engaging than in real life but I know that in every other respect the on-line workshops are better. The on-line lectures are shorter and clearer. They are supported by well-structured written material. The on-line workshops offer opportunities to get feedback. And they give participants more flexibility and more time.
Better Lectures On-Line
My face-to-face workshops were almost entirely lecture-based, and always received rave reviews. So naturally I assumed that recording a face-to-face workshop would produce excellent lectures. The recorded lectures were fine except for two problems. The picture quality was appalling. And the audio content was dull, repetitive, and full of speech tics and idiosyncrasies. Clearly I had to take a different approach.
The cancellation of all my face-to-face workshops at the end of January created the opportunity I needed. I set up a studio at home and scripted and recorded new lectures. I enjoyed the recording and editing and I am very pleased with the results. The video lectures are clear, crisp and to the point, while retaining enough editing imperfections to create an impression of authenticity. Friends assure me that the appeal definitely comes from the quality of the content rather than the slickness of the production.
Written Material
The lectures are supported by extensive written material, which was originally intended to be published as a book, and may yet be. This has allowed me to resolve a long-standing problem with the face-to-face workshops. Although they were supplemented by slides, handouts, and blog-posts, the material was fairly disorganised. Now each lecture sits on a web-page. The web-page contains text that develops the points made in the lecture. The web pages are organised into three strands that address the main needs of workshop participants.
They need to understand strategy: how to plan grant writing, what to do before starting to write, and what to do after finishing.
They need to understand tactics: the characteristics of a good grant application and what to do to produce one.
They need to develop skill: the ability to write the kind of text needed in a good grant application.
Feedback, flexibility and time
It has always been difficult to work on skill in face-to-face workshops. Skill only comes from practice. People get better at writing by practising their writing, and by getting feedback on what they have written. In a face to face workshop most of the time is taken up explaining tactics so there is little opportunity either for participants to write or for me to give feedback. In the on-line workshop, all the material is pre-recorded, so participants can practise writing and I can give feedback on what they write.
The principal cost of a workshop is determined by the amount of time that I have to spend presenting it. In a face-to-face workshop, the presentation time has to be a continuous block, bracketed by travel time to and from the venue. The need to travel meant that short face-to-face workshops were uneconomic, except very close to home.
In the on-line workshops, I stay at home, and all the material can be presented, for as much time as the client wants, without me. So my involvement can be as little or as much as the client wants and can be recorded, so that participants can choose when they want to engage with the material and with me.
The Fly in the Ointment
One surprise was that I expected that switching to on-line delivery would reduce stress but initially stress increased. I have decades of experience with with face-to-face delivery. I know how it works, I can see when something goes wrong, and I know how to fix it. On-line workshops depend on web-page components that I don’t fully understand and it made me anxious that I definitely can’t deliver a workshop if they fail. However, after more than a year of trouble-free delivery I now have more-or-less the same relationship with on-line delivery as I have with air-travel. I don’t understand the machinery that makes it work, but I do now trust it to work.
This has been a sad and difficult year for many, and we at Parker Derrington have had our share of sadness. Amanda Parker, our managing director, died of cancer in July. While her family, friends and colleagues celebrate the positive force she was in our lives, I have been developing the tools for a socially-distanced way of delivering workshops, and changing the web pages to reflect the new approach.
Over the next few weeks I shall be writing blog posts to raise awareness of our new offer.
This post is about who will read your research grant application, and how they influence the funding decision. There are three different groups of reader:-
referees, who are typically experts from outside the committee,
presenting members, who lead the discussion on your application by explaining it to the committee, and
the rest of the committee.
The three groups have different levels of specialist knowledge and different amounts of time. Failure to satisfy any of the groups can kill your chances of a grant but, surprisingly, the least knowledgeable readers who spend the least time reading your application are the ones most likely to push it across the threshold for funding – in either direction.
Referees
The referee only has to read one application
Referees are the most knowledgeable readers because they are selected from the international research community for their knowledge of your research topic, so there is a pretty good chance that they will understand your proposed research project. Referees are also likely to have enough time to read your application carefully because each of them has only one grant to read.
Unfortunately, the referees’ input to the funding decision is indirect, precisely because they only read one application. The referee writes a report and recommends a score. Low referees’ scores will likely sink an application, but high scores are no guarantee of success.
The next step in the funding decision is taken by a grants committee, who produce a ranked list of the applications in a batch of about 100. The committee assigns a score to each application, and then compares the applications that have similar or identical scores. The final step in the decision is to distribute the available funding to the highest ranked applications. Typically there is enough money to fund about 20% of the applications.
The grants committee considers the referees’ reports as they evaluate each application. However, they also compare the application with other applications, which the referee has not seen, and consider it in the context of the committee’s aims, which may not be known to the referee. Although all the members of the committee can read your application, it is likely that only two or three of them, the ‘presenting members’, will spend much time on it.
Presenting Members
A presenting member can probably spend an hour on each application they have to present.
The presenting members are second to referees, in terms both of their knowledge of your subject and their reading time. They will probably have been selected to present your application because their interests are relatively close to your research area. However, the committee will only have about twenty members to cover a huge subject area, so the presenting members may not understand the finer points of your project. They will spend as much time as they can reading your application because their job is to explain it to the rest of the committee and to recommend a score. However, your application will be probably be one of a batch of about ten that they have to present, so it will be unlikely that they can spend more than an hour or two reading it.
The presenting member’s role in the decision is to explain your application to the rest of the committee and recommend a score. It is important to be aware that even if the presenting member thinks your application looks brilliant, their recommendation is likely to be pretty conservative. They have to leave themselves room for manoeuvre because of their relative lack of expertise and because they do not have time to analyse every last detail. So it is very common that a presenting member lavishes the highest praise on an application, and then recommends a score that is only just above the likely cut-off for funding. Then if other members of the committee notice faults in the application, the score can easily be reduced, and if the other members of the committee are impressed by the application, the score can be increased.
The Rest of the Committee
Committee members have so many applications they don’t have time to read those they don’t have to present.
The rest of the committee have a very important role in the decision. Their input can push a borderline score up to a safe score, or put it completely out of contention.
The rest of the committee probably make their contribution on the basis of a hazy understanding of your subject and a hasty impression of your application. They are unlikely to be knowledgeable about your research topic because the committee covers a very broad range of subjects and their expertise will be in a different area from yours. And simple arithmetic shows that they definitely don’t have time to read your application carefully. It takes about 5 or 6 hours to read a grant application carefully; a committee will deal with about 100 grants each meeting, and will meet about 3 times a year. Reading all the grants carefully would take 1800 hours, more than a year’s work. The most likely approach for committee members not presenting an application is to read the summary before the meeting and skim through the application itself during the discussion.
Which of these readers should you write for?
So what should you do?
Should you cram your application with detail, to impress the referees, and risk leaving the committee members scratching their heads trying to understand your jargon?
Should you fill the application with explanations, so the presenting members can understand it, and risk turning it into a dull textbook?
Should you write for the rest of the committee and risk patronising the other readers?
Or do the ‘Pippin’ key sentences make it possible to create a structure for the case for support that allows you to package the detail where the referees will look for it, while making your research logic clear to the presenting members, in language that makes your technical jargon self-explanatory?
One reason that so many of the posts in this blog are about key sentences is that participants in my grant-writing workshops find it very difficult to write a set of key sentences. The structure of the key sentences and the relationships between the sentences are critical for my approach to writing a case for support, so I am always on the look-out for ways to help people write sets of PIPPIN sentences. As an exercise, I have written a set of PIPPIN sentences that summarise the grant-writing workshops. Here it is.
The workshop teaches a systematic approach to research grant-writing that won the presenter continuous funding throughout his research career and that is informed by his participation in committee decisions on thousands of grant applications. A systematic approach to grant writing makes research grant applications easier to write and more likely to be successful; there are three elements it must include.
It must include an effective strategy to maximise success and reduce wasted effort, so that it is clear when to write grant applications and how to prepare.
It must include a specification for an effective grant application, so that it is clear what to write.
It must include a step by step recipe for producing effective grant applications, so that it becomes easy to write.
The workshop consists of lectures and exercises to teach participants the three elements of a systematic approach to grant writing.
The presenter will explain how the uncertainty of funding decisions can be ameliorated by an effective strategy to maximise success and reduce wasted effort.
The presenter will analyse how funding decisions are made and derive a specification for an effective grant application.
The workshop will include writing exercises to help participants follow the presenter’s step by step recipe for producing effective grant applications.
The presenter explains how the approach is based on real-world experience of applying for and awarding research grants, so that participants can use the workshop to develop a funding strategy tailored to their own experience and ambitions.
There are exactly ten key sentences in the set and they conform to the pippin specification –
Promise sentence, a single sentence description of the workshop
Importance sentence, stating the value of the workshop
3 Problem sentences, each stating and justifying a problem.
Project sentence (in this case a summary of the workshop activities)
3 implementation sentences, each of which describes a part of the workshop and then uses exactly the same words as the corresponding problem sentence to describe the outcome of that part of the workshop.
A sentence that wraps up the description of the workshop and says what happens next.
Eagle-eyed readers will have noticed that these sentences were originally published at the end of my PIPPIN post. I decided to pull them out and make them a stand-alone post because of the need for examples of pippin sentences. Expect more short posts with examples.
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 the main problems that your project will solve and explain their importance. 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 self-evident that each work-package solves one of the three problems. This convinces the funder that your project ill make significant progress and therefore will be a success.
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.
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.
