Pilot Experiments (part 2)

July 2, 2012 - 8 minutes read

o in light of the topic of my last post, I think that this post needs to reflect a more direct improvement on my ideas and strategies as it pertains to the pursuit of managing scientific discoveries. I just read it over and it seemed a little too abstract and has really no useful information that can be processed by others. 

I thought to just delete it or to edit it, but that would kind of defeat the purpose of my theme of pilot experiments. Instead, I’m keeping to my ideology. I hope that this will serve to illustrate growth and improvement with each successive post.

I named this current posting “part 2” because I hope to try to express the thesis (or philosophy)  of my last post in a more clear and digestible way.  The information should be useful and thought provoking.  It shouldn’t leave you saying, “What the…?!!!”

Like I said before, this is my first few attempts at a blog.  I’m taking the theme of pilot experiments to try different approaches to communicate my understanding of managing research labs.  I believe managing scientific resources is critical to producing great discoveries. The way to approach the management of science is through a series of little experimental systems. For example; scheduling meetings every Tuesday at 9am, updating notes every morning before starting benchwork, reading 1 article a week, etc. Each one of these examples is a systematic series of events which can be tracked and measured.  It’s not much different than the current experimental systems we do at the bench, in our daily lives, or in every biological environment.

Managing is to take measurements on these repeatable events and to take action based on the trajectory of those measurements.  We start out with establishing ONE act in hopes of improving the work flow. If that one act works, then we repeat, if it works again, we repeat; again and again. Over time, we get to know what systems are best for improving scientific flow and which ones aren’t.  The trick is measuring them and deciding which ones to keep or which ones to abandon.  Again, the way to do that is by making a single actionable change and checking. Doing it again and again.

Over time, the system will build upon itself.  As it does, though, we have to remember that in order to manage the course of the science, we need to take baby steps to alter that course. To give you an example of a course change in management, I go back just a few years ago. We needed a drastic change in our budgeting system. We were running critically behind in our budgeted balance. The department didn’t really know how to change the system or to catch up. The solution I suggested was to introduce a new online requisitioning software. This wasn’t taken very well and there were resistance. I wasn’t surprised. Everybody hates change; even when its beneficial.  (Heres a great book I suggest you read on making changes in organizations.) We introduced the software one person at a time. We had a single research technician process what ever orders she requested into the system. We did this for about a couple of months. It was working! We were able to track orders and the system seemed to work.

The PIs were happy. So they wanted to implement this quickly across the board and make it happen with all of the labs, all at the same time. I told them, “Whoa! Stop! No way! Remember; baby steps.” That one tech was to serve as a pilot expriment before we could fully scale up.  We suggested adding another tech for a couple of weeks run to see if this could work in everyone’s hands. We saw that the system was good but we quickly realized that we needed better training. In the next week, we solved the training process. We then added another tech and a postdoc. We saw that postdocs were using the system differently and so we had to make more adjustments. Once we made those changes, we added another postdoc and another, then proceeded to add grad students. Then the system was working within a single lab. The operative word here is singleChanges can only happen sequentially. 

We decided to implement the system into another lab. The PIs wanted to mandate it with every one, but that wasn’t going over well. So we decided to implement the system in the same systematic way that we did with the previous lab, but with ONE difference. We sped up the integration time to be done in one month. Too fast! People weren’t understanding it. So we slowed it down to six weeks. The integration time was still able to be half that of the last lab. We did the process again with another lab but this time we decided to add another lab. So we were doing two labs at a time. This time we knew we had to have more trainers but we learned that not everyone trains the same way. So we decided to add training protocols to follow.

Overall the process took about 8 months, but the software integration into the department helped to solve the budgeting problems and translated into about a 20% annual budget savings.  The system has grown and is being integrated into a bunch of labs and universities since its pilot experiments. What I want you to take away from this story is the understanding that management is just a series of little experiments and the results that we base our actions off of.  Each pilot experiment is a baby step.

I hope that this post was a little clearer than my previous. I also, hope that this provided you with a little bit of information to help in your research quests. My last post may have been too abstract, but there’s some philosophy there to support my approach to management.  Let me know what you think. Comment below. Thanks for reading. I want to manage to make science easier.


Tags: , ,