The hard truth about research grants

You must do many silly things to get a large research grant:

  • You must know precisely what you will do for the next five years. Yet, in my experience, good researchers only have a vague idea of where they will be in 5 years. If you know the promising research directions you will encounter, you are an astrologer, not a scientist.
  • Your plan must be infallible. Yet, in my experience, research ideas that never fail are not research ideas at all! They are mere applications of known principles. There is no research without risk. The more ambitious the research, the riskier it is.
  • Your work must revolutionize your field. Yet, as stated above, it must also be  infallible.
  • Your work must have crucial applications. Make it up if you must! When Einstein came up with E=mc2, he should have pointed out the possibility of dropping nasty bombs on Japan. Again, we expect scientists to know the future.
  • You must work in large teams, packing up a broad range of researchers. Yet, there is no clear evidence that correlation exists between the resort to extramural collaboration and overall research performance. The goal—once more—is to minimize risks. It is unclear whether it actually reduces the risk at all. And the cost is added bureaucracy.
  • You must promise to train many new Ph.D.s. Somehow, flooding the job market so that there are hundreds of qualified applicants for every research job is highly rewarded.

Thankfully, Peter A. Lawrence has many good ideas on how to improve the system:

  • Grant applications should be short. Quick to prepare. Quick to process. Currently, it is not uncommon for scientists to spend months writing grant applications, and weeks reviewing them. Wasteful!
  • You should be able to apply for grants based on your record alone. The requirement to submit a project or research program is silly.
  • We should be critical of large groups. For some large projects, such as building a multi-billion-dollar machine, you need a group. To investigate the properties of some algebraic structure, you don’t.
  • You should only offer a handful of research papers for review. Pick your top 3 papers and don’t mention the rest. In Canada, NSERC applied this idea, but they did not go far enough. They ask us for our top contributions, and then they ask for the full list. By reviewing researchers on only their best work, we would lift the incentive to produce many weak papers.

I conclude from a quote by Michael Nielsen:

Some years back I constructed a list of papers I especially admired, and was surprised to discover that with only a few exceptions they were produced from unfunded research. This was sobering, since it suggest that receiving research grants was (…) anticorrelated with doing work of the highest quality. Grants seem to be good at sustaining an established area, but not very good at all at producing the conceptual innovations that start new subfields. (Michael Nielsen)

(And before anyone jumps at this… Michael did not write that having a large grant was incompatible with highly original research.)

Published by

Daniel Lemire

A computer science professor at the University of Quebec (TELUQ).

9 thoughts on “The hard truth about research grants”

  1. The trick is to apply for a grant to do work you’ve already done. Then when you get the grant, you start on the work that you’ll apply for your next grant to do. Yes, this is dishonest, and I’m not endorsing this approach, but it’s how some people play the game.

  2. Following the same idea here is an interesting reading on PLoS biology :

    Real Lives and White Lies in the Funding of Scientific Research
    The granting system turns young scientists into bureaucrats and then betrays them

    Peter A. Lawrence*

    Department of Zoology, University of Cambridge and Medical Research Council Laboratory of Molecular Biology, Cambridge, United Kingdom

    http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1000197

  3. There is strong evidence that collaboration leads to higher levels of citation.

    Wuchty, Stefan, Ben Jones, and Brian Uzzi. “Science Commentary: Why Do Team-Authored Papers Get Cited More?” Science, September 2007, 317: 1496-1498

  4. Hi Daniel – Thanks for the quote. A caveat is that this obviously depends on the type of work one finds appealing. Others would no doubt put different papers near the top of their lists. Still, I was pretty taken aback when I constructed my list and realized it was nearly all unfunded work.

  5. You’ll get caught if the reviewer looks at your current work isn’t it? If not, they’re going to have a hole in your publication record?

  6. @Jon To change this, I think that the first step is to raise awareness. The problem is that many people are not even aware of how flawed the system is.

    @Ian There is strong evidence that collaboration leads to higher levels of citation. Yes, and there is strong evidence than collaboration leads to more grants too. Basically large groups do better and coincidently, we also decided a priori that large groups are desirable. Can you smell the circular argument? I bet that if we decided that research on wireless sensors was our priority, we would publish more wireless sensor papers, the wireless sensor researchers would get cited more. I’m not against collaboration, but I’m against the unsupported belief that working in large groups is better.

    @John Yes, that’s precisely how to get grants, by using your recent papers. That is the first piece of advice I give my page Get a grant. Basically, you tell them that you are going to do whatever you already did. These are the little dirty secrets you only read on blogs. 😉

Leave a Reply

Your email address will not be published.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

You may subscribe to this blog by email.