Do any organizations use a hybrid approach with projects for both scientific groups/teams and programs?
Our programs are highly collaborative with members from each scientific group. However, not all entries can be categorized under a program. There is a lot of more general R&D that is specific to the scientific group that cannot be assigned to the program. Thus, there should be a project (folder) to store these types of non-program related work.
Is there any disadvantage to this type of hybrid approach? It would allow R&D to be shared among scientific team members yet provide an easy way for program-specific work to be shared between various members of different teams that collaborate in the same program.
We are already planning to use an entry schema to capture metadata pertaining to team, project, targets, assays, so regardless of where it is stored we should be able to find it. However, I’d like the storage of ELNs to be intuitive to the end user.
@JasonDG Hi!!! I’d say why not be creative?! I can’t think of any downside of having projects with the hybrid approach. I would even recommend creating Projects by each org/team so that the scientists can keep a folder to keep their notes under it, and a separate projects for collaborative work where you can tailor your permission structure to fit your needs!
I have (and am wrestling) wrestled with this for a long time. I do believe that there is room for hybrid and that it can be effective.
However, I think to make it work, it’s important to have some sort of governance for the use of Project/Folder hierarchy in general. This applies whether or not you are hybrid, but it’s more important in a hybrid model. The risk with hybrid is unpredictability of what goes where. You could end up in a situation where authors and searchers need to always try each of the two main dimensions.
If you have a governance process that vets the creation of new Projects (or high-level folders), then there is a person in the loop to make sure that you maintain a rationale model. Further, the result of the governance process can be to update a master roadmap document (especially good for new hires) and to communicate to the broader organization.
A related point is that they tool should always be in service of the organization and the science and not the other way around. This means that to really solve this well you need to start with a clear organizational model. How is (or should be) the organization structured and how do you operate? How does Program Management define and manage work? If you have clarify here, then the Projects/Folders can built on that. However, if this is in high flux or not well organized, then you won’t have a foundation to model anything in Benchling.
Ultimately organizing complex information in a single hierarchy is a challenge. This is why tags and “smart folders” (and if you are talking about databases “views”) are so useful. They all allow other ways of organizing the same data since one size may not fit all. Your use of entry schemas is an excellent way to provide this extra view capability in Benchling. If you don’t have clear rules for what goes where in hybrid, then you may be best to keep a homogenous Project/Folder model and just use entry schemas and saved searches for all else.
We started of as functional area / scientific teams as the project folders, but have decided to separate special pipelines into their own project structure, especially when we needed to do some access controls without creating another organization for separation.
Again - i think this is where the idea of “tagging” could be huge to enable smarter “findability” and allow for a dominant path to help sort things out and not only rely on the Folder name as the metadata...
