Tuesday, January 6, 2015

"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.