Writing a research grant application: the quick way and the easy way.

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.

If you are lucky, when you find yourself with a misshapen monster grant application, you will engage a consultant like me who will tell you some really good news. Your misshapen monster of a grant application can be salvaged. There is an easy way to restructure the case for support that only takes a day or so. You start by writing a set of key sentences……..

My £30 DIY Computer

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.

What’s the Point?

I want to explain why I think it’s better to produce a well-written grant application than a poorly written one. Obviously, given the nature of my business, I have to make this case, but it is not as simple as you might think, not least because most successful grant applications are very poorly written. In fact, if you think carefully about the quality of grant applications, it becomes clear that, in this particular domain, quality is completely subjective. So I will start by saying what I think makes a good grant application.

The quality of a grant application is not the same as the quality of the research project it describes. A grant application is essentially a marketing document for a research project and you can have a first-rate application that markets a tenth-rate project. And vice versa. Indeed  poorly-written grant applications are very often successful precisely because grants committees are trying to judge the quality of the project, not the quality of the application. Judging the quality of a project can be very difficult if the application is poorly written. So what makes a good grant application?

The essence of a good grant application is that it makes it easy to judge the project. The application contains all the detail that an expert will look for. The detail should be set out so that it can be read at very high speed and understood by a non-expert. As a rule of thumb, it should take less than two minutes to understand the main points of what you will do and why it is worth doing.

Those main points should be expressed and justified in such a way that a non-expert ‘gets’ what you are going to do and why. An expert should also be able to drill down and find the detail that they need in order to judge whether your project is likely to succeed and achieve those main points. I have already explained how the ‘key sentence’ structure enables a grant application to fulfil these requirements.

Despite the fact that most successful grant applications are poorly written, there are three reasons that it is worth taking trouble to produce a well-written grant application:-

  1. If your project is good, a well-written application will improve your chance of success.
  2. If your project is bad, a well-written application will help you to see that it needs to be improved.
  3. A well-written application can be easier and quicker to write than a badly-written application.

I’ll deal with the first two reasons in this post and I will leave the third for the future.

Well written applications are more likely to be successful.

Well-written applications generate an enthusiasm among committee members that makes them give higher scores. For reasons I’ll explain in a future post, the person leading the discussion is likely to recommend a relatively conservative score, no matter how much they like the application. But if the committee are enthusiastic, they are quite likely to argue that the recommendation should be raised, and to exceed the recommendation when they score.

Poorly written applications can also get high scores, particularly if the referees have given very strong recommendations, but when committee members don’t understand an application they will not argue for a higher score and they may even score slightly below the recommendation. The consequence is that the scores of poorly written applications tend to drift downwards. The effect is small, but if the score is close to the borderline, which is likely to be the case, given the tendency for conservative recommendations, a tiny drift can make the difference between success and failure.

A well written application helps you see that you need to improve your project.

A well-written application explains your project very clearly at two levels.

  • First it explains what makes the project important to the funder.
  • Then it explains what the project consists of, and why each part of the project is important.

If your project needs to be improved, you are likely to find one or both of these explanations unconvincing as you write them. If you do find yourself writing arguments that you find unconvincing, then you need to reexamine your project and work out how to make it more convincing. If your application does not convince you, it is unlikely to convince a committee.

 

Lists: Keep them Short; Use Bullets.

Oxford college eights training early on a November morning

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

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

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

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

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

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

Lists Should Have Fewer than Five Items

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

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

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

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

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

Lists Should be Formatted

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

Why did I relax my rule in this blog post?

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

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

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

How Key Sentences Work

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 Case for Support: Structure Solves its Problem.

Birdy folding bicycle front fork.

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

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

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

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

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

The case for support has to do all those things without them actually reading it. That is the main problem.

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

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

A three-layered structure.

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

Main Structure: Introduction, Background and Methodology.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fine Structure: Key sentence followed by justification.

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

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

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

The Introduction

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

The perfectly matched summary

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

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

Catalogue

The posts discuss 8 themes:-

  1. How to write a Grant Application
  2. Strategy for writing grant applications
  3. Writing Style for Grant Applications
  4. Giving and Receiving Feedback on Grant Applications
  5. Dealing with referees reports and with rejection
  6. Interviews and Talks
  7. Software
  8. Academic Life and Afterlife

How to Write a Grant Application

Strategy for Grant Applications

Writing Style for Grant Applications

Friendly fire: Giving and receiving feedback

Dealing with referees reports and with rejection

Interviews and talks

Software for Writing Grant Applications

Academic life & Afterlife

Scrivener for Grant Writing

Scrivener is designed for assembling a long document from a large number of components.

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.

$ pandoc --filter pandoc-citeproc --reference-docx=/Users/amd/Dropbox/02Andrew/11-Scrivener/pandoc/reference.docx -s -S --normalize  -f markdown -t docx -o CaseForSupport.docx -i CaseForSupport

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.

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!

ERC Grant Interviews: Recipe for a Good Talk

EurosI 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.

Slides

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.

Life After Academia

More enjoyable work and less of it!

More enjoyable work and less of it!

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.