Category Archives: Uncategorized

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!

Recipe for a NIH Grant

ManhattanI’ve just spent a very pleasant few days in New York City teaching post-docs at  Mount Sinai my recipe for a NIH grant. We focused on the K99/R00 scheme, which is for applicants less than 4 years from their PhD. K99/R00 applications must  include career-development as well as  research, which makes them more complex than a pure research grant, but the recipe I developed can easily accommodate other grant schemes by adjusting  the formula for their assessment criteria. Before I describe the recipe – how you get the grant written – I need to say something about the formula – what the finished grant consists of.

The Formula

The formula is based on the principle that you should make it as easy as possible for those who carry out the peer review of your grant to do their job. NIH makes it very easy to apply this principle because they take great trouble both to explain their peer review process and to list the review criteria for every kind of grant they offer.

The peer review process is carried out by a study section, a group of about 15 scientists whose expertise covers the area of the grant. Three of them, the reviewers, have to produce a written assessment of the grant and score it against the review criteria before the study section meets. At the study section the reviewers present the grant orally, then it is discussed openly and then scored by secret ballot. All members of the study section join in the discussion and vote on the score even though they may not have read the grant, although they will probably have read the 1 page Specific Aims, or the 30 line Summary. So the formula has two requirements.

  • It must be very easy for the reviewers to understand the grant quickly and to find the detail that shows whether or not it meets the assessment criteria.
  • It must be easy for the other members of the study section to speed read it and understand it.

To make it easy for reviewers, the three versions of the grant – the 12-page Research Strategy, the 1 page Specific Aims and the 30 line Summary should be recognisably the same, so that someone who has read the Summary or the Specific Aims should find the Research Strategy looks familiar. I recommend that you define the grant with a set of about 10 key statements that address the review criteria. The key statements begin major sections of the Research Strategy and are followed by text that justifies them and convinces the reviewer that they are true. The reviewer will be familiar with the key statements because they appear in the same order in the Specific Aims and the Summary, but with less text to justify them.

The repetition of the key statements between the Summary, the Specific Aims and the Research Strategy helps the other members of the study section to feel that they understand the Research Strategy as soon as they glance at it. To make it possible for them to speed-read it, the top line of every paragraph should contain the main message of the paragraph and there should be white space between the paragraphs.

The Recipe

To cook up a grant with this formula you need to start by deciding what key statements you need. NIH assessment criteria are very helpful here.

  • All grants are required to have a number of specific aims – goals that the research hopes to achieve. Three is the ideal number of specific aims – just as it is the ideal number of points to make in an emphatic statement.
  • The Research Strategy document must be divided into three sections, each of which is assessed. They are Significance, how important the research is; Innovation, what is new about the research, and Approach, how you are going to do the research.

Each specific aim needs one key statement to state its significance and one to state the approach to achieving it. Innovation can be stated separately for each aim or in a single staement that covers all three aime. Thus you need between 7 and 9 key statements to cover the basic criteria.

In addition you should have a couple of key statements to introduce the Research Strategy. These make the ‘elevator pitch’. The first needs to say what overall outcome is hoped for, something about how it will be achieved and something about your credentials for carrying out the project. The second needs to say something about the project’s overall importance. You can think of these statements as the opening remarks of the reviewer addressing the study section. They correspond to key sentences 1 and 2.

Finally you probably need an ‘onwards and upwards’ statement to finish off the Research Strategy, something that says how you will take the research forwards at the end of the project.

The K99/R00 grant has a training requirement. The research project must contain a mentored (K99) component and an independent (R00) component. The candidate is also required to submit a training and career development plan. The criteria make it clear that the K99 project must develop the candidate’s skills to prepare them for the independent phase. One or two extra key statements are needed to address this aspect of the project.

Once you have drawn up your list of key statements you draft them. They are the introductory sentences of the main subections of the Research Strategy. Don’t spend too much time perfecting these sentences. Get on with writing the sections that they introduce. As you draft those sections you will naturally polish the key statements until they are as good as you can make them.

Once you have a complete draft of the Research Strategy you can copy the key statements from it into the one-page Specific Aims document. Make that document up to a page by cutting and pasting more text from the Research Strategy or by drafting new text. You should cut and paste wherever possible to maximise the overlap between the two documents.

There are a number of sources that help you with content.

These can help you to modify the formula by choosing different sets of key statements and by varying which key statements appear in the different components of the application. But the best way to minimise the pain of writing is to follow the recipe.

Can your grant application stand up on its own?

13550103_sThis is the third in a series of posts explaining how to edit your grant application into the right shape. In order to stand up a grant application should consist of three sections that are shaped to support each other. They are:-

  • An introduction that prepares the reader for the points the other two sections are going to make. It is less than 20% of the total.
  • A background that convinces the reader that the world needs the results that your project will deliver. It is less than 30% of the total.
  • A description of the project that makes it clear that your project will deliver the results that are needed. It is at least 50% of the total.

If you have followed the advice in my last post you will have done the most important part. The second half of your application will be a description of your research project in five or six subsections. The subsections are introduced by matched key sentences that say what your project will produce and what you will do with the results. The sub-section that follows each key sentence adds the detail that will convince the reader that your project will deliver what the key sentence promises. Now you have to write a background section that sells the promises.

The shape and content of the background section are dictated by the description of the project. This follows from the fact that the function of the background is to sell the project. Obviously it should sell everything your project will deliver. Equally obviously it shouldn’t waste time or space by selling anything else.

So if you are editing the background to support such a description, the first thing to do is to create the sub-sections it needs by drafting the key sentences that introduce them. You need the following sub-sections:-

  • A sub-section that states the overall outcome of the project in a way that makes it clear that it is exciting and that stakes your claim to carry it out. This is introduced by the first key sentence, which ideally states the overall outcome of the project, links it to an important research question and to a distinctive claim for competence. The sentence says “This project will do X, which will (partially) solve huge research problem Y, by using technique Z, developed by our group.” For example “This project will develop a potential treatment for Alzheimer’s disease by testing the efficacy of a plaque-dissolving molecule, which our group has discovered, in a mouse model of the disease”. The subsection prepares the reader for the “we need to know” subsections which are preceded by the “importance” subsection.
  • A subsection that discusses the importance of the problem and of the contribution that your project will make to its solution. This subsection is introduced by a key sentence about the importance of the problem and of your project and has two functions. First it is like a funnel for the importance of the question. If you have picked a problem that is big enough to be exciting then it is unlikely that a single project will solve it completely. Everybody knows that. But everybody needs to be convinced that what you will do will be an important step towards a solution. So you need to help the reader to see that the piece of the problem addressed by your project is important. The second function is that it creates the need for whatever you will do to disseminate your results. For example, if your project promises to discover a cure for a disease then the dissemination plan needs to address the question of making the cure available to those afflicted by the disease.
  • A “we need to know” subsection for each of your sub-projects that explains why (and how much) we need the knowledge that sub-project will produce. Drafting key sentences for these sub-projects is very very easy. The first draft is “We need to know XXX” where XXX is the knowledge that the sub-project will produce.

Once you have created these  subsections and introduced them with the key sentences, you can copy over text from your old draft and write new text so that each sub-section explains, with reference to relevant evidence, why the key sentence that introduces it is completely and compellingly true. That makes the background the perfect preparation for the description of the project: it convinces the reader that we desperately need everything that the project will deliver.

All that you need now is an introduction. The perfect introduction is very simple to describe but it takes a bit of time to explain exactly why it should be so simple. I will tell you about it next week.