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.
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.
There are two ways of writing a grant application, the quick way and the easy way.
The Quick Way
The quick way is to start by writing a set of key sentences. Each key sentence states one of the points that you will need to make in the case for support. These points include the main research goal, what makes the goal important, the sub-goals, the lines of research that will deliver the sub-goals, and so on.
Writing the key sentences is hard work, but it only takes a couple of hours. If you can’t draft a set of key sentences in a couple of hours then you know you are not ready to write a grant application. On the other hand, when you write a set of key sentences you get more than the knowledge that you are ready to write. You get a short-cut to the finished case for support. The key sentences enable you to write the full case for support in a couple of weeks.
The key sentences give you a short cut because the full case for support is simply an expanded version of the key sentences. It consists of a series of sections, each of which begins with a key sentence. Each of the sections should also have a heading that uses phrases from the key sentence. The remainder of each section consists of a few paragraphs that expand and justify the point made by the key sentence.
Not only is it easy to write the case for support with the key sentences, it is easy to keep it short. And if it gets too long it is easy to shorten it. Every section starts by saying what is most important. If you write too much in any section you can trim the unimportant stuff from the end.
The Easy Way
It’s only a grant application. Why make it difficult?
Despite these advantages of the key sentence approach, most writers prefer to write a grant the easy way. They just start writing. If you write the easy way you won’t have the key sentences to guide your writing but you will have saved yourself two hours of dull work, so as long as you can work out what to write you will surely finish sooner if you start the easy way.
It’s obviously best to discuss the most important issues first. Describe your research question and what makes it important to your chosen funder. Pretty soon you will have several pages of text. There’s lots of helpful advice on the web about what you should include. A google search on writing a good research grant application give 37.6 million hits. Some of the top hits in the google search are written by the funders themselves. The funders tell you exactly what to do, in detail. This page on content and presentation on ESRC’s website lists 37 points you should include and 5 questions you should answer. Following this advice will make it very easy to write a lot of text very quickly.
Unfortunately, there is no advice about how to write clearly. The most likely outcome is that the document you write will be a misshapen monster, far too long and completely unreadable. Editing a badly structured document of any kind is futile and utterly miserable. The excellent @thesiswhisperer blog likens the process to fighting a jungle war. If you are unlucky, you will have supportive colleagues who will encourage you to persevere in this miserable task. In fact you should quit and start again.
You should quit because because line-by-line edits do not fix the real problem, the poor structure. The more you edit, the worse it gets. You will work for months and when you finish you will know in your heart of hearts that your case for support is a mess.
Foolishly, you will nurture a vain hope that maybe you are being overly critical because you have been working so hard. You will reach out to your supportive colleagues for reassurance. They will know how hard you have worked and will want to support your morale, rather than help you write a good case for support. When you ask them for comments, they will lie, to protect your morale. They will see that the case for support is a mess, but they want to be supportive, so they will tell you to dot a couple of i’s and cross a couple of t’s and you will breathe a sigh of relief and submit your grant application.
The point at which you discover the truth about your grant application is when you get the results of peer review, nine months after submitting. At this point you will probably no longer be pleased that you saved the two hours it would have taken to write the key sentences.
My Raspberry Pi on the kitchen table. The computer is in the small clear plastic box on the right of the picture.
I am writing this post on a computer that I built from parts that cost less than £100. I haven’t tried to take a computer apart or put one together since I gave up research about 10 years ago but my eight-year old grandson, recently expressed a desire to do some coding. I decided that I should build him a machine of his own to avoid the risk of him damaging the machine on which I make my living. I still remember one of my early coding mistakes. It destroyed months of work by several of the researchers who used the computer on which I was learning.
The computer I built is a Raspberry Pi, product of a project that started at Cambridge University, to develop a computer that would be easy to program and modify. The aim was to get a hundred or so computers to use at university open-days so that students could get some pre-university experience of programming. By the time the first units were shipped in 2012 it was clear that the producers had underestimated demand. By 2016 over 10 million Raspberry Pis had been sold. I bought two, one for my grandson and one for me.
The cheapest Pi, the Pi zero, costs less than £5 for the main board. Ours are top of the range model 3Bs, which cost £28 each. They have a 64 bit processor, a gigabyte of memory, WiFi, 4 USB ports and a HDMI display port. The main file-store is a 64Gb micro-SD card. I salvaged two cards from disused mobile devices. I bought a couple of cheap colour displays but we could have used a digital or analog tv. I bought my grandson a combined keyboard and touch-pad for £17:50 and I am using a disused bluetooth keyboard and a USB touch pad. The Pi can use a phone-charger as a power source but I have bought a powered USB hub to make switching it off a bit easier.
The performance of the Pi compares favourably with the desktop computers I used during most of my career, although it is no match for my £2000 iMac. The operating system is Linux, which shares many features with the Apple Mac’s unix-based operating system. The memory and file storage are vastly greater than I had early in my career.
The computer on which I wrote my PhD thesis had less than a tenth the amount of memory (28K) and less than a thousandth as much filestore (256K). It was also the size of a wardrobe and it cost nearly twice as much as the first house I bought. If you compare prices then and now, the Pi system I built is an amazing bargain. For the current price of my old house you could buy more than five thousand of them.
Scrivener is designed for assembling a long document from a large number of components.
This post is about using Scrivener to write a grant application. I have wanted to write the post for a long time but I was held back by the fact that it is about an idea that, until last week-end, hadn’t come to fruition. The idea is that Scrivener is the ideal tool for writing a grant application.
Scrivener’s strength is that it is designed for the task of assembling short sections of text into a larger document and for editing and rearranging the segments until they work together. This is exactly the problem with a grant application. You have to assemble the background information about your research problem and the description of your research project and then edit and rearrange them until they work together as a coherent sales pitch for the project.
For the sales pitch to work, reading the background information about the research problem must make the reader want that research project and no other. This requires the content of the background to be exactly tuned to the content of the project. This kind of fine tuning is much easier if you draft the corresponding subsections of the background and the description of the project, which will end up several pages apart in the final document, side by side.
Scrivener was designed to do exactly this. It is a program designed for writing novels. I discovered it through Twitter. Someone I follow, whose writing I admire, said they found it invaluable, so I wanted to find it invaluable too. But the sad truth is that I never have. My problem is that Scrivener isn’t very easy to use. In fact it’s pretty difficult. Everything I have ever tried to do with Scrivener is much easier to do with a different program. Last week end, this changed.
Last week-end I had the grant-writing assignment from hell. I had four days to assemble a case for support. The raw material I had was patchy, to say the least. I had about 30 pages of text provided by eight academics scattered across four continents. 95% of the text was about research but the grant was about building research capacity. Important components of the research project were still being written, whereas the source of text on building capacity and capability had run dry. The least of my problems was that the grant was a kind I had never written before, requiring the case for support to have a unique structure and a limit of 10 pages.
The first thing I had to do – fortunately I had done this the week-end before – was to overcome Scrivener’s two great weaknesses.
It isn’t very good at producing Microsoft Word, which is pretty much the only medium in which the academics I work with can collaborate on a text.
Its approach to references and bibliographies is extremely limited.
I needed to find a way that I could convert Scrivener text into Microsoft Office, completely reliably and with very little effort. I needed to get Scrivener to interface with a good referencing software package so that I could combine the citations provided by all the different contributors into a single bibliography, in a compact format.
Fortunately I had discovered an excellent blog post by David Smith explaining how to use a program called pandoc together with the excellent reference software Zotero to produce Microsoft word output from Scrivener. Pandoc converts a text file produced by Scrivener into a Word document, which uses styles defined in a document of your choice, and Zotero inserts and updates and formats citations and a bibliography, which has a style determined by a csl file, thousands of which are available on Zotero’s website. I had never used Pandoc or Zotero, so it took me about a day and a half to become proficient enough with them to get the process working reliably. While I was getting pandoc to work I also found this csl file, which makes pandoc produce bibliograpies in the style of an obscure Italian law journal that does not require the titles of journal papers.
I was slightly apprehensive that Pandoc, which is a 1970’s style unix command-line application, requires you to type a monstrously long command into a terminal app. This is the command I used.
This command specifies the citation process, the path to the Word document with the correct styles, the format and the name of the input file, that the output should be a standalone file, that repeated white space should be stripped out of the input, the format to convert to and the name of the output file and the name of the input file. Other details, such as the datafile and format specification for the bibliography were specified in the input file but they could also have been specified in the command. It takes a few tries to get the command right but once you have got it right you can repeat it whenever you need to by pressing the up-arrow key.
Once I had taken care of its weaknesses, I could start exploiting Scrivener’s great strength, its facilities for assembling a large text document from a series of snippets of text that have to be organised in different ways. Text came to me as Word documents, which I converted to raw text, marked up with formatting instructions in ‘Pandoc-flavoured Multimarkdown’. These instructions are very simple, and they cover the bare minimum – six levels of heading, numbered and bullet lists, bold and italic – so it only takes a few minutes to mark up a whole case for support and it is very easy to keep the mark-up consistent. It reminded me of writing my thesis in the 1970s, using runoff on a minicomputer, which was a machine the size of a wardrobe with 0.05 Mb of memory, 0.25 Mb of disk that cost £25,000 (£140,000 in today’s money).
Exchanging edits and comments with colleagues was easy. I would send them the draft case for support as a word file and they would send back the same file edited with track changes, send me comments, or send me more text. I had to convert their edited text back to raw text, mark it up, and put it into Scrivener. This was quick and easy because I kept each contribution as a separate file, and it avoided the formatting errors that frequently happen when you merge Microsoft Word files.
Adding references was very easy. As long as the writer could identify the paper I would be able to find it and add it to my Zotero database. This was easiest if the writer used the DOI or the Pubmed ID but in several cases I succeeded with nothing more than a google search for the author names, year, and journal title.
The funder’s instructions for writing the case for support required seven different sections so I created a folder for each section and sub-divided the contributions from different writers between the sections. Scrivener makes it very easy to split a file at any point. You can also select text in the file to use as the filename. This makes it easy to create separate files for each little subsection and to give them names that tell you what is in them. By the time I finished editing the case for support it comprised about 30 files.
Scrivener’s Corkboard makes it easy to rearrange the sections of a document.
Using separate files makes it very easy to reorganise the text if you decide the structure is wrong, as I did reluctantly when one of the contributors pointed out that the case for support looked as if the main point of the grant was research, whereas the funding call was for building research capacity and capability. Completely restructuring the case for support involved splitting one file into six or seven pieces to be distributed throughout the document and reorganising the other files so that I now had a two level structure, with folders and files. Scrivener has a very flexible view of folders and files, you can convert one into the other, but the advantage of a folder is that it allows you to move a group of subsections at the same time, without changing their relationships with each other, in a single drag and drop. The whole restructure, which felt as if I was turning the case for support inside out, took me a couple of hours.
Without Scrivener I couldn’t have written the case for support before the deadline. Two features were crucial: the ease of restructuring, and the rock-solid reliability with which I could create a perfectly formatted Word file after every edit.
Restructuring a case for support in Word is possible: you can use the outliner to move subsections around, but it is very hard to keep track of what is where, and I have never tried anything as complicated as this.
Preserving the format of lists and the styles of headings through an exercise like this may be possible in Word, but I have never managed to do it. I spend huge amounts of time renumbering numbered lists and at least once in an exercise like this I will have to recreate all the heading styles from scratch.
Scrivener has a couple of other features that make it useful, but not uniquely so.
It allows you to assemble all the background information you need and keep it together with the text in a file called the project. You can do this by using the folder structure of the file system.
It allows you to tag files in different ways so that it can produce several different output files from the same project. I used this to produce other documents, like the pathways to impact, the summary and the objectives.
Finally, there is one thing I would like Scrivener to do that I haven’t yet managed to do. I would like it to insert boilerplate text several times in a document. Followers of this blog will know that I like to repeat myself and that I will re-use a key sentence several times. If I could do this by referring repeatedly to a single sentence, so that all the instances would change if I edited any of them, that would be perfect. Then I would be able to write a whole case for support by numbers!
Whom should you ask for feedback on your grant application?
The best option is to ask the right kind of expert, if you can. Expertise on grants is much more important than expertise in your subject. The ideal person would be someone who has served several years on the grants committee that will consider your proposal. Failing that, you could ask someone who has wide experience of similar grants committees and a good understanding of the scheme for which you are applying. Unfortunately these people tend to be busy and you may be in a hurry. You can ask Parker Derrington Ltd to read your grant application and give you face-to-face feedback by Zoom, but you would have to pay. What can you do if you don’t have an expert on call and can’t afford to pay one?
If you can’t get an expert, you should choose an ignoramus, or someone who can act the part as far as your project is concerned. You need someone who does not share your views about what is important in your subject but who is open-minded. This mimics the kind of expertise that a grants committee member will have. The ideal person would be someone at your level, in a different but related field. It can be a good idea to exchange feedback with a colleague in a different subject area who is also preparing a grant application. It is a mistake to use someone who knows as much or more than you do about the area of your project, unless they are sufficiently experienced in the way grants committees work that they will be able to discount their knowledge of your subject.
How should you ask for feedback on your grant application?
If you ask a real expert for feedback, it doesn’t matter how you ask, they will give you useful feedback. Otherwise, you need to design your questions carefully if the answers are to be useful. Here are some suggestions.
Write down the main outcome of the project. Mark where it describes it in the text with a (1)
Mark with (2) in the text the section that gives evidence that the main outcome is important. Can you think of anything else that could be said to support the claim that the outcome is important?
Is the importance of the outcome specific to this funder? Mark any references to the funder’s goals with (3).
How many separate components does the research project have?
Mark with (5-1), (5-2) etc, the sections of text that state the outcome of each component of the research project.
Mark with (6-1), (6-2) etc, each section of text that explains how important the outcome is of a component of the research project.
Mark with (7-1), (7-2) etc, the sections of text that give citations that support the explanations in (6-1), (6-2) and so on.
Mark with (8-1), (8-2) etc, the sections of text that describe the research processes that will produce the outcomes (5-1), (5-2) etc.
For each of these sections, can you mark with (?) any processes that are not clear, and can you suggest any extra processes that might be needed in order to produce the research outcome.
Mark in the text with (1) where it states what will be done to make sure that the overall outcome of the project has maximum value to the funder. Can you think of any way that this could be made more valuable to the funder.
You should ask the reader to spend no more than half an hour answering these questions. If they are unable to answer them in that time then you need to do some serious rewriting.
Finally, you should know that the correct answer to question 4 should be three.
Make sure that your feedback sandwich has plenty of meat.
This is one of a series of posts with advice for people who review grant applications for their friends and colleagues. It is also intended to encourage people writing grant applications to review what you have written before you ask a colleague to read it and tell you something you could have worked out for yourself. My last post argued that a quick and easy way of reviewing a grant application is to check its structure. Good structure makes a grant application easy to read.
Most applications will have very poor structure. If the structure is poor, it is not worth reviewing the detailed content. One reason is that it will take too long. Another is that, even if the content is very good, a funding committee’s enthusiasm for the application will be limited because the poor structure makes it difficult to understand.
At this point I feel honour-bound to confess that I have hesitated a couple of weeks before finishing this post because I know that many people find my feedback a bit too direct. They like to soften criticism by constructing a feedback sandwich that smothers useful comments in copious quantities of praise. My view is that feedback should be clear, it should explain how the proposal can be improved, and it should be delivered as quickly as possible. Feel free to cut and paste from what follows and to wrap it up in whatever form suits you.
The application should have an introduction that states clearly:-
what goal the project will achieve;
why the goal is important;
about three aims, which are things that we need to discover or understand in order to achieve the goal;
the general research approach;
about three research objectives, which are pieces of research that will enable us to achieve the aims; and
what will be done with the results.
These statements are what I call the ‘Key Sentences’. They are a distillation of the argument that the project deserves funding. If the grants committee believe the key sentences, they will almost certainly award a grant. So the rest of the case for support should be designed to make the reader believe the key sentences. It does this by repeating them, and reinforcing them with evidence or explanation.
After the introduction, the case for support has two main sections, each of which repeats six of the key sentences and then justifies or explains them. The background section deals with the goal, the importance and the aims. It should explain, with evidence, why the goal is important and how meeting the aims will achieve the goal. The description of the research project deals with all the rest. It should explain in detail the research approach, the research objectives, and what will be done with the results.
The structure allows a reader to understand the message of the grant in 2 or 3 minutes, by ‘speed-reading’ it. This is very important. The committee that decides whether or not to award the grant will have dozens of other applications to read and discuss. Most members will have a limited understanding of the detailed argument. Some of them will still be reading the application during the final discussion about whether to fund it. All of them will have a say in whether it gets funded. They will be much more enthusiastic to fund an application that they can understand and remember.
The structure also helps the referees who will read the proposal thoroughly and write an evaluation. Each key sentence leads directly to the detailed argument and evidence that justifies and explains it. It is not quite as important to make referees’ task easy because each referee typically only deals with a small number of proposals. Moreover, their enthusiasm will be based on their evaluation of the detailed argument. But it definitely doesn’t hurt to make their task easy.
The opening sentence must whet the reader’s appetite. The best way to do that is to say what the project will achieve, together with something about how it will achieve it, ideally with a clear implication that the research team are well qualified to do the work. For example, the sentence “This project will develop a new potential treatment for stroke based on a family of synthetic metabolic inhibitors that we have discovered, and synthesised” achieves all this. The reference to discovery and synthesis suggests that the project is a continuation of past work. Of course the suggestion that the project continues previous work does not testify to its importance – that will rest on the opening clause, which states that the project will develop a new potential treatment for stroke.
Draft grant applications quite often have a good opening sentence. But it is not usually at the beginning. Usually it is somewhere towards the middle. Skim through the whole case for support to see if there is a suitable opening sentence that can be moved to the opening position.
It is useful to repeat the opening sentence at the start of the background section, which usually follows after the introduction. It is also useful to open the summary with the same sentence. Repetition of this kind is very good: it helps the reader to remember the essential message. Unfortunately most academics don’t like to repeat a message unless they can confuse readers by using completely different words.
It’s useful to have a sentence explaining that what the project will achieve is important and to have it follow the opening sentence, which says what the project will achieve. Health, social, or economic benefits are usually, depending on the remit of the funder, good reasons that something is important. Solving a major theoretical problem may also be a good reason. Being the next logical step from the applicant’s previous research is typically not a reason for importance, although mentioning this kind of progression can be a useful way of supporting the proposition that the applicant has the necessary skills to carry out the research.
The importance sentence should also be repeated in the background section and in the summary.
I suggest that there should be about four aims. I also think that because funding agencies often ask you to state aims and objectives, you should use them as key parts of the structure. A good way to state an aim is to say that “We need to know” something. There are three important things to check about each stated aim.
The aim should be restated, word for word, in the background section, where it should be followed by a few paragraphs that convince the reader that this is an important aim. Usually they do this by citing appropriate literature. Stating and justifying the aims like this is a device to create a direct link between what the project will do, and an important underlying question that the funder will pay to have answered. It’s also a way of papering over the cracks when the link is a bit tenuous.
The aims of the project should also be stated in the summary. Repeating them exactly, using the same sentences, is a good way of helping the reader to remember them.
Project overview sentence
It is useful to have a sentence that says what kind of research project is envisaged and what the likely outcome will be. It’s often necessary to have something that puts the reader in the right frame of mind for the subproject overview sentences. This sentence should be in the introduction and should be repeated at the start of the section of the proposal that describes the research project in detail.
Sub-project overview sentences (Objectives)
The essential difference between aims and objectives is that, aims tend to be abstract and objectives tend to be concrete. Aims are things that we would like to achieve. Objectives are the concrete things that we will do in order to achieve those aims. Thus the four or so sub-projects that comprise a research project are objectives. Matching the objectives to the aims is a good way of convincing the reader that the research needs to be done: the description of each sub-project should begin with a sentence that includes the phrase “this will tell us” whatever the corresponding aim says “we need to know”.
These sentences should be ‘pre used’ in the introduction and in the summary.
The last substantive sentence in the introduction should say something about what will be done with the results. Again, this sentence should be re-used to introduce the last sub-section of the description of the research project, which should explain it in detail.
So, that’s the filling for the feedback sandwich. How do you wrap it up? I think that it’s up to you to use your judgement. All the wrapping does is to set a baseline. In my view it doesn’t much matter where the baseline is, as long as it is absolutely clear how much the structure of the case for support could be improved.
I should point out that some funders, including several UK Research Councils, require applications to contain a section detailing the achievements of the research team. That section, which is an excellent way of supporting the competence proposition, is in addition to those discussed in this post.
This post tells you how to do a five-minute review of a research grant application. If you are asked to comment on a grant application by a friend or colleague, you should begin with this five minute review. In 95% of cases it will be all you need to do. Except create the feedback sandwich of course.
If you are writing a grant application, before you ask anybody else to read it you should spend five minutes reviewing it yourself. Far too many of the grant applications that I get asked to read take me a lot less than five minutes to review. Then it takes several days to construct a palatable feedback sandwich with the filling “rewrite this completely”.
I don’t say you can review the detailed content of a grant application in five minutes. That takes longer and I will write about how to do it quickly in a future post. However, five minutes is plenty of time to review the framework of the case for support and check that it is appropriately used.
The framework is important for two reasons. First, if it is good, it tells the reader the essential story of your grant application very quickly. Remember, most readers only want to know the essential story. Second, the framework guides the reader to the detailed content that supports and justifies the essential story, so that the detail can be reviewed effectively and quickly.
The most important part of the framework is a summary sentence. This should say what the project will achieve and enough about how it will achieve it to give a bit of distinctiveness and a bit of plausibility. It is essentially the elevator pitch, except that instead of taking 30 seconds to 2 minutes to say it or read it, it should take more like 15 seconds. The summary sentence should be the first sentence of the introduction, so it should take no time to find it, you still have 4 minutes 45 seconds left.
If you read my last post you will recognise that the summary sentence is what I refer to there as the first key sentence. So it will come as no surprise that you should check that the summary sentence is re-used as the first sentence of the part of the case for support that sets out the background to the research project. Let’s allow 15 seconds to do that. 4 minutes 30 seconds left.
Now you should spend 20 seconds checking the second sentence of the introduction. It’s the importance sentence. It should say something about why it is important to achieve whatever the project will achieve. Make a mental note about whether the importance sentence has a practical element. Does it mention a real world problem – childhood cancer, the economy, forgetfulness in old-age, or some such. It’s not essential that there is a practical element to the importance sentence but it has implications for the dissemination sentence, which you will review in a few minutes time.
As soon as you have checked the importance sentence for practical content, jump to the background section and check that the importance sentence is repeated there. This is just a quick glance, so it should only take you 10 seconds. You have 4 minutes left.
Go back to the introduction. Immediately after the importance sentence there should be a set of aims sentences, about four sentences setting out the aims of the project. The aims sentences should state things that we need to know, understand, characterise or in some way discover. The aims sentences could be preceded by a linking or framing sentence and they could easily be formatted as bullet points. Checking that the aims sentences are in the right place should take you 10 seconds. Do not look at the content of the aims sentences yet. Wait 30 seconds until we get to the sub-project overview sentences.
Now you should check the next sentence of the introduction. It should be the ‘project overview sentence’.
Project overview Sentence.
The project overview sentence gives a simple one-sentence overview of the project. It might also be structured as a linking sentence to the four or so sub-project overview sentences, which should immediately follow it and which could appear as bullet points and could be expressed as objectives. It should take you 30 seconds to read the project overview sentence and 20 more to check that it appears again to introduce the part of the case for support that gives the detailed description of the research methods and of the project.
Next you can spend 10 seconds checking that the sub-project overview sentences follow the project overview sentence. Now you are ready to check their content against the content of the corresponding aims sentences.
Sub-project overview sentences; content of aims sentences
Each aims sentence should link logically to the corresponding sub-project overview sentence in the following way. The aims sentence should say “We need to know X”. The sub-project overview sentence should give a very brief description of the research in the sub-project and should end with a clause that says “this will tell us X“.
The aims sentences should be repeated in the background. Each of them should introduce a discussion of the evidence that supports the assertion that this is an important aim.
The sub-project overview sentences should be repeated in the part of the case for support that describes the project in detail. Each of them should introduce the detailed description of the corresponding sub-project.
This checking and matching will probably take nearly a minute to do for the first aim/sub-project overview sentence pair but the others should be much quicker. It’s just a matching exercise after all. Lets assume it takes 2 minutes. You have a minute left, and only the dissemination sentence to check.
The dissemination sentence
The last sentence of the introduction should say what will be done with the results. It is the dissemination sentence. You need to check that it is repeated in the description of the project as the introduction to a section on dissemination. You also need to check that, if the importance sentence has a practical component then the dissemination must have a corresponding practical element. For example, if the project is going to discover a cure for a disease, the dissemination needs to promote the use of the cure in some way. As a general rule there must be a plan to disseminate the results in a way that makes it likely that the claimed practical benefit will be realised.
What to do with the outcome of the review
Only about 5% of grant applications will pass this five minute review. If you are reviewing a grant application for someone else and it passes, it should be pretty easy to review the detailed content. I’ll give some helpful pointers in a future post. It goes without saying that if the grant you are reviewing is yours, it is safe to give it to someone to review.
In the more likely case that the grant application fails the review, then it needs rewriting. If it’s yours, that’s pretty simple. Read my post from last week. Write the 10 key sentences and use them to organise the text you have already written. If you can’t write the 10 key sentences then you shouldn’t be writing a research grant.
If the grant application is not yours, you need to write a feedback sandwich. Basically the grant needs to be rewritten before it’s worth looking at the detailed content. I’ll say something about how to do this in my next post but whatever you do don’t use the phrase “completely rewrite”.