Personal Thoughts on Collaboration and Long-Term Project Planning

Our opinions can change over time, and some long-term effects may not be noticeable until 5+ years of experience.

While I still don't think I have everything figured out, I am using this page to organize my thoughts on some topics that may be of use to the broader community.  I also hope that the update/change logs may also be helpful for giving credit to feedback from others during discussions.

Nevertheless, for these posts, I am going to try and focus on what I believe I understand most clearly:

• Post-Publication Review
• Staff in Shared Resources
• Long-Term Maintenance / Support
• Code / Data Sharing 

Again, it is probably a little early for me to be giving advice (since I don't have a solution worked out for myself yet), but I hope sharing my experiences can be helpful to other people as I sort out the details for figuring out a sustainable workload for myself.  Having the patience to work on agreed processes step-by-step is also important, but I believe some of this information may be important for future changes (even if they don't occur in the immediate future).

To be clear, I very much enjoy working with collaborators as a Bioinformatics Specialist in a Core Facility.  So, while some of what I am saying indicates room for future improvement, I have an overall positive impression of my work environment and the researchers that I have worked with (who are passionate about helping other people).

Plus, even though I think some of this content is important for long-term discussions, I also want to emphasize that you can be genuinely proud for putting in your best effort to help people and there is some need for short-term support (such as a temporary difficulty in getting additional funding) or at least giving people the chance to think carefully about whether a more major transition is necessary.

Update Log:

7/26/2019 - public post date
7/29/2019 - trim down introductory paragraph
7/30/2019 - add link for maintenance / support, and modify preceding sentence
8/4/2019 - minor edit after some proofreading by a family member
8/6/2019 - minor changes
4/30/2020 - add link to code / data sharing details (either required or suggested)

Personal Thoughts on Collaboration and Long-Term Project Planning: Staff in Shared Resources

While I am still having discussions to understand and precisely describe my 10+ years of genomics experience (and the influence on current projects, particularly those started Post-2016), I have some opinions that I would like to share for broader discussions:

1. If bioinformatics support comes from a shared resource, I think there may be benefits to limits on percent effort (as a fraction of split salary) and/or PIs supported by individual staff members.  A colleague kindly referred me to this paper that recommended a minimum limit of 5% effort.  My tentative opinion that there may be a benefit to having a maximum limit of 4-5 PIs (although the specifics probably vary, depending upon whether the analyst has a Master's Degree or a PhD, for example).
• For me, I feel very comfortable in saying that I need to have a maximum limit of 3 average difficulty projects per day.
• Also, if possible, I believe that gaining in-depth knowledge on a limited number of projects should help with publishing higher impact journals and/or novel methodology.
• I think this matches the minimum level of effort for NCI awards, as well as the concept of having a conflict of commitment.  I also learned about both of those at work.
2. I believe the PI / project limits for shared staff should be more strict when developing software that requires long-term support.  It is important to remember that the average (or minimum) amount of time per project will be inversely related to the total number of projects.  So, if you want to provide prompt feedback to users of your software (and fair support for all projects handled by an analyst), this needs to be taken into consideration when scheduling projects.
3. If an analyst is supporting multiple labs, I believe the best-case scenario may involve splitting time between labs that knowingly collaborate with each other.  For example, if the set of projects among all labs is known, that may help scheduling submission (and expected revision) for papers that are expected to be published in the highest impact journals.  Regardless of whether this is done, the ability to support any given project is dependent upon concurrent support of other projects, and I think that is at least something that needs to be kept in mind.
4. I think there should be transition periods when making changes in staff support.  While I'm not 100% certain about the details, I think a yearly or quarterly review may be a good idea.  I don't believe it is a good idea to make support decisions on a daily or weekly basis, and it often takes me 1-2 months to feel comfortable with a project that has been was previously worked on my somebody else.
5. At least for me, it helps to have somewhat frequent discussions / analysis to help remember the details for a project.  For example, I would probably recommend having at least monthly discussions (and I think weekly or daily discussions / analysis is probably preferable).
6. Likewise, I can discover and fix errors when spending a substantial amount of time for critical assessment of results.  For example, my recommendation would be to expect to have 10 "rounds" of analysis (hopefully, some of which includes creative / custom / novel analysis).
• This isn't perfect, but I know I have found (and corrected) some errors this way.  This is kind of similar to being able to make new discoveries (or correct additional errors) when you re-read a paper.
7. It is my opinion that specialized protocols should be an area of expertise for individual labs (which may or may not be offered externally), but this should not be a responsibility / service of the core.

That said, I am expecting the "Update Log" to reflect at least a few additional changes (as I have more discussions - primarily internal at first, but I think some broader feedback is also valuable).

While I am primarily focusing on the project management part of shared staff in the points above, the concept of an optimum workload can be important in various situations.  For example, if your optimum workload is 5 projects and you are trying to take on 10+ projects, you will either do lower quality work or not have an even distribution of time on projects.  However, that does indicate a possible solution: if somebody is having difficulties with supporting a certain number of projects / PIs, they may actually be able to be capable of producing excellent quality work if they focus on fewer projects more in-depth.

Update Log:

7/26/2019 - public post date
9/14/2019 - add note on discussion intervals
9/16/2019 - remove nearly duplicated sentence
9/23/2019 - mention being able to catch errors as I perform additional analysis for a particular project
9/28/2019 - add point / opinion #7
4/16/2020 - add link about effort limits and conflict of commitment
4/17/2020 - minor change