Say it again Sam. And use the same words.

groundhogRepetition of key sentences and key phrases is extremely important in a grant application. The key sentences that introduce each subsection of the background and the description of the project in the case for support should be repeated in the introduction and also in the summary.  So each key sentence should appear at least three times.

Some key phrases should be repeated more than three times because they occur in more than one key sentence. For example, imagine you are writing a grant in which one of the sub-projects will characterise the relationship between motherhood and apple pie.  The phrase ‘the relationship between motherhood and apple pie’ will be in two of your key sentences.  One will explain why we need to characterise ‘the relationship between motherhood and apple pie’.  The other will introduce  the description of the sub-project that characterises the relationship between motherhood and apple pie.

Most academics accept that it is helpful to repeat key sentences. But most of them reject the idea that the repetition should use  the same words in the same order.  So I want to explain now why it is more effective to use the same words in the same order whenever you repeat a phrase or sentence.

Effectiveness is much more important here than correctness.  Few would disagree with the assertion that exact repetition is a more correct use of English than paraphrasing but it is much more important to think about how you can increase the effectiveness of a grant application by using repetition in the way that I recommend and how you will fail to increase effectiveness in the same way if you change the words you use or their order.

In thinking about the effectiveness of a grant application, we should consider who will read it and how.  Committee members and referees have different needs and derive different benefits  from repetition.

The most important readers are the committee members that make the decision.  All of them will have a vote in deciding whether or not the grant application gets funded. Few, if any,  will understand the details of the research topic. All of them will read the summary and most of them will stop there. Some will try to read the application and understand it. Usually two  members of the committee, the designated members, are tasked with reading the application and leading the committee discussion. They will try hard to understand the application, but they will find it very difficult and they won’t have much time – maybe an hour. Any help you give them will be gratefully received.  Although most of the rest of the committee will not read the application they will probably glance through it during the discussion.

There are three ways that repetition is particularly helpful to committee members:-

  • Repeating the key sentences means that all the committee members will be likely to remember them. Even those who just glance through the application once will read the key sentences three times. This means that there is a very good chance that they will remember them and understand the logic of your case for support – what outcome your project will achieve, why it is important, what things you need to know in order to achieve the outcome and how you will achieve them. If you repeat the key sentences but substantially change the wording then people will be less likely to remember them. Every change in wording is likely to be interpreted as a change in meaning, leading to potential confusion.
  • Repeating key phrases in the sentences that state what we need to know and what the sub-projects will discover makes it very clear that the project will discover exactly what we need to know. In this way the key phrases act like labels for the different parts of the project.
  • Repeating the key phrases enables committee members to learn them and to have a sense of what they mean. Humans learn the meaning of new phrases by encountering them repeated in different contexts. Committee members who read your grant application carefully will get the sense that they know what it means , even if they don’t. If you vary the wording of the key phrases it becomes harder to learn them and  less clear to the reader that you mean the same thing.

The referees are, notionally at least,  experts in the research topic. They will read the application, write an analysis of its strengths and weaknesses and give it a score, which the committee will consider, but not necessarily follow.  The referees are likely to read your application more carefully than the committee members and to have a deeper understanding of the topic. However, they will want to assess whether the detailed content of your case for support actually supports the assertions made in the key sentences. Repetition helps them do this in two stages.

  • Reading the key sentences in the summary and in the introduction allows them to create a mental list of questions to which they want to find answers in the case for support.
  • Repeating the key sentences at the head of each subsection of the case for support guides the referees to the answers. Again, the key phrases act like labels. For example, a referee that has some doubts about whether your research approach really will characterise the relationship between motherhood and apple pie will be guided straight to the place where you describe the relevant part of your research approach by the phrase the relationship between motherhood and apple pie. If you decide to change any of the words in the key phrase, not only does it become less effective as a label, it also introduces the possibility that you are seeking to do a piece of research without having told the reader why it is important to do it.

In sum, repetition of key sentences and key phrases makes a grant application more effective in four different ways, provided that you use the same words in the same order.

 

 

We had the workshop: where are the grants?

16630702_sAt Parker Derrington Ltd we often encounter rather fixed ideas about how to improve grant-writing outcomes. ” A workshop is what we need….. Can you manage 100 participants? Can you tell them how to get bigger grants? Can you do it any cheaper? What can you do in half a day?”  Obviously, to survive in business we have to allow the customer to be right, so we find ourselves giving rather a lot of grant-writing workshops.

Of course we think our workshops are the best in the business and we get excellent feedback.  However, a workshop can only do so much. Even academics who have good ideas, a good track record of publications and who can design a fundable research project need more than a workshop can provide. Let me explain. There are three problems that tend to prevent such academics from writing good research-grant applications:-

  • They don’t appreciate the unwritten constraints on the case for support.
  • They don’t have an efficient way of writing a grant-application.
  • They don’t usually get high quality help and encouragement from other academics.

Let’s take these one by one.

The unwritten constraints on the case for support

There are two constraints that push people in opposite directions.

  • It must be speed-readable. Research councils don’t tell you that most of the committee members who take the decision on your research-grant application probably  haven’t read the case for support properly. Worse,  even if committee members did read the case for support properly, most of them wouldn’t understand it.  Obviously your case for support must enable speed-readers to understand and remember what you expect to discover, why it is important, how you will do it, and what you will do with the results.
  • It must be easy to find the detail. Your case for support will also be read by expert referees who will want to assess the detail of what you will do and why it is worth doing. However, few people appreciate that referees will do a much better job and will feel happier about doing it if you make the job easy. So your case for support should  guide referees to the specific content that supports each element of the case. And your summary should make it absolutely clear what arguments the case is making, so that referees know before they begin reading the case for support, what arguments they want to test.

In our workshops we explain how these constraints arise and how to design a case for support that meets them.

An efficient grant-writing process

It should be possible to write a research-grant-application in a week. Most people take months. Some take years.

We find two common factors that make writing inefficient. Probably the commonest is starting to write the grant proposal before designing the research project. Remember, the grant application is a marketing document that is trying to secure investment in the project. It can take a very long time to write it if  you start before you define the project because you don’t know what you are marketing.  Moreover, applications that are not based on a defined project usually fail to convince the reader that they are marketing anything at all: we call them zombie grants. A second factor that makes writing inefficient is not having a guide that tells you what to write in each part of the case for support.

We teach a 2-stage approach to writing in which the first stage is to write a summary that consists of 10 key sentences. That summary is enough to check whether the writer has a viable project. In the second stage, the summary is a guide that tells you what to write in each part of the case for support. Each of the key sentences  forms the first sentence of a major sub-section of the case for support and defines what the rest of the sub-section must convince the reader to be true, either with evidence or with detail about proposed research activities.

How to help a grant-writer.

It’s harder to help a grant-writer than you might think. It should be easy to give clear feedback that will tell them exactly what they have done wrong. Actually, it’s quite hard to do that unless your heart is made of stone, because accurate feedback is crushingly demotivating. Telling a colleague what is wrong with a grant-application that has taken them six months to write can completely destroy their motivation.

To write a grant quickly and well, a writer needs encouragement and feedback, delivered as directly and as quickly as possible.  Our 2-stage approach to writing makes it easier to give constructive feedback, partly because it breaks the writing task down into smaller chunks but also because it makes it easier to define what is expected at each stage, so it combines feedforward with feedback. We offer workshops for coaches to help academics coach their colleagues it but we also offer coaching directly to writers, either as a stand-alone service or as a follow-up to a workshop.  If you are interested, get in touch.

First you tell them; then you convince them.

Quotative Like; xkcd.com

Some  common writing styles are very bad for grant applications and this post aims to help you to avoid one of the worst.  It is a style of writing that we refer to in the Research Funding Toolkit as “Argue – conclude”.

Argue-conclude writing sets out the argument for a statement before it makes the statement.  Done well, argue-conclude writing can be very convincing for a dedicated reader,  who will follow every twist and turn of  your argument. By the time they get to read a statement that ordinarily they might be inclined to reject, they already know the arguments that support it. Unfortunately, most of the readers who will decide whether your grant application gets funded are less dedicated. They will give up reading before they get to the crucial statement.

To communicate with these readers, you begin each paragraph with its main message. Then use the rest of the paragraph to convince them that the message is true. In the Research Funding Toolkit we refer to this style as “assert-justify“. An easy way to describe about assert-justify style is “Tell them; then convince them”.

As I was writing this I thought of nine reasons you should adopt “Assert-justify” style in research grant applications.  The first four are concerned with meeting the needs of the reader – one of the guiding principles for writing with style. The remaining five are concerned with making the task of writing easier. Naturally I shall assert each reason and then justify it.

  1. Assert-justify style communicates more effectively with speed-readers, tired readers, and lazy readers.
    These readers will skim through your document. The neurology of eye-movements dictates that, provided you put blank lines between the paragraphs, their eyes will skip from paragraph to paragraph. They will read the first line of each paragraph. Thus they will read the assertions and get the headline messages. If they are inclined to disagree with the headline messages, they will dig down into the arguments that justify them.
  2. Assert-justify style makes it easier for diligent readers, such as referees, to examine your arguments in detail.
    Each paragraph starts by stating what the paragraph is about. This makes it very easy for the reader to find the arguments they want to examine. They never face the problem of wading through an argument wondering where it is leading.
  3. Assert-justify style makes it easier for the committee-member who has to present your grant to the rest of the committee.
    They can see at a glance what points you are trying to make. This makes it very easy for them to select the points that are most important and relevant for the committee, even if they don’t entirely understand them.
  4. Assert-justify style is more likely to engage readers who are bored.
    The conclusion is always the most interesting part of the argument. By putting the conclusion first you are more likely to entice them to read.
  5. Assert-justify style makes it easier to write an accurate summary.
    The assertions from each paragraph comprise a draft summary. If you want a shorter summary you may be able to leave some of them out.
  6. Assert-justify style makes it easier to write a good introduction.
    The assertions from each paragraph comprise the core of the introduction. You may need to add some linking text and some signposts.
  7. Assert-justify style makes it easier to write short sentences.
    You can write in simple, clear statements. You don’t need to frame them and qualify them.
  8. Assert-justify style makes it easier to write short paragraphs.
    In argue-conclude writing you have to spend a lot of words preparing the ground for the argument. If you start by asserting the point you want to make, you leap straight into the argument without spending any words.
  9. Assert-justify style makes it easier to write.
    I used to spend a lot of time staring at my screen wondering how to get started on each section. In assert-justify writing you can write the ten key sentences that start each sub-section of a grant proposal in an hour.

There are probably more and better reasons to write in assert-justify style.  When I started writing this post, I only had three!  If you have any doubts about whether assert-justify style is correct, it may help you to know that some time after writing this post I discovered a tenth reason: courses on English for academic purposes advise that every paragraph should contain a sentence that states the message of the paragraph, the topic sentence, and that it should usually be the first sentence.

Let me finish with an example of what I think you should avoid. This abstract of a funded grant application is short and clearly written but it is in argue-conclude style; consequently the piece of information that the reader most wants to know – what will the research project do – is buried away in the second half of a sentence in the last paragraph. A speed-reader would not see it.

Committees and Referees

Committees Like a Simple Story: thanks to Science and Ink http://www.lab-initio.com

Committees prefer a clear story: http://labinitio.com

The Journal Nature reported yesterday that scientists have complained that there is a mismatch between expert referees’ evaluation scores of research grant applications and funding decisions.  Different interviewees claimed that this mismatch either does or does not indicate either a flaw in the system or mistakes by referees or by committees.

There may be flaws in the system and mistakes probably happen, but there is a more obvious reason that referees’ scores should not be expected to predict funding decisions. Referees and committees do different jobs which impose different constraints on the way a grant application is written. Very few proposals are written in a way that satisfies both sets of constraints, and so, for the majority of proposals, there is no reason to expect a close match between the referees’ score and the committee’s score. Before I explain the constraints and how to meet them, I’ll clarify the story and explain its relevance.

The story was based on 302 grant applications to the Medical Research Council. It states that some applications that received high scores from the referees were triaged (rejected without being discussed by the committee). Of the proposals discussed by the committee, the story states that the group of applications that were successful and the group that were rejected had ‘a nearly identical spread of scores’. It’s worth noting that the story focuses on a statistic of the scores that is not particularly informative (spread) and does not mention any other statistics. It is relatively common that the referees include both friends and foes of the applicant, which can cause the spread of scores on a single application to range from the lowest to the highest possible. Consequently, nothing that the story says about this rather small data sample indicates a general failure of referees’ scores to predict committee decisions.

However, whatever we may try to conclude from this small dataset, most funding agencies (the EPSRC is an exception in the UK) ask referees and committees to do very different jobs. These jobs depend on different aspects of the way the proposal is written.

Referees work alone and each one works on a single application. The referees are expected to be experts in the same research field as the applicant and their evaluations are typically seen as coming from within that field. Their main task is to test the detailed rationale of the proposal. Are the research questions important? Is the research approach feasible? Does the research team have the ability to carry out the project? What is their standing in the field? Has their previous work made a significant contribution? Is the approach novel? Are other teams likely to get the answers first?

To get a good score from a referee, a grant application must contain relevant detail. Evidence that the questions are important and relevant must be cited. Any evidence to the contrary must be dealt with effectively. The research approach must be described clearly and in sufficient detail to convince a knowledgeable sceptic that the project is feasible, can be carried out with the resources requested, and will lead to the promised outcomes.

The committee works as a collective and takes a view across all the applications before them, typically about 100 for a single meeting. They must also take a view across all the different research fields that the committee supports. They need it to be clear that the project will deliver an  outcome that will have importance beyond the immediate research area and that the applicant has identified an approach that is likely to be productive and that the research team has the skills to deliver it. They need to know what the research aims are and how they relate to the overall outcome. They need it to be clear that the research objectives will satisfy the research aims and deliver the overall outcome and that the results will have appropriate impact

More importantly, the committee also works very quickly. They have to reach an agreed view about grant applications which most or all of them may not understand completely. For the committee to score an application highly they need it to be possible to understand it on the basis of a single hasty reading – or even a quick skim. The case for support should have a very clear structure that states clearly what will be the research outcome, why it is important, what are the research aims, what are the objectives and what will be done with the results.

Of course the best possible case for support has a clear structure that enables the committee to understand it and appreciate its strong points. It also uses the structure to guide the referees to the relevant detail. In my experience cases of support written in this way get very high scores both from referees and from committees. Unfortunately they are very rare but this blog explains in several different ways how to write them.

 

Build the Project, Then Fit the Question

Was your question clearly linked to your project?

Is your question important to the funder?

The first thing you must do in a grant application is convince the reader that you are going to address a question that is important to the funder. Your grant will definitely not get funded unless you convince the reader that your research question is important to the funder. Even so,  you should take a project first approach. Generate your project and then fit the question to it. Do not try to pick an important question and then design a project to solve it. The project first approach is quicker – often by several months – and it reduces the risk of writing a zombie grant.

The project first approach is easier if you take a modular approach to project design and start by generating a catalogue of sub-projects.  As you generate each sub-project, you should ask  yourself if the outcome will contribute to answering an important question. If it will, keep the sub-project and begin preparing yourself to make that case. Otherwise, discard that sub-project and try  to generate another one with an outcome that will contribute to answering an important question.

Once you have a few sub-projects – ideally at least five or six – it is easy to generate projects. The ideal project has three, or just possibly four, sub-projects.  When you combine sub-projects to generate a project you need to start looking hard for a good research question. You need a question that covers all  of the sub-project outcomes comfortably. It is better to take a question that is too big to answer, and answer it partially, rather than risk picking a question that is too small to be exciting and answer it completely.

An important part of your development as a researcher is to develop the ability to design projects that produce results that help to answer important questions. I absorbed this from the culture of the lab in which I did my PhD and this is part of the approach we recommend in the book. However, it is also possible to search on the web to see if a given funder will fund the kinds of research outcomes you are likely to produce.  Obviously every funder’s website will have a statement of their remit, but this can be hard to interpret because it will be couched in terms of questions rather than outcomes. A better way to get a sense of the outcomes that excite a given funder is to scan their press releases. Best of all, some funders have a database that includes the abstracts of all their funded projects.

The Gateway to Funded Research is a searchable database that covers  all the UK research councils. The Projects and Results page on the European Research Council website is also searchable and allows you to see research outcomes.

A simple answer to a simple question

lab-initio.com astrophysicsmadesimple

Try to write a simple answer in one sentence

Last week I was a rather noisy fly on the wall in a workshop run by Sara Shinton to help  post-docs prepare for fellowship interviews. Sara pointed out that many institutions, including Glasgow University, which is where the workshop took place, have developed extensive support programmes for would-be fellows and will arrange a mock interview if you give them sufficient notice.

We also worked out a simple 10 minute exercise you can do to set yourself up to perform well in the interview. The key, if, like me, you have a tendency to be nervous, is to prepare and to learn a really good answer to a question that almost always crops up at the start of the interview. The question is very simple: Could you tell the committee a little bit about your project. Preparing a good answer to this question is a bit more difficult, but the exercise helps a great deal.

It is best to work with a colleague, someone who is preparing for an interview or writing a project grant themselves is ideal. It’s best if you don’t know too much about their research. The exercise is very simple. Spend exactly 4 minutes asking your friend about their project – you need to find out

  • What will the project try to achieve?
  • Why would that achievement be important?
  • How will the project try to achieve it?
  • Why is your colleague a good person to lead the project?

At the end of 4 minutes switch roles so that your colleague questions you about your project. Then you both write one sentence about each project. Spend 1 minute on the sentence and try to  give a simple overall statement of what the project will achieve, ideally you will relate that achievement to a big important problem and will also include something distinctive about how the project will achieve it in a way that will make it clear that the PI is a suitable person to do the project.

The sentence you need is something like key sentence 1.  You probably want the language to be a bit less formal than you would write in an application because you want to speak it. An ideal sentence would have a structure like this one:- “I’m going to identify potential treatments for stroke by testing compounds that we have found to inhibit brain metabolism in tissue culture”. It does 3 things.

  1. It says that you are working towards something pretty important, a treatment for stroke. It makes it clear that you don’t expect to get there by saying ‘potential‘. Everyone knows that the road from ‘potential treatment’ to ‘treatment’ can be a long one.
  2. It uses the phrase ‘we have found’ which says that you are working with compounds that you have worked with before. This establishes that you have credentials to do the work.
  3. It says that you are going to be testing metabolic inhibitors in tissue culture, which gives a sense of the kind of research you will be doing and the kind of drug that might be developed as a result.

The ideal sentence will have about 30 words. The example I have given has 23. We discovered that some of the workshop participants can write very long and very complex sentences in a minute. We also found that it’s often easier to write a good and convincing sentence about someone else’s project than about your own. Often you can make a really strong sentence by combining phrases from your sentence with phrases from a sentence produced by someone who knows much less than you do about the technicalities.

Dealing with rejection 2: Salvage.

Collection_of_scrap_aluminium_in_Welshpool_by_the_Womens_Voluntary_Service_(8559465818)

Salvage is the only way forward after rejection.

The most difficult aspect of grant rejection, apart from not having a grant of course, is that your motivation to write new applications evaporates. That’s why it’s even more important than working out what was wrong with your rejected application to salvage what you can from the rejected application and start putting together a new one.

It is of course important to take the opportunity to learn what you can about what was wrong with the rejected application and I wrote about how to do that last week. However, whether or not you learn anything from it, you must come to terms with the fact that your rejected application is dead. Yes, dead. I’m sorry, I did say dead and I do mean dead. Mourn its passing but do not imagine that editing will reanimate its corpse. Use your editing pencil instead to mark useful parts to salvage and recycle.

 Salvage the Sub-Projects One at a Time

The most important part of the case for support is the description of the project. This should be at least half the case for support and it should be subdivided into three or four sub-projects. If it isn’t subdivided into projects then you can divide it up as you salvage it.

A sub-project is a discrete set of research activities designed to produce a definable outcome. You must divide your project into sub-projects in order to make it accessible for the grants committee. Remember, they are not experts in your field so they are unlikely to appreciate your project unless you can break it into bite-sized chunks.

If you cannot easily divide your research into sub-projects you can use the timeline of your project to divide it into phases. You will need to be able to say in a single sentence what you expect to be the outcome of each phase. If it’s impossible to do this you need to think again. You won’t get funding for a research project unless you can produce a succinct statement about what you expect to have happened by the time you are about a third of the way through it.   Of course you can use natural break-points in your project to divide it into phases that are not exactly equal, but if you want to get funded you must be able to give confidence that you will are able to plan the progress of your research.

Record Key Information About Each Sub-Project

To make it easy to re-use the sub-projects you need to record extra information with them. I suggested in a previous post that you should compile a catalogue of sub-projects with this information.

  • The most important thing to record is what the outcome would be if you were to carry out the sub-project. You should use this to draft a key sentence that describes the sub-project and states the outcome, unless you have already written such a sentence.
  • A list of the research activities that comprise the sub-project.
  • A list of the skills needed to carry out the sub-project.
  • A list of the resources needed to carry out the activities in the sub-project. This consists of 2 sub-lists:-
    • resources already available to you, and
    • resources you need the grant to pay for.

If you can salvage all of your sub-projects you should have about half what you need for another grant application. However I strongly recommend that you try to create a portfolio of sub-projects so that you can re-use them in different combinations.

 Useful Sentences and Phrases

The descriptions of the sub-projects are the only large chunks of text that I would advise you to salvage from the proposal. The other sub-sections will probably not be relevant if you restructure your project, which I strongly advise you to do. However, there are some snippets of text that could be worth salvaging from the rejected proposal.

  • Key sentences, other than those in the sections of text you have salvaged, are probably not worth salvaging. The ones that express the need to do the sub-projects you have salvaged will be useful but they are very easy to write. Any others should be viewed with suspicion because they have failed.
  • Sentences that refer to your research and project management skills and those of your team are quite difficult to write and should be salvaged if they read well. If your project is for BBSRC, NERC, MRC or EPSRC there will be whole sections of text describing the accomplishments of the different members of the project team that should be salvageable.
  • Descriptions of how existing resources will be used should also be salvaged, even when they are part of  sub-projects that you may not re-use.

Finally, a word of caution, be suspicious of all the text you are salvaging. Something in your grant application sank it and, unless your feedback made it very clear what it was, you should be cautious about the possibility of salvaging something that could sink the next one.

How to Deal with Rejection 1: What could I have done better?

Are you driven by the question or by the project?

Did you design a project that will answer your question? Thanks to Nick Kim, http://lab-initio.com

Getting a grant application rejected has three things in common with other rejections.

  1. Rejection is slightly less painful if you have other applications still being considered.
  2. Regardless of how painful it is, rejection is an important learning opportunity.
  3. Regardless of the pain and the learning, you need to make sensible decisions about whether, and how, to try again.

I know – believe me I really know – that getting grant applications rejected is painful. In my experience the combination of pain and humiliation can make it impossible to think analytically about the application for weeks or months. However, unless your desire to do research is completely extinguished, sooner or later you have to come back. When you do, it’s really important to learn as much as you can from the rejection and use it to plan the best way ahead.

If you are still consumed with the pain of rejection, you might want to bookmark this page and come back when you feel able to be analytical. However there are three practical  reasons you might want to work through the pain and deal analytically with the rejection now.

  • Dealing constructively with a rejection helps to draw a line under it and resolve the pain.
  • The sooner you start, the better will be the outcome for two reasons.
    • You will do a better job on the analysis if you do it while your memory is fresh.
    • Any plans you develop as a result of the analysis are more likely to be successful if you can implement them before they go out of date.
  • The more times you deal with rejection, the easier and the quicker it gets. I can remember once  (admittedly it was about my 20th rejection) I was able to deal with it in less than a day, rewrite the grant in under 3 weeks and get it fully funded.

If you have got this far I am assuming you want to be analytical. There are four separate steps.

  1. Work out why your grant application was rejected.
  2. Work out how you could have made it stronger.
  3. Salvage useful components.
  4. Get back on the horse.

I’ll deal with the first two in this post and the other two next week.

Work out why it was rejected

Usually the reviews you get back will  say lots of good things and it can be hard to understand why an application with so much going for it could have been rejected. Rejections usually boil down to:-

  • the committee thought the research question wasn’t important enough or
  • the committee couldn’t see how the project would answer the question.

There are three things you should consider here.

  1. It only takes one hole to sink an otherwise perfect boat. It might make it easier to find the hole if you filter out the negative comments and look at them separately.
  2. In most cases the committee discussion is more important than the referees reports but the description of their discussion is likely to be both short and vague. So the hole in the boat my not be very well defined.
  3. Funding rates are falling and sometimes perfect grants, grants that propose well-designed projects that will answer important questions, don’t get funded because there just isn’t enough money.

Don’t be too eager to assume that your grant was perfect. If the funding rate was 30% or better then it’s very unlikely. In fact, most grants that get funded could be improved significantly.

Work out how you could have made it stronger

Regardless of why your grant application was rejected, you should look to see whether it could have been improved. This is particularly important if the reason for rejection is not apparent from the comments: a badly written grant simply fails to convince the reader – the reader may not know why.

You should look separately at four elements:- the description of the project, the background, the introduction, and the summary. As a rough guide you should be clear on the following questions:-

Description of the project

  • Is it clear what you will do?
  • Have you explained the steps that will take you from starting research to having a set of findings that are written up and disseminated?
  • Is the project divided into three or four (i.e. more than two and fewer than five) phases?
  • Is it clear what will be discovered by each phase of the project?

Background to the Project

  • Have you given a good reason why you should do your project? Have you linked it to an important question?
  • Is your link direct (your project will completely anser the question) or indirect (your project will take some important steps towards an answer to the question)?
  • Has the funder stated explicitly or implicitly that this question is important? This is probably worth a whole post. I’ll get around to it.
  • Have you linked the question clearly to each phase of your project by showing that we need to know what each phase of the project will discover?
  • Do other authors agree with your specific ‘we need to know’ statements or are they individual to you?
  • Have you cited publications that demonstrate that your team are competent to produce new discoveries in this area?
  • Have you overstated your contribution to the field?
  • Could other people think this area is a backwater rather than a niche?

 Introduction

  • Does the introduction make all the statements listed in the ‘key sentences‘?
  • Does the introduction state every thing that  ‘we need to know’.
  • Does the introduction state  every thing that the project will discover?
  • Are these statements in the introduction clearly the same as the statements that begin the corresponding sub-sections of the background and the description of the project? They should be recognisably the same statements although they don’t have to be exact copies.

Summary (I mean the summary of the Grant Application)

The summaries of most successful grant applications are appallingly bad. You can see this if you look for the details of successful proposals from the UK research councils or from the European Research Council. However, a good summary helps the funding agency to choose more appropriate referees and it helps the referees and the committee members to understand the research. You should check the following:-

  • Does the summary make all the statements listed in the ‘key sentences‘?
  • Does the summary state every thing that  ‘we need to know’.
  • Does the summary state  every thing that the project will discover?
  • Are these statements in the summary clearly the same as those in the introduction? They should be recognisably stating the same thing although they don’t have to be exact copies.

What Next?

It’s very likely that these two exercises will give you a clearer sense of how you could have given your application a better chance. Next week I will discuss what raw material you can take from a rejected grant application and how to turn it into the basis of future success.

How to Write a Research Grant Application in 2 Weeks

MonkeysAndTypewriters

The key to writing anything quickly is knowing what you have to write.

One of the things that puts people off writing research grants is that writing a grant can be a never-ending nightmare. However, it doesn’t have to be that way.

Last month I helped a client, let’s call him Dr B, to write a research council grant application in 2 weeks. It was interesting for me because it was a model of how to write with the minimum of effort – by either of us. Dr B tells me that he spent only about half of the working day on the application during the 2 week period when he wrote it.  I spent between 2 and 3 hours helping him.

The clock started on September 3rd when Dr B sent me a draft set of 10 key sentences and a  question about whether to follow my advice, to state the  aims and objectives in the introduction, or whether to follow the funder’s guidelines for a case for support which suggests that aims and objectives  form part of the description of the project.

I edited the sentences and sent an email suggesting that Dr B could follow both my advice and the funder’s guidelines. I think that it is essential to state the aims and objectives – and not much else – in the introduction to the case for support and also in the summary, so that the reader knows what to expect. And if the funder recommends that you state the aims and objectives at the start of the description of the research project then its fine to do that although I would suggest that you only format them as Aims and Objectives once. In other places you can use phrases like ‘We need to know’ for the aims and ‘In order to discover X we will do Y’ for the objectives.

I think that editing and drafting my email took less than 20 minutes. It can’t have taken much more because the email logs show my response 31 minutes after Dr B’s query. A few days later Dr B promised to send me a draft on the 15th and we made an appointment to speak about it on the 16th. The draft arrived on time and I spent about an hour and a half reading it and annotating it. Then Dr B phoned and we spent an hour discussing my suggested changes which took him less than a day to implement. We also kicked around some ideas that will be the subject of his next grant proposal.

The key to writing anything quickly is knowing what you have to write. That is why it is so useful to start by writing the key sentences. They define the grant application. Each of them begins a major section of the proposal. These sections justify the bald assertions in the key sentences and make the reader believe that they are true. The key sentences that define the background must be justified with evidence; those that define the project must be justified with descriptive detail.

Writing the key sentences should only take you a couple of hours. If you can’t write the key sentences in a couple of hours then you need to do some more thinking about your project. That can take days, weeks, or months, but until you have done it you are not ready to start writing a grant application.

Dr B is ready. I had an email from him last week. He has been thinking about the ideas we kicked around when we were discussing the edits to his last application. He wants to send me a set of key sentences next week!

 

A Good Book for Department Heads and Their Colleagues

DarthEvery academic head of department should read the book Getting to Yes. Although it is  a book about how to negotiate, originating in the Harvard Negotiation Project, it applies to a huge range of situations that are not normally thought of as negotiations. It is like a bible for the day to day business of running a department.

The book is also invaluable if you are an ordinary academic and you have to negotiate with your head of department  because it is about trying to produce an outcome that is good for both parties. This means that you can initiate the approach from either side of a negotiation. It also means that the approach works better if both parties use it.

The essence of the book is that there are four steps you should take if you want a negotiation to have a good chance of success. They are:-

  1. Separate the person you are negotiating with from the problem that you are negotiating about.
  2. Deal with the problem in terms of the interests of the relevant parties, and not in terms of the positions they wish to adopt.
  3. Invent options for mutual gain.
  4. Use objective criteria to evaluate possible solutions.

My experience, both as a head of department and as a manager of heads of department, is that these four steps are like four commandments for running a department in a way that supports academic endeavour. Let’s take them in order.

Separate the person from the problem

The first commandment is to separate the person you are negotiating with from the problem you are negotiating about. This makes it possible to turn negotiation from a confrontation into a collaboration in which people work together to solve a shared problem.

In management you get a similar benefit from separating the person from the problem: it reduces confrontation and makes it easier to solve problems. But you get several other benefits. For example:-

There is also a more general benefit of the first commandment. It makes it easier to manage people, especially people that you might be tempted to think of as “difficult’ and in situations that give rise to difficulty and disagreement.

Focus on interests, not positions

The second commandment is to represent the negotiation problem in terms of interests (what each party would like get from a solution), rather than positions (the  outcomes preferred by the negotiating parties). This makes it possible to look widely for ways of satisfying the interests of both parties and potentially to find an outcome that satisfies more interests for both parties than either of their starting positions. Part of the reason for this is that dealing with interests makes it possible to consider interests that are not strictly part of the immediate problem, such as the desire to maintain a long-term relationship, as we shall see when we get to the third commandment.

In management, the second commandment makes it much easier to change the way things are done in order to produce better outcomes. When people focus on positions, on what they do, it can be quite hard to persuade them to do anything other than what they have always done. Focusing on interests makes it possible to have discussions about the benefits of change without getting blocked by concerns about who does what.

Invent Options for Mutual Gain

The third commandment is to invent options for mutual gain. You add extra factors to the negotiation in order to make the outcome better for both parties. This is possible when something that is of great value to one party can easily be provided by the other.  A simple example is when a car dealer takes your old car  in ‘part exchange’ when they sell you a new one. Usually this creates mutual gain because the dealer will make an extra profit from your old car and because you will be saved the trouble of selling it yourself. This is why dealers pay unrealistically high prices for ‘part-exchange’ cars.

Inventing options for mutual gain is hugely important in management, both in dealing with individuals and in creating strategies for departments, faculties and institutions. At an individual level, you invent options in order to persuade people to  take on  tasks that they might otherwise be reluctant to do, although you also do your best to select  tasks that best suit each individual. At a broader level, inventing options is part of how you create strategies that reconcile apparently conflicting interests. For example, increasing numbers of UK institutions are creating graduate teaching assistantships (GTA), which pay PhD students to teach and, which, if they are well designed and implemented,  can improve both undergraduate teaching and research while saving money. I should emphasise that, for GTA schemes as for most strategic initiatives, good outcomes depend on good design and implementation: it is very easy to run a GTA scheme that costs money and damages both research and teaching.

Use objective criteria

The fourth commandment is: use objective criteria. In negotiating, when you make your criteria objective it becomes possible to discuss what an acceptable outcome might be, and to analyse outcomes and their implications.

In management, using objective criteria makes it possible to be rational about issues that otherwise can become emotional battlegrounds. Management decisions that can have huge emotive impact, ranging from failed applications for promotion to refusals to replace retired colleagues can be subjected to analysis and used to formulate plans for future success.

Work out your BATNA before you get stuck in and if you get stuck

There is a fifth step, which is more important in negotiations than in management situations. Before deciding whether to negotiate you should work out your best alternative to a negotiated agreement, or BATNA. You should review your BATNA if the negotiation gets stuck or if the other party refuses to act reasonably.  If it becomes clear at any point that your BATNA is better than the best you can get by negotiating, then it’s better not to negotiate.

How useful is the book?

I first read ‘Getting to Yes’ years ago, when I was a new head of department and had an acrimonious disagreement with my dean, which my coach suggested I might resolve  by negotiation. I read the book in an afternoon and it had a huge impact on my ability to operate as a head of department. I used to find that my successes in management could usually be attributed to following one or more of its commandments and my failures could be explained by not following them. I also found the book extremely useful when managing my bosses and I wished I had read it at the beginning of my career. When I was a dean I bought copies of the book for my reports to help them understand how to manage me.

On the other hand, the book’s influence on my ability to negotiate with the dean was less clear. When I had read the book, I asked him for a meeting. He refused to meet me; instead he resolved our disagreement by giving me everything I had asked for. I guess he must have decided it was his BATNA!