- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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:
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
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
This comment has been removed by a blog administrator.
ReplyDelete