If you haven’t already I recommend you read the first part before continuing with this article further. In the last article, an idea for non-linear project management was introduced. Looking at the image below, we can see that the R&D project workflow looks a lot like a version control tree mostly used for software development projects. Since Git is the most popular solution for version control, I will refer to it in the text as just – Git. In this article, we will take a look at which Git concepts could be used as research project management principles.

We should not give up tickets

Every curve looks like a straight line if you zoom close enough

Before discussing which parts of standard project management are not optimal for research, let’s talk about the ones that work. Even though the workflow of a research and development project is not linear, one unit of time (a week or a sprint) is. Kanban and to-do lists are very intuitive for a short-term focus. The first thing most of us do when presented with a task is to write a list on a blank sheet paper or a digital document. The problem lies with the bigger picture where those tickets do not represent a real situation of the project flow. 

Ticketing systems are excellent for short term progress tracking but lose value on marathon projects. Ideally, just by using a standard ticketing system with a couple of additional tags, a Git tree should be generated automatically.

Branches

Typical Git workflow has one main branch called the master branch, but this might be the only concept that cannot be directly copied. There is no possibility for a single main branch if there is more than one topic in the project. Project branches should be used for different topics and they will probably never merge. There is one exception discussed in the next paragraph.

Not every dead-end is a loss

Deciding when to close a branch requires a topic on its own. It might be possible to say that an idea is never a dead end and an implementation will come eventually. But a dead-end in one branch could be a solution in another and this is a great breakthrough that should be documented. We propose something like this:

This is a rare case where Git-merge might happen. An alternative solution could be cherry-pick, if we wish to keep the branches separated at any cost. 

Other stuff

I’m sure we all suffered from a tunnel vision where we focused too much on a problem and ignored everything else that could have helped. Imagine a situation where you’re working on a problem that after changing some minor details requires 30 minutes of testing, and you’re aware that the procedure could be significantly optimized. I personally had that kind of situation and at that moment optimization didn’t seem like a rational solution. It would be very interesting to track the amount of the time invested in “other” tasks and their influence on the project performance. My gut tells me that those investments lead to a significant speed-up of the findings.

If the mentioned test could be optimized to one minute, that would mean 30 times more tests. Just last week I received an IM from my employee telling me he sped up the test algorithm 85 times. Initial versions are often hasty written (as they should be) in order to test a concept. But a balance between optimization of an idea that has will fail nine out of ten times and using the first draft for the next three months needs to be found.

In the PM tools, there should be a reward system that would let you know when you’ve “earned” the other stuff time e.g. for every nine days of work on the core problem, you receive one day for optimization. The relationship between the time invested and the benchmark curve would be something interesting to see.

Benchmark timeline

As already mentioned in the previous article, having a benchmark keeps us on track and motivated. Connecting the Git-tree with benchmarks could also give us the idea which branches worked, and which didn’t. At this stage, it is hard to tell exactly which benefits this would offer to the project manager, but I’m sure this will be clearer later.

Conclusion

Looking at the big picture, the R&D project has plenty of similarities with Git-structure and there are plenty of concepts that could be replicated. I would like to hear your experiences from managing or being part of research projects. Feel free to contact me with your opinion.