Oh boy, lots of these:
- Poor documentation for old data that you're told to make into something publishable. Usually it's also garbage quality.
Sometimes it's better to convince someone to take a project behind the barn and put it down rather than spending immense amounts of time and effort to generate low-confidence results. Most people are too stubborn to kill projects, however. Learning to say "no" to potential collaborations that seem doomed to fail/drag on forever is perhaps the most important non-computational skill for early career scientists to learn, in my opinion.
- Collaborators who want you to do an analysis, but don't really know the question they're trying to answer.
- Or that label all their files as non-descriptive nonsense and don't provide a sample map despite you asking multiple times.
- Or saying they want to know X, Y, and Z, but their data can really only answer Q.
- Or get upset when your sound analysis doesn't show exactly what they want/hope.
- Or generally have an utter disregard for other projects/your own work, demanding an unreasonable turnaround.
Most of those can be prevented by meeting with those designing the study ahead of time, but many PIs seem to ignore the analysis aspect until they suddenly have a bunch of data that they don't know how to handle. Even then, being very clear about what you need (data, metadata, etc), exactly what they want, and how long you expect it to take (plus an extra 20-30% of time) can help assuage them. Being clear, upfront, and maintaining constant communication is crucial.
Additionally, having some self-respect is important. You are not a robot, sometimes things take longer than you expect, and collaborators need to understand that performing complex, custom analyses is a task that requires significant planning, critical thinking, and resources...just like involved wet-lab experiments. Sometimes you need to do significant literature digging to determine the most appropriate methods for their data, particularly if you're not familiar with the assay/format/typical analysis methods. If they didn't plan for any of that, that's on them.
- Poor experimental design in terms of lack of proper controls and replicates.
Again, all project planning should include the person who's actually going to be analyzing the data. A pipe dream, certainly, but maybe someday.
- "Fishing"-type studies in general.
These tend to lead to drawn out analysis periods with lots of work done that doesn't produce anything of use. If you start hearing, "well can you look at the data this way" every time you meet, then yup, you're fishing.
People failing to appreciate how long it takes to get something done.
So far the major issues I had were related to bad experimental design
It would be better if you can focus/refine this challenge (unless you meant it as a very general question). If a person was working in a core facility then these sort of challenges are part of every day job that you can't avoid. If you were helping people out of goodness of your heart then you may have a completely different reference/angle.
That's a good point. I don't know if the distinction is always clear. Sometimes people who are helping out of goodness of their heart are treated as a core facility.