This post is a collaboration between myself, and a guest author who wishes to stay anonymous. They are a researcher and PhD candidate in neuroscience, based in Europe, and in the post they are referred to as Alice.
When people talk about failures, often rejections are the first things that come to mind. But what about other things in science, that did not work out? Today’s post is all about those – projects that don’t work out, and that do not end up either on your CV and probably even your “CV of Failures” (here is mine).
Read on to find out about the ways our projects have failed, during the PhD or after, AND the lessons from these experiences. In short, here are the 9 ways to fail a project:
- Inheriting a poor project setup
- Failing to plan
- Not enough redundancy
- Changing the scope
- Underestimating the complexity
- No data available
- Collaborating for the wrong reasons
- Starting too many projects
- Forgetting to advertise your successful project
1) Inheriting a poor project setup
Alice: My first project failed in a bad way. In retrospect the idea was not thought through and vague and the methodology was not sound. In fact this is what got me into trouble – as I tried to discuss these issues with my supervisor, he got angry and said that I am at no place to challenge his authority… After two years when he left the project was evaluated by a panel of group leaders at the department and found to be crap from the very bottom. The project was killed.
Veronika: Of course a lot here depends on the supervisor. But from the researcher’s perspective there are still a few lessons here:
- If you inherit an existing project, verify that the objectives and methodology are clear
- Ask questions early on, consult with others
- Remember that quitting a poor project early is not your failure, but might save time and stress
2) Failing to plan
“Failing to plan is planning to fail” – no post about failed projects is complete without this quote attributed to Benjamin Franklin. If you are responsible for the project setup from the beginning, definitely do not skip this step.
This is particularly important for side projects that you might initiate next to your main research, that “shouldn’t take a lot of time”. While that may be true, in my experience things can go wrong is it is not clear who is going to be responsible for what. Or, all content-related tasks might be divided, but nobody is taking the lead on the project. Lesson:
- Spend time defining the project timeline and contributions of all team members, including a leadership role
3) Not enough redundancy in the project
Alice: My second project failed for two main reasons. One was founded around a collaboration which was tied to one person who left. The lesson being that being dependent on certain people for connections or data is a weak spot.
Veronika: I recognize this! I’ve experienced problems when parts of the project depended on specific data, code or tools that were not available / accessible to others. Again a lot about this depends on the PI, but for me the lesson from the researcher’s perspective:
- Be your own best collaborator by using open science principles, sharing data/code where possible. Consider using public data or artificial data in addition to the main data, if the main data cannot be shared.
4) Changing the scope during the project
Alice: […] But there was more. In the course of the project, as I processed the data, the PI got ambitious and teamed up with his colleague who did similar things and was interested. He then wanted to do a much bigger comparative study and requested me to process large amounts of public data which slowed me down significantly. By then my PI left. The lesson is getting too ambitious can drown the project.
Veronika: I’ve had similar experiences too and see it all around me – a PI invents things to try until there are “state of the art” results (similar to HARKing). I’m getting repetitive here but again you are quite dependent on the PI. What you might be able to do:
- Clarify project objectives and timeline in the beginning in writing (for example, type up meeting notes, and send them around after to confirm)
- Open science principles like preregistration might be worth a try, although this depends on your field and will also require the PI’s approval
5) Underestimating the complexity of the project
Alice: My third project did not fail as such but rather faded away., which is a failure of a kind. It was a collaboration with a postdoc who was an expert in the field and had a nice idea. The problem was that the implementation and most importantly interpretation of the data turned out to be much more difficult than she had anticipated and it required more input from both of us than we pledged for. A mistake here I’d say – wrong estimate of the complexity and resources available.
Veronika: Agreed – I’ve had several nice ideas that sounded great when brainstorming, but in the end did not receive enough attention to progress. I have a lot of thoughts about these which would warrant an entire blog post. Still, I wish I would have been better at planning my time. My lessons would be:
- When agreeing on a new (side) project, agree on how much time you can put into it. I think this is hard to do, but if you did have this agreement in the past, the future you will have an easier time letting go of the project.
6) No data available
Alice: The fourth project failed when I learned that I can not get the phenotype data on the cohort I worked on and at this point there was nothing I could do. The data was blocked due to disagreement and issues between my PI and the competitors with whom initially it was supposed to be a collaboration. I don’t really have a recipe how to help that, it is one of the things that I have little control over.
The fifth project failed for a similar reason. But this time it was because we were not allowed to collaborate with the boss of our PI (who has a cohort with the exact phenotype we need) who did not want to publish with the previous boss in view of the career. We were thus pushed to prey on the public data repositories which a) did not have such precise phenotype we needed b) required downloading and low-level processing of large amounts of data which was very straining and hard for a single person and given resources. We managed with the published subset of the data and we found nothing. I spent almost a year working on it.
Veronika: This overlaps a bit with my previous ideas about open science, but in this case there’s not a lot somebody in your position could do other than use public data. Lesson: don’t blame yourself for decisions of your PI!
7) Collaborating for the wrong reasons
Alice: A friend of mine went to a prestigious university to collaborate with a research group there for a few months. He worked very hard, but faced open racism and bullying. The conflict escalated and the project was tabled. Instead of support, my friend’s supervisor was unhappy with him. This is also a situation which is hard to foresee. But perhaps trying out collaborating remotely first and building relationships slowly would be a safer bet.
Veronika: Sounds like a terrible experience for your friend! Agreed it is a good idea to try out collaborations first but perhaps that was not possible. There needs to be not only a research fit, but also a safe environment.
But on the other hand, the environment alone is also not enough – even with people who really want to collaborate, sometimes it just doesn’t work. Getting along well with somebody doesn’t mean your research project will be complementary as well. My lesson would be:
- Know who you will collaborate with, and aim for a combination of research fit & good environment
8) Starting too many projects
Veronika: A “favorite” reason why some of my projects failed, is starting too many projects and then not getting back to them. Often this would happen if I was waiting for reviews on a paper, and already planning the next project. But when a major revision would come in, I would drop new ideas to revise the paper, and once done, fail to get back to the new_idea.txt. Side projects could also end up in this category.
In a way, this is a combination of “failing to plan” and “underestimating the complexity”, but on a larger scale. My lesson from this:
- Keep track of how many projects you’ve agreed to do, and what stage the are in (for example with a Kanban board)
9) Failing to advertise your successful project
Veronika: Congratulations, you finished the project! What now? While this is not technically a failure, there’s still ways to increase the success of your project.
Once you do finish a project, you might not give the project output enough attention. It’s easy to become focused on getting a paper for the thesis, especially if your PI is pushing you to. So a natural response might be to just move on to the next project, leaving the published paper as is.
But maybe it’s good to pause, and give that effort more justice by sharing the paper with your colleagues, submitting a poster about it to a local conference, or writing a thread about it on Twitter. I know I am guilty of this – despite my rather active Twitter presence, I haven’t tweeted about my research this year. The lesson is:
- Give your finished projects (and your hard work!) the attention they deserve!
******
These were the 9 ways to fail a project during your PhD and beyond! These are based on Alice’s and my experiences, but there are probably more reasons there.
Let us know which ones are recognizable, or if you are missing any failures that can happen along the way. The best way is to leave a comment below so they reach both of us, otherwise as usual you can reach me (@DrVeronikaCH) on Twitter!