Bioinformatics in the Lab: Putting a Yearly Plan Together

"Plans are worthless, but planning is everything" Dwight D. Eisenhower

Making yearly software development plans for a wet lab is at best a frightening moment, commonly a nightmare and very often totally ignored.
From the makers perspective, buried in the trenches, already overwhelmed by an avalanche of reactive tasks, making plans for he year to come can be seen as a boring process when not  a total waste of time. From the upper management one, yearly plans are a corner stone, a transmission belt between strategy and tactical realization. Middle managers have therefore to organize the planing process... before making it happen.
The situation we'll consider in this post is a common one in a research environment, when bioinformatics plans have to be drafted to support a wet lab effort. The process described here is designed for a medium size entity, eventually part of a larger organization. It consists for example in a lab with thirty-like scientists and technicians ran by five group leaders. This lab is supported by a group of five computer folks, bioinformaticians or computational biologists. Let's also consider that the whole group already works together on the longer term, therefore killing the business analysis barrier. In other words, people are used to talk to each other and they know what they are talking about.
Drafting plans cannot be a top down process, it must take into account multiple perspectives: the strategic ones, relayed by lab managers and the practical ones, voiced by the makers, the bioinformaticians. Moreover, everyone must be listened to (a hardly achievable process in large scale passionate meetings.) Adoption shall be general and funnier tasks must be mixed with less exciting ones.
We propose a four steps process:

• gathers the tasks,
• estimate the effort,
• individually prioritize,
• make the One Plan.

The overall planning is facilitated by a single person, navigating across the different contributors. This orchestrator shall have a fair understanding of the scientific domain but should come from the computational side, with a better sense of the technical complexity. Two global meetings are needed: a short one up front to explain the process and a longer one for the last step.

Looking for a path, in Polar Bear area - Spitzbergen 2001

Step I: Gather the tasks

Tasks are defined in the agile manifesto as pieces of "working software." They shall bring some value to the scientists while not being too large. If one project is too complex, it shall be broken into smaller meaningful pieces (typically smaller than a few weeks of effort), as they will more easily fit in the global puzzle.

A key point of the tasks gathering is to go and visit each manager individually to build their own list. If an email is sent upfront to describe the process and have them think about their wishes, a couple of 30 minutes one on one meetings are usually more than enough to wrap it up. Such private interviews might take longer on the orchestrator's shoulders but it allows every manager to have a dedicated window, with her/his problems and vocabulary, without the personal interferences of a more crowded room. Overall, experience shows that they are a longer term time saver but, more importantly, they are the first steps in building a global adhesion to the larger plan.
While cycling through each lab head, tasks are consolidated, merged or split. The outcome of this first step is a spreadsheet with a minimalistic descriptions (good will throughout the team and general understanding are a key factor of success). A Google document perfectly fits the purpose for the more collaborative steps to come.
Congrats! We have a list. Time now comes to price those tasks.

Step II: Estimate the effort

The purpose of this step is to assign a crude estimation to each of the collected tasks. Every computational folks is to give his/her input.

The idea is for everyone, in turn, to roughly evaluate the number of days needed to complete each task. Again, having the team working together on the longer term, continuously talking, makes it unlikely for new challenges to fall out from blue sky. However, if a task one liner is not clear enough to give a raw guess, a small chat with the facilitator or a lab manager should be enough.
Each developer shall evaluate independently from each other. Going back to our shared spreadsheet: we simply add a column per bioinformatician and ask each of them to simply hide the other's columns when they fill theirs. If a developer has no idea of a task cost, he should simply skip the line.
The last step is, for the facilitator, to take the median estimation for each task. In case of bimodal distribution, extreme values or doubt, just go back to the source and clarify.
We now have tasks and a cost for each of them. We can start the prioritization process.

Step III: Individually prioritize

In this step, each lab manager will select the most important tasks, as if she/he was ruling it all.

In our example, we have 5 bioinformaticians. However, they might not be dedicated full time on new developments for our lab in a matrix environment, caught in other projects, production maintenance or data analysis. However, based on their recent history, we can have an approximation of the time they will be able to spend and sum it to have an overall available force for the year: N days.
Each manager independently select the tasks she thinks most valuable until the cost sum up to N. There is order at this stage. Once again, the shared spreadsheet is a convenient tool and ignoring the other's calls by hiding their columns is a cheap and efficient solution.
Almost done! Every manager has her/his own plan. It's now time to build one plan for the whole lab.

Step IV: Make The One Plan

Good news: at this stage, everyone is well aware of the tasks and the planning process. It's time to bring coffee, croissants and all the folks in a room to rank those tasks.

Naturally, some tasks will have more votes than others and get ahead with natural approval. Some others will have only one vote but, as business drive them, there should be a consensus for giving them priority (if no consensus, the boss' voice.) Some others are technical or inferred by dependencies and developers will defend why they shall come up.
Beside the fact it is easier to estimate shorter tasks, we now see the benefit of having split a larger endeavor in smaller chunks. It will be easier to convince your peers to let a small development in the top list and have at least a useful part of the work done, instead of having nothing delivered at all in one direction.
During this step, tasks are ranked. Using our spreadsheet, it is simply achieved by moving lines.
Based on the effort estimation, three task categories emerge: a) the ones that will have first focus and decent chance to be completed; b) the ones that will maybe get some traction; c) the ones that will have no chance to get any attention during this year.
The last category is certainly the most important. Having at once this discussion about what will not happen in a foreseeable future will clear off the way for developers and avoid later frustrations among scientists.
A medium term plan exists with, if not a total consensus, a general understanding of the decisions. It is of course not set in stone and might evolve because of technical or business reasons. But at least, a plan exists.

Conclusions

Beside generating a document, the process described above have several advantages. Communication channels within a large group exist in many forms and are the foundation layer of the global understanding. But the multiplicity of dedicated one on one dialogues during the plan building is key to have dedicated focus, without pack interference. More vocal people will have the same input as shyer persons. And everyone will have time to get their arguments rolled out and spread before the final gathering. Moreover, as every person in the team participated more or less equally, they will adopt the final decisions more easily.

Having such a list offers a ground for communication with upper management, sponsors and stakeholders. From the bioinformaticians perspective, it can be used as a defense document ("don't ask me again this 'urgent' tool, we've decided together why it was not that important") and a clearer road to follow for the coming year.
Overall, the whole process is straightforward and rather short for all the team members as the main effort lies on the facilitator's shoulder. Experience has shown how it lays down a convenient ground for an agile execution to come during the year. But one shall not forget that such a process is not perfect and need certainly to be adapted and improved.

"Everyone has a plan 'till they get punch in the mouth" Mike Tyson

Acknowledgements

I would like to thank my former colleagues at Genentech Research and Early Development. Jeff Blaney, from the cheminformatics department, seeded the idea in our mind. And the whole fantastic Microchemistry and Proteomics Lab, lead by Jennie Lill, my colleagues in the Computational Proteomics team, always ready for new adventures...