Methods for Mapping Projects

I wrote recently about how there is no such thing as “one size fits all” management advice. I was reminded of that again recently when I was catching up on some old posts by one of my favorite Kanban aficionados, Pawel Brodzinski. His post “A Fool with a Tool is Still a Fool” is well worth your time. (Yes, that post is from last May. I was very, very far behind!)

I don’t think most people who apply management tools blindly are really fools. I think that a lot of people who find themselves managing people or projects aren’t really all that interested in management, per se. They are interested in whatever they are trying to accomplish. The fact that they even recognize that management methods can provide tools to help them accomplish their goals is actually a huge step forward from where a lot of “accidental managers” are- a lot of people don’t really think about how to manage their team at all.

The tool-appliers realize that management techniques can help them, but they don’t want to spend a lot of time reading about all the different techniques and thinking hard about when various techniques might apply. So there is a strong temptation to take whatever methodology is “hot” right now, look up its manifesto or whatnot, and just apply that.

Of course, as both Brodzinski’s post and my earlier post point out, this is not likely to work so well.

I think that perhaps those of us who are interested in management have to share in the blame for that. We don’t tend to spell out the parameters that define when a technique will be useful. To be honest, we probably don’t even know those parameters ourselves a lot of the time. One of the reasons I wanted to start this blog is that writing about management will force me to analyze what I do and why.

So, in that spirit, I’d like to talk a bit today about when I use different techniques for mapping out a project. A visual representation of a project can be a very useful thing for keeping yourself and your team oriented, particularly when it is a complex project with a lot of intersecting work. There are a plethora of ways to map a project. The most famous is the Gantt chart. I don’t make much use of that one, though. I do produce Gantt charts as a by product of  a dependency analysis, but that is mostly because the tools that make completing a dependency analysis easy (e.g., Microsoft Project) make a Gantt chart by default. I ignore the Gantt chart, though, and just work with the listing of tasks to keep track of my dependencies. This could be a matter of personal preference. I haven’t given this aspect of how I manage projects much thought.

I have thought a lot about two mapping techniques I do use: decision tree diagrams and Kanban boards. I use these both quite a bit, and even sometimes use them together. I think the easiest way to understand when each of these methods is likely to be helpful is by example. Since I am a bioscientist by training, I’m going to use a bioscience research example, but I’ll also try to articulate the underlying principles so that people working in different fields can apply these techniques.

Let’s take as an example a research project in which a group is trying to understand the function of a protein they’ve recently identified. There are all sorts of questions to answer. With what other proteins does this protein interact? Where is it found in the cell? Does it have any post-translational modifications? And so on and so on. Furthermore, the answers to some questions will produce more questions- and the specific questions produced will be different depending on the answer to the first question. For instance, if the answer to “where is it found in the cell?” is “in the nucleus,” it is reasonable to wonder if it interacts directly with DNA.

This profusion of questions can be a bit overwhelming, and the project leader should ideally bring some order to the situation by prioritizing them. Also, there may be decisions to make about whether or not to continue to pursue the project. I am most familiar with these decisions in a corporate setting: for instance, if the work is being done in support of drug discovery and the new protein is found to act via protein-protein interactions, some companies will discontinue the project. I suspect there are similar decision points in academia based around the likelihood of getting grants renewed and the like.

One way to organize this part of the project is to draw a decision tree. This is exactly what it sounds like: you write down a branching tree of questions, and indicate where decisions will be made. Here is an example:

Note this is just an invented example. The purpose is to give you an idea of what a decision tree is, not to show you actual decisions. Also note that in many real projects, there are parallel tracks being pursued simultaneously. For instance, someone might be doing bioinformatics analyses to see whether they can suggest any hypotheses about protein function from other available data. Each track might have its own “drop” points, and these might terminate an entire project or just one line of research.

I strongly suspect that most successful project leaders have a decision tree like this for their project. However, it is usually only stored in their head. There are advantages of writing it down. Writing down the decision tree forces you to explicitly think through the questions, and this often uncovers perhaps unjustified preconceptions and suggests new, possibly better questions to ask. A written decision tree also makes the decision-making on the project more transparent, and that will both make it easier for other project members to contribute ideas and make them feel more invested in the project. It can also help more junior project members grow, because it will help them understand the direction of their work and the project as a whole.

Decision trees work really well for projects (or the parts of projects) with a lot of unknowns. People often argue that you can’t “manage” these sorts of projects at all, but I disagree. You can’t manage them in the same way as you manage a project that is proceeding through a series of steps that you can define ahead of time, but you can- and should!- manage them. Even exploratory expeditions should take the best map available. Sure, the people on the expedition will need to fill in a lot of details as they go, and may even correct large features, but it makes no sense not to try to use the information they have ahead of time to organize their explorations and avoid known pitfalls.

For some projects, you can create a fairly complete map ahead of time. For example, once the team has figured out how best to express and purify the protein in the example above, those steps can be repeated over and over again to produce the protein needed to supply other experiments. They will probably be continually refined as the people working on those steps get new ideas and try them out, but the overall process is now known.

This is a situation that is well-suited for a Kanban board. The project leader needs to keep any eye on the flow through the process steps, particularly if there are several projects using the same people to express and purify proteins.  I’ve written before about how to create a Kanban board, so I won’t belabor this point. For the purposes of this post, I just want to point out that Kanban boards work really well when you are repeating similar steps over and over- even if the details of those steps vary with the specific task at hand. Here is an example process flow for protein production:

Express -> QC on Expression -> Purify -> QC on Purification

Since Kanban boards are extremely helpful in managing competition for people’s time, you may want to use one for even the more research-y portions of your project. In principal, anything can be modeled on a Kanban board, because you can always have steps like “decide to do X, plan how to do X, do X.” I find that sort of high level board useful for my own personal to do list, but not so useful for project management. If you wanted to map the less well-defined downstream assay portion of the above decision tree onto a process flow, you might use something like this:

Research options -> Adapt or Design Assay ->Qualify Assay -> Run Experiment

Again, these are just invented examples, so don’t get hung up on any differences between the example process and what you would actually do.

As explained in the earlier post, once you’ve mapped your process, you can now track the progress of specific tasks or experiments. You can identify bottlenecks and make sure none of the process steps are getting so overloaded that the people completing them are at risk of starting to make stress-induced mistakes. However, note that the Kanban process flow doesn’t tell you which experiments to do next. Your decision tree can help do that, but ultimately the decision is up to the project team. There are many different ways to make those decisions, but I think this post is long enough, and I’ll leave discussing decision making techniques for a later post.