Opiniomics

bioinformatics, genomes, biology etc. "I don't mean to sound angry and cynical, but I am, so that's how it comes across"

A guide for running large projects

As I hope most of you know, I have two jobs: I run a research group at The Roslin Institute, and I am also Head of Bioinformatics at Edinburgh Genomics, an academic genomics facility at the University of Edinburgh.  It’s fair to say that in both roles I see a fair amount of very large, multi-centre projects, and over the years I have picked up a number of ways of working which I think represent best practice in running this type of project.  I’ve jotted these down below and hopefully these will be helpful to some of you!  Feel free to suggest more in the comments.

1. Sort out SOPs very early on and stick to them

I think this is probably the most important point, and I suspect it is the one that is ignored most often.  If two or more participants in a large multicentre project are going to be producing data, or samples, then you need to make sure they are equivalent.  It’s not enough to say, for example, that groups will produce RNA-Seq data.  Considering all of the sample and library preparation methods that are possible, not to mention read depth and length, there are probably 1000s of ways of doing “RNA-Seq”, and unless two data sets are produced in very similar ways, they are incomparable.  Similarly 16S and many other protocols.  So the very first meeting after winning the grant should be an SOP meeting – agree on them and stick to them.  No variations allowed.  The same for bioinformatics and data analysis protocols – agree on software, versions and parameters and stick to them.  No exceptions, otherwise that parameter you tweaked will end up proving your biggest false positive result.

2. Be clear where the money is going

This can be one of the biggest sources of friction within large grants.  If there is any uncertainty about which group will get which amount of money and when, then this can cause huge arguments, internal competition and distrust.  It’s a really good idea to be clear right at the very start who is doing what and what they will get paid for it.   Arguments such as “Group X are doing Y, but we can do it far cheaper” are really not helpful.  Each institution will have their own costing model and costs are rarely directly comparable.  Be clear about money and trust one another.

3. Stick to deadlines

If you have signed up to deliver X to Y by Dec 2015, then deliver it by then, because Y will have planned all sorts of things around that date.  They may even be employing staff to start around Dec 2015 specifically to deal with X’s input.  They may have an even larger project starting in March 2016, and need to get your project finished before then.  If X doesn’t turn up on time, things get really messed up.  Once you’re behind, it can be hard to catch up.  So set realistic deadlines and stick to them.

4. Be clear about exactly what the deliverables are

This is very similar to the SOPs I mention in point 1.   What are you delivering?  Is it DNA?  Or is it a throat swab?  If group X expect DNA and are sent throat swabs, then you’re really in trouble.  However, it can be much worse than that.  I spoke to a post-doc recently who was sent VCFs from a collaborator.  That’s what had been agreed.  However, what he actually needed was a single, co-called VCF across all samples, or at worst, gVCFs for all samples.  What he got was VCFs called on individual samples in isolation.  Welcome to pain.  Be clear about deliverables, and be specific.  Recognise that many standards are not standards and that you need to specify in fine grained detail what you need and what you will provide to others.

5. Consider employing a project manager

A project manager is someone who ensures that all partners are doing what they are supposed to do, that they are doing it on time and that all deliverables are met.  They are the most important and often most helpful person in the entire project.  So employ one and give them the authority to run the whole project.  Note this should not usually be the PI.

——————————————-

I am sure i have missed many more!  Feel free to suggest them in the comments.

DISCLAIMER: if you feel this is aimed at you, it isn’t.  Honestly.  It’s a general post containing opinions formed across many projects I have been involved in 🙂

7 Comments

  1. On the SOPs and PM – couldn’t agree more. I distinctly remember giving an (industry focused) career development talk to a group of graduate students and postdocs at GW last year, and when I asked “How many of you use SOPs in your work?” Not a single hand went up. 100+ trainees in the room. My next thought was “How many of their PIs don’t use or even know want an SOP is?” (let alone a QA process). It was maddening. Then a student in the front row raised his hand and said “What’s an S-O-P?” (no kidding…) #mindblown

  2. How about this: Try to hire someone as the project manager who has a good reputation in managing or leading large projects before (not necessarily someonw who can only write good or can talk good, it should be different from the project representative). Someone who knows how to interact with people (inside the project group or outside the group with other colleagues) without making them feel useless, unappreciated, unacknkowledged, or even abused in the project.

  3. That’s what you get for using a TLA (three-letter acronym) instead of English. If you asked them if they had standardized lab protocols for repeatability, probably over half would have said yes.

  4. Snarky replies aside – I would argue that an SOP is more than -just- a “standard protocol for repeatability”. Most organizations I’ve worked with (and for) use the term SOP and it generally implies a standard operating procedure AND active quality assurance (QA) oversight to ensure the SOPs are actually being followed. In a strictly academic “researchy” setting I wouldn’t expect QA to be in place (beyond the PI checking notebooks at best) – so those “standardized lab protocols” would not really be SOPs (in my book).

  5. SOPs are great when you are collecting multiple data across multiple data providers. Most of the students work on progressive projects (for want of a better term) where each experiment is bespoke and follows on from the ones before. There are no SOPs for a protocol that is novel and used only once or twice.

  6. Your surprise that people in academia are unfamiliar with corporate jargon suggest to me that you were unprepared to give career advice to them.

    Please note SOP ranked #1 in “10 Cringeworthy Business Jargon Examples that Should Be Banned” http://www.lifed.com/10-cringeworthy-business-jargon-examples-that-should-be-banned)

  7. I disagree with SOP bashing. I’d be disappointed in people who didn’t know what one was.

Leave a Reply

© 2017 Opiniomics

Theme by Anders NorenUp ↑