Guardian Live Chat

Posted on May 1, 2013 by Andrew

I recently had the pleasure of taking part in a live chat, on the Guardian Higher Education website, about how to write successful grant applications. It was very interesting for me because the rapid flow of questions made it impossible for me to stop writing, whereas my normal situation is that I find it impossible to start.

I suppose it should be no surprise that a real question from a real person is a very potent stimulus. And the complete absence of questions and people isn’t. Maybe there is a research project in this…..

It’s worth reading the chat, not just for the wise words of the expert panelists but also in order to see what other people who are applying for research funding are thinking and worrying about. The chat is archived here and Claire Shaw has distilled the advice of the panel into ten tips here.

Reflecting on the chat, it occurred to me that many academics wander unwittingly into the trap of the never-ending grant application. I think it happens if you start to write a grant application before you are ready. It’s a version of catch 22. You can’t write a grant application if you aren’t ready. And you can’t get ready to write a grant application if you are trying to write it  instead of trying to get ready.

So my next post will be about what you need to do before you commit to writing a grant application. It’s about how you will know that you can finish the job in a few weeks and avoid falling into the trap of the never-ending grant-application.

I think I’m ready to write about this. I’ll post by the beginning of next week.

Promise……

Posted in When you should NOT write a grant, Writing the Case for Support | Tagged , | Leave a comment

Writing by Numbers: the Case for Support in 7 Easy Steps.

Posted on January 15, 2013 by Andrew

This post is a step by step guide to writing the case for support in a research grant application. It describes the structure of the generic case for support and tells you what steps you should take to write it efficiently. At each stage it points you to a previous post that describes in more detail what you should do.

Over the last few weeks I have been helping a couple of colleagues write grant applications. This post is what I wish I had told them before they started.

The generic case for support consists of three sections.

  1. The first section gives a headline preview of sections 2 and 3.
  2. The second section explains why we need to know the things that the project will discover.
  3. The third section is the most important. It describes the project, the resources it will use, what it will discover, and how those discoveries will be disseminated.

In essence, the third section explains to the reader what will happen if the grant is awarded. The second section explains to the reader that we need those things to happen. And the first section tells the reader what will be explained in the second and third sections. The easiest way to write the sections is in reverse order. Here’s how.

  1. Start by describing a work-package or sub-project, a piece of the research that you will do. This post explains how to write and test your description. The work package should be about 25% of the total project. If you are hoping to get a 3 year project grant the work-package should be about 6-8 months work.
  2. At this point you should start talking to those colleagues whose support you will need, the colleagues who will help you to cost the project, and those whose formal permission you will need in order to submit it through your institution. Find out about deadlines, whether there is an internal peer-review process, whether your line manager is happy for you to commit yourself and whatever institutional resources you may need to the project.
  3. Follow the instructions in this post to build up another three or so work packages and link them together into a coherent description of your project. The description of the project should be at least 50% of the allowed text. Most people make it too short – usually because they have made the mistake of writing it last.
  4. The description of the project allows you to work out what resources you need to apply for, so as soon as you have written a draft of it you can get the project costed in the way recommended by your institution. You can also check that your institution is happy to commit the internal resources that your proposed project will need.
  5. Write the second section of the case for support, the background,  by following the instructions in this post. The background should be about 30% of the total text.
  6. Follow the instructions in this post to make sure that what you have written is in ‘assert justify’ style.
  7. This post explains how to write the first section. It should be less than 20% of the case for support.
Posted in proposal structure, Writing the Case for Support | Tagged , , , , , , , | Leave a comment

Writing the introduction:- Getting your Foot in the Door

Posted on November 22, 2012 by Andrew

This post is about the easy way to write the first part of the generic case for support for a research grant application. As I have explained in a previous post the first section of the case for support should be written last. I also explain how to write the other two main sections of the case for support,  the description of the research project, which comes last but should be written first, and the ‘we have a problem’ section, which comes second and should be written second.

In the book, we call the first section the ‘Foot in the Door’.  It gives the reader an immediate preview of the whole research proposal, as when a travelling salesman sticks his foot in the door and tells you what he is selling and why you should want to buy it. The ‘foot in the door’ section must grab the reader’s attention and then hold it for long enough to deliver its message.

It is important that the message delivered in the ‘foot in the door’ section is the same and uses the same words as the subsequent sections of the case for support. For this reason, it is almost impossible to write the ‘foot in the door’ section until you have written the other two sections, so if you haven’t written them yet, go and do it now.

Once you have written the main sections, the ‘we have a problem’ and the description of the research project, writing the ‘foot in the door’ takes three steps.

  • First, you ensure that the main sections are written in  ‘assert-justify’ style: see my last post for how to do this.
  • Then you copy and paste the dozen or so ‘message sentences’ from the main sections into the new section at the beginning, the ‘foot in the door’.
  • This gives you a first draft of the the ‘foot in the door’, which you can edit so that it reads well. In editing, it is best if you can avoid changing the sentence order.
Posted in proposal structure, Writing the Case for Support | Tagged , | Leave a comment

Assert-justify Style:- Why and How?

Posted on November 22, 2012 by Andrew

Grant applications should be written in what we call assert-justify style. The first sentence in each paragraph carries the message of the paragraph. The sentence makes an assertion or statement. The remainder of the paragraph justifies or explains the statement that was made in the first sentence.

There are two obvious reasons to use assert-justify style for grant-applications.

  • Speed-readers, who typically only read the first line of each paragraph, will get the message because the message will always be in the first line of the paragraph.
  • Assert-justify style sustains the interest of the reader because it tells them what is important immediately. Then, if they need to be convinced they can read what could be a relatively lengthy justification for the statement.

The only difficulty about assert-justify style is that many writers, particularly academics, find it difficult to write a statement until they have written the justification. For this reason it is necessary to check what you have written and, if necessary, convert it into assert-justify style as follows.

  • Read each paragraph carefully.
  • Find the sentence that carries the message.
  • Move the message sentence to the beginning of the paragraph.
  • Then edit the remaining sentences so that the paragraph still makes sense.

In my next post a less obvious reason for using assert-justify style will become clear. It makes it possible for you to generate a first draft of the most difficult and important part of the case for support with no effort at all.

Posted in Language and Style, speed-reading | Tagged , , | 5 Comments

Lacuna, hope and other words to avoid

Posted on October 22, 2012 by Jacqueline

Here are five common writing mistakes gleaned from a wide variety of real life grant applications:

1. Fancy synonyms such as ‘lacuna’, ‘felicitous’ and ‘finitude’ make your proposals both harder to read and harder to understand.
2. The language of uncertainty (‘hope’, ‘would’, or ‘intend’) implies that you cannot deliver your proposed project and  leave assessors less convinced by your plans. Use ‘will’ instead.
3. Equally, over-use of ‘generally’, approximately’ or ‘tentatively’ makes your project look poorly designed rather than honestly described.
4. Sweeping statements such as ‘the general consensus’ or ‘it is agreed’ are likely to annoy those assessors who do not form part of the consensus and who do not agree with your point.
5. References to ‘the academy’ or ‘the faculty’ may lead assessors to query the importance and relevance of your research both within and beyond these vaguely-defined groups.
This post is the first in a series and thanks to my colleague Sarah Slowe for her contributions to this one.  Further suggestions welcome.

Posted in Language and Style, Uncategorized | Tagged | Leave a comment

We have a problem: writing the second part of the case for support.

Posted on September 16, 2012 by Andrew

This post is about writing the section of the case for support that convinces the reader that the research project you propose to do is really important and deserves to be supported with a grant. In the book, we call this the ‘We have a problem’ section because its task is to define and to establish the importance of the problem that will be solved by your proposed research project.  It is the second most important part of the case for support and it should be no more than 30% of the total length of the case for support.

Almost every funding agency gives the ‘We have a Problem’ section a different name. Some specify more than one section that should contain components of this section. Here are the  section-numbers and names specified by several of the UK research councils:-

  • 1 Importance (MRC)
  • 2 Research questions (ESRC)
  • 1 Research Questions / 2 Research Context (AHRC)
  • 2.1 Topic and context / 2.2 Past and current work on Topic (BBSRC)
  • 2 Background / 3 Academic Impact / 3 Research Hypotheses and Objectives (EPSRC)
  • 2.1 Rationale / 2.2 Objectives (NERC)

The most important point to remember is this. The function of the ‘we have a problem’ section is to prime the reader so that when they read the description of the research project they will think that it needs to be done because we need to know what it will discover. Thus, although this section will be read before the description of the research project, its content and structure  are completely dictated by the research project.

In my last post I  recommended that, while writing the description of the research project, you should compile a list of the discoveries you will make in the research project and a list of the research competences that you and your team will need in order to carry out the research project. If you haven’t already compiled these two lists you should compile them now because you will need to use them in order to write the ‘we have a problem’ section.

The ‘we have a problem’ section will typically consist of five subsections. Four of them are ‘we need to know’ subsections. Their task is to convince the reader that we need to make each of the discoveries that will be made by the sub-projects in your research project. Typically there will be four discoveries in the list you compiled while writing the description of the project. For each discovery you need to write a ‘we need to know’ subsection, a few paragraphs that define the sub-problem that will be solved by that discovery and justify its importance.

In writing each of these sub-sections you should cite literature to make the point that the sub-problem needs to be solved. You should not cite literature just to impress the reader with your erudition. They don’t care. The only thing they care about is whether your research project needs to be done.

You should also cite, and carefully refute, any literature that appears to contradict your position. You cannot ignore it. The expert referees will probably have read it.

It’s also worth citing your own work on the issue, even if it is merely confirmatory. This allows you to demonstrate that you can use the research techniques needed for the project. You should be honest about the status of your work. It is much better to say “we have confirmed X’s finding using the techniques we shall use in the research project” than to  suggest that you made the finding. Consider the possibility that X might referee your application.

If, for any of the discoveries you expect to make, you cannot write a convincing ‘we need to know’ subsection this means that one of your sub-projects is going to discover something that we don’t need to know.  Nobody will fund research that discovers things we don’t need to know, so you have to get rid of that sub-project. You need to edit the description of the research project. Delete that sub-project. Replace it with a sub-project that will make a discovery that you can justify.

Once you have written sub-sections that convince the reader that all the discoveries that will be made by your research project are things that we need to know, you can write the final sub-section. This is the introductory subsection. It starts by stating the overall research problem. You need to express the research problem in such a way that it incorporates all the sub-problems that you have justified. Then you need to justify your project by saying why it is important to solve the research problem.

Typically there are two kinds of justification for solving a research problem. I call them the ‘giant leap forward’, and the ‘bad stuff is happening’.

The ‘giant leap forward’ justification argues that solving the research problem will take your research field forward. It has the advantage that in order to support it all you need is a comprehensive understanding of your field and how it is developing. It has the disadvantage that researchers from outside your field may disagree with you about how important it is to take that leap forward.

The ‘bad stuff is happening’ justification is common in the medical and social sciences. The argument is that something bad is happening – such as people suffering from a disease, or lives being blighted by a social problem – and solving the research problem will give information that will make it possible to prevent the disease or solve the social problem. It has the advantage that the evidence to justify your research is the stories about the bad stuff, which are in the real world. It has the disadvantage that people may not believe that you will get the information needed to cure the disease or solve the social problem.

It is also important to bear in mind that the ‘bad stuff is happening’ justification has the implication that you will need to show in your description of your research project that you will disseminate the information you gather in a way that will lead to the real-world problem being solved. The ‘giant leap forward’ justification has no such implication: publication in journals will be deemed to be sufficient to ensure that the project achieves its maximum benefit.

In my next post I shall explain how you can ensure that the two sections of the case for support you have written will allow you to write the last section of the case for support just by cutting and pasting.

Posted in proposal structure, Writing the Case for Support | Tagged , , , , , , , , , | 3 Comments

One Idea – Several Projects

Posted on July 16, 2012 by Jacqueline

In Chapter 7 we talk about dealing with low success rates by creating several applications from one project idea.  Once you understand how to read and use the application template, writing up different versions of the same idea is straightforward.

But funding agency schemes and priorities differ and there may be restrictions that stop you sending the same project to different agencies anyway.  So, must learn how to vary your applications in a way that retains the spirit of your original idea.

But generating these variations can be challenging.  This post suggests a way of thinking through this process.

Firstly, decide which dimensions of your research are non-negotiable.  These will generally be your motive for getting out of bed each morning to carry out research (or simply where you have built your track record).  They might include one or more of the following:

  • The topic you explore (e.g. horror films, small island tourism)
  • The question you want to answer (e.g. how are memories stored and updated?)
  • The method you use (e.g. conversation analysis, Transcranial Magnetic Stimulation)
  • The population or sample you investigate (e.g.  looked after children, female entrepreneurs)
  • The benefit you want to create (e.g. helping small food producers, neuro-rehabilitation)

These dimensions will usually remain fixed (unless your fixed dimensions are also ‘unfundable’ ones – in which case, see Chapter 1).  Then ask yourself the following further questions about those dimensions that you are prepared to vary:

  • Is there any other topic that this project could apply to?
  • Would any other methodological approach answer this question?
  • Is there any other question I can ask about this topic/population/sample?
  • What else can I use this method to investigate?
  • Does any other population face the same issues?
  • Would asking a different question or working with a different method/sample create the same benefit?

Your possible project variations will lie in the answers to these questions.  At this point, apply the importance and success criteria to check whether the new-look project is viable.  Then check whether it fits the funding agency guidelines and criteria.  Then, start writing.

Posted in Multiple applications | Tagged , , , | Leave a comment

Toolkit Rocks ESRC Festival

Posted on July 4, 2012 by Jacqueline

Prof. David Shemmings, Grants Factory veteran, uses techniques from the Research Funding Toolkit in his popular grant-writing events around the UK.  His workshop  yesterday, at the ESRC Research Methods Festival in Oxford, even made the Times Higher.  Find out why good proposals are like sticks of Brighton Rock….

http://www.timeshighereducation.co.uk/story.asp?sectioncode=26&storycode=420405

http://www.ncrm.ac.uk/RMF2012/programme.php?id=E3

 

 

 

Posted in proposal structure, Workshops | Tagged , | Leave a comment

Describing your research project.

Posted on June 30, 2012 by Andrew

In this post I want to discuss how to build up a full description of a research project. The description of the research project is the last and biggest part of the generic case for support. Its length should be about 50% of the total and, as I have explained, it is the part you should write first.

In my last post I explained that the easiest way to start writing the case for support is by describing a sub-project, a discrete set of research activities that will discover something. I also put a sub-project checklist in the resources section. In this post I want to discuss three issues:-

  • the actions you take after you have written the description of each sub-project,
  • how you string your descriptions of sub-projects together to produce a readable narrative, and
  • how you top and tail the list of sub-project descriptions to produce a complete draft of the description of the research project.

In chapter 7 of  the book we explain that the description of the research project should be built up from about four sub-projects. This is true whether you are conjuring the sub-projects into existence by describing them or whether you have already designed the entire project and you are breaking it down into sub-projects in order to write the case for support.

As you complete the description of each sub-project you should do two things. You should record the information you will need for writing other parts of the case for support and you should check whether your project is heading to be too big or too small..

In order to record the information you will need,  you should maintain five lists.

  1. A list of discoveries: each sub-project should lead to one discovery. In the next section of the case for support that you should write, you will need to cite evidence that will convince the reader that we need to know the things you are going to discover. For convenience, the discoveries should be listed in the same order as the sub-projects that will discover them.
  2. A list of the research competences needed to carry out each subproject. Somewhere in the case for support you will need to convince the reader that your team has these competences. The best way to do this is to cite publications in which you have used the competences.
  3. A list of methods used. The list should include a note of whether the method has been explained and which sub-project description contains the explanation.
  4. A list of the resources, including staff-time and your time, that will be paid for by the grant. As soon as you start writing this list you should seek help from your institution’s research office in compiling the costs.
  5. A list of institutional resources that will be used by the grant, including your time. You should discuss with your institution’s research office which of these will be provided free and which should be paid for by the grant.

In order to check whether your project is likely to be the right size, when you update your lists of resources you should calculate whether the time and cost required for the research project are likely to be within the range of that you can request in your application. You should also check whether the institutional resources – including your time – are likely to be available to commit to the project and will be seen as a reasonable commitment by your colleagues and your head of department.

If it looks as if either the institutional commitment or the requested cost will be too high, think about curtailing the overall project so that you end up with commitment and cost in the right range. On the other hand if it looks as if the cost will be too low, think about adding more sub-projects so that you can scale up your project. Alternatively, think about finding a funding scheme for which your project will be the right size.

If you don’t know the funding agency’s limits you can get advice from the funding agency and from your institution’s research office. If you don’t know which agency to target you need to get advice or read chapters 1-3 of the book; chapter 12 also has advice on how to assemble your budget.

Stringing the sub-projects together to make a coherent project is a matter of deciding whether there is a natural order for doing the research, or for describing it. It is often the case that the execution of one subproject will depend on information to be discovered in another, which will dictate a natural order. However, you should be very careful to avoid designing a sub-project that depends on a particular outcome of a preceding sub-project. One of the commonest reasons for rejecting a grant application is that the committee forms the view (correctly or otherwise) that if the first sub-project finds z instead of x or y, then the other sub-projects will not be worth doing.

If you are lucky, you will reach a point where you have a budget in the right range, and four sub-projects that make a coherent project when they are combined. If you are unlucky, you may need to adjust the number of sub-projects by combining them or splitting them. You may also need to set one or more sub-projects aside for a future grant application and generate one or more different sub-projects to get a better fit. Don’t worry if you have to do this – it is good to maintain a library of ‘do-able’ sub-projects in case you have to write a grant application very quickly.

When you have got four suitable sub-projects linked together in the right order you are ready to write the opening sub-section of the project description. This needs to do the following:-

  • State the general research approach.
  • Introduce the sub-projects in order.
  • Describe any general methods. Use the list of methods you have compiled (see 3 above) in order to ensure that all the methods that will be used in the project are described just once.
  • Discuss any necessary general issues – for example ESRC requires a special justification if new data are to be collected and most funders will require statements about how ethical and data protection matters are to be dealt with if research involves experiments on animals or research on humans or information about individuals.

Finally you should write the tail end of the description of the project which should describe what  you will do to make sure that your research findings are appropriately disseminated and any actions you will take to ensure that they have appropriate impact. Any activities which will require resources from the grant should be described in much the same way as a sub-project and the resources should be added to the resources list.

The resources section contains a checklist for the project description. The best way to use it is to get a friend to read through your project description and fill in the checklist.

As soon as you have written the project description you can begin to work out the detailed costings with your research funding support office.

In my next post  I shall describe how you write the research background section. We shall see that the fact that you will already have written the description of the research project makes it much easier.

Posted in Testing your proposal, Writing the Case for Support | Tagged , , , , , , , , | 1 Comment

You can take an academic to a grant-writing workshop but…

Posted on June 16, 2012 by Andrew

The poster describing the University of Kent Grants Factory won first prize at the ARMA conference in Southampton last week. I have put a pdf of the poster, which is brilliantly drawn by Phil Ward, on the resources page. The remainder of this post is the poster abstract.

————————–

This poster describes a programme that helps researchers learn what a fundable grant proposal looks like – and how to write one.

It is easy to convince an academic colleague that a fundable grant proposal must be clearly structured and well written. It is almost impossible to get the same academic colleague actually to produce a clearly structured, well-written proposal.

The ‘Grants Factory’ approach achieves this through training sessions led by senior academics with personal experience of grants’ committees. It was developed at the University of Kent and was the springboard for a forthcoming handbook The Research Funding Toolkit (Aldridge and Derrington 2012), see www.rftk.eu.

The training sessions include the following elements:

• Insights from successful researchers who have evaluated hundreds of poorly written proposals
• Informal, small group format
• Discussion of writing technique and style
• Group work on actual proposals

The Grants Factory acts as a catalyst for the formation of an engaged network of funding applicants with a positive, realistic and resilient approach to winning research grants.

The Grants Factory has run at Kent since 2009 with 8-10 oversubscribed sessions each year, repeat attendance, testimonials from funded alumni and a number of strategically important, high value grants for the University.

Posted in Testing your proposal, Writing the Case for Support | Tagged , , | Leave a comment