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.
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 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.
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
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.
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.
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.
Key sentences define the structure of a case for support and ensure that every reader gets the same picture.
A crucial challenge in writing the case for support in a grant application is that the finished document will be discussed by a group of people who have read it at different levels. For example:-
The referees will have read and analysed every last detail, in order to write a report for the grants committee.
The presenters will have read it very carefully and will have created their own summary of it, which they will present orally to the committee.
Most of the committee will only have read the summary but many of them will glance through the case for support when the committee are discussing it.
Members of the committee who find the case for support interesting will also read it in detail.
If the discussion is to be fruitful, all these people should get exactly the same picture. Detailed reading of the case for support should produce exactly the same picture as riffling through it at high speed, which should produce the same picture as reading the first page and stopping when it gets boring, which should produce the same picture as reading the summary and ignoring the case for support completely. All these different ways of reading should produce the same picture. The only difference should be in the level of detail.
To solve this problem, you build the case for support from a skeleton of key sentences. In the full case for support, you flesh out each key statement with a few paragraphs of text to create a subsection. The key statement summarises the subsection that fleshes it out. In this way the case for support consists of a number of subsections, each of which begins with a key statement. If you string the key statements together on their own, without the subsections that flesh them out, you get the same story as the full case for support, but with less detail.
The full case for support fleshes out the key sentences with supporting detail, whereas the summary consists of the key sentences on their own. This ensures that people who read the full case for support get the same story as those who only read the summary. It also means that a reader who attempts to create their own summary from careful reading of the case for support is likely to create a very similar summary to the one you supply.
You can use the first sentences of paragraphs in the same way, to create a summary of a piece of text. This blog post has been written using the key sentence approach at the paragraph level. Each key statement is fleshed out with a few sentences to create a paragraph. You can see how the approach works by taking the first sentence from each paragraph in this section and stringing them together. It should make a good summary. Check the key sentence summary below to see how this works.
A second benefit of this assert-justify approach is that the key sentences act like signposts to tell the referees where to find the information they want. The referees will read the summary before they read the case for support and, as they read the summary, a series of questions and doubts will arise in their minds about whether the summary is backed up by detail. The key sentences in the body of the case for support will show them where to look for the detail.
In sum, the key sentence approach gives a summary that tells the same story as the extended version and makes it very easy for referees to find the information that they want. In the bullet points that follow you can see the summary of this blog post created simply by cutting and pasting the first sentence of every paragraph.
KEY SENTENCE SUMMARY
A crucial challenge in writing the case for support is that the finished document will be discussed by a group of people who have read it at different levels.
If the discussion is to be fruitful, all these people should get exactly the same picture.
To solve this problem, the case for support is built from a skeleton of key sentences.
The full case for support fleshes out the key sentences with supporting detail, whereas the summary consists of the key sentences on their own.
You can use the first sentences of paragraphs in the same way, to create a summary of a piece of text.
A second benefit of this assert-justify approach is that the key sentences act like signposts to tell the referees where to find the information they want.
In sum, the key sentence approach gives a summary that tells the same story as the extended version and makes it very easy for referees to find the information they want.
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-justifystructure. 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.
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.
I have a number of clients who are applying for European Research Council grants, mostly starter grants. Those who have reached the interview stage this year have been notified and are now getting ready. The interview is short, typically 25-30 minutes, and begins with a talk of about ten minutes. The exact timing of interview and talk varies and candidates have yet to be notified of the exact timetable of their interviews.
Most people give pretty bad short talks, so this seems like a good time to give you a recipe for a good one. This recipe works for any research-based short talk.
Choose a Suitable Message
The recipe is based on a very simple principle. You must decide on a suitable message that you want the audience to remember at the end of your talk, and you must structure the talk so that they remember that message.
The message must be short. A sentence, or possibly three or four short bullet points is ideal. If the message is too long the audience will not remember it.
Before you decide on your message, think about your audience, the interview committee. The committee will include one or two specialists in your subject but most of them will be specialists in something else. You want the whole committee to understand your message so make it broad, and don’t use overly specialised language.
The ideal message for an ERC interview talk would say what the project will deliver and what makes this deliverable important. If there is time you might try and say something about the research approach and something about your qualifications to use the approach. Even if the research approach and your qualifications aren’t part of your main message you should certainly touch on them during the talk. It is no coincidence that my recommended message matches pretty closely the first two key sentences of the case for support, as described in this blog post.
Structure of the talk.
My recipe prescribes a very simple structure for the talk.
Start by stating the message.
Break the message down into components.
Explain each of the components.
Resynthesize the the original message to close.
I would use the 3 components of the project as the 3 components of the talk. I recommend the same structure for the case for support, as you can see, here, here and here.
It is easy to get hung up about slides and to trap yourself with rules that don’t always work – such as ‘no writing on slides’. But I do have some recommendations:-
Don’t have too many slides. I will usually have no more than 6 for a 15 minute talk.
Use each slide to make a point. Know what point you want to make with it. Design the slide so that it makes its point. Sometimes I will write the point as the slide title and I will always state the point of the slide when I first show it.
Make everything on your slide legible. You should be able to read everything when the slide is displayed on a standard size phone screen and held at arms length.
Make the slides self-explanatory: if you show data you must label the axes and have a key. When I listen to a talk I usually flip between listening to the speaker and reading and analysing the slides to check whether I agree with their interpretation.
When I show a data slide I start by saying what point the data make, which will usually be a question of interpretation. Then I explain how the data are plotted, the axes and so on, then I then interpret the slide by explaining which features of the plotted data make the point.
Don’t have so much text on the slides that your talk consists of just reading the slides.
Practising, notes and scripts.
You should practise your talk several times so that you know that it fits within the time limit. Try to practise with an audience. Most people speed up when they get nervous, so when you get to the interview, remind yourself to slow down so that you remain intelligible.
I would never read a talk from a script, nor would I learn a script word for word. If I am very nervous I will learn the first sentence of the talk, and repeat it many many times, so that when I start the talk that sentence comes out automatically. That gets me started and usually settles my nerves.
I may also learn the sentences that state the points from each slide, although I usually write the point in short form as the slide title and I use the list of slide titles as notes.
Finally I will learn the last sentence of the talk, so that I can ‘bale out’ if I have to end the talk in a hurry because I have run out of time
Don’t Create Hostages
Some people think you should plant obvious questions in the talk by making some of your explanations incomplete, or that you should use the talk to repair any weaknesses that you can see in your application. I think both these strategies are risky.
Planting questions is risky because although the committee may ask you the questions that you have planted, if you make it obvious that you are hoping for them to do so, they might feel that you are manipulating them. Equally, you may make it too subtle and they might not ask the question you have planted and simply decide that you aren’t very good at explaining.
Using the talk to repair weaknesses in the application is risky because by doing it, you draw attention to the weaknesses. Your application was good enough to get you to interview, so they may not have noticed any weaknesses.
Of course, if the committee have noticed weaknesses in your application then they will ask you about them in the interview. Consequently, analysing your application for weaknesses is an important part of your preparation for the interview. I will write about preparing for the interview in a future post.
It is almost exactly 2 years since Parker Derrington Ltd opened for business and over a year since I changed career definitively and gave up my university job to become a full-time businessman.
The change of career was a leap in the dark but 3 key facts convince me that I have landed on my feet:-
I enjoy my work more.
I do less work.
I earn more money.
Of course, things could be even better and I want to use this blog to improve them. This post is a review of my career change and an outline of what I want to do better. It follows one of the good practices I developed as an academic manager – annual planning and target setting.
When I changed career, the target I set myself was to develop enough paid work to replace my salary before the end of 2015. I had a 3-point strategy:-
Start a blog;
Build a website;
Offer free workshops to people I knew and generous discounts to people that I didn’t.
My plan was that the blog would bring people to the website; the website would bring clients; and free workshops would turn friends into clients. I thought that any client that had a free or half-price workshop would very quickly order a full-price workshop once they knew how good they are.
I was wrong both about free work and about discounts. Clients act as if workshops are only worth what they pay. They act as if my workshops are worth nothing. The workshops are very good but the attendees seem to expect them to be bad. And, they don’t lead to more work: clients act as if they are reluctant to pay full price for something they have had free or half-price. So now I charge the full price and I offer new clients a BOGOF (buy one get one free – two days for the price of one). For many clients the BOGOF clinches the deal. I am careful to make sure that my invoice states the full price and applies the discount so that the client sees the full price even if they don’t pay it. Since I changed my approach, a good proportion of clients have asked for follow-on work at full price.
The website and blog, which I promote through Twitter, have also been very useful. Of the 30 different clients or organisations that have hired me, about 20 found me through the web site or through Twitter.
I met the target I set myself with a healthy safety margin. I earned more last year through the company than I would have done if I had stayed in my job. However, although my income is higher than it was when I was an academic, it is a lot less predictable. I never know when I will get offered work and the delays between working and getting paid are variable and huge. The fastest payer so far was the University of Exeter, which paid within 3 days of my invoice. I won’t name the slowest payer because, even though they took over 4 months to pay, they will probably be replaced by someone even slower quite soon. Almost all my business is with universities and almost all universities are apallingly slow to pay their bills.
My next target is to change the mix of work. At present it is about 60% teaching people how to write, 25% writing and editing, 10% consultancy and 5% coaching. I’d like to do more writing because that’s what I enjoy most. It’s probably also where I add most value. Very few clients trust me to co-write their grant applications and papers but those few are delighted with the results: better papers and grant-applications with less effort.
My target for 2016 is to shift the balance of business towards writing and consultancy. My strategy will be to use the blog, the website and direct contacts to promote writing and consultancy.
So do get in touch if you don’t know what to write, if you don’t know how to write it, or if you know what to write and how, but don’t have time.
A 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.
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?