In my last post, I explained how my funding source (and therefore my job description) has changed in the last couple of months, specifically to include more project management. Still undecided about pursuing formal PM training and qualifications, I’m currently trying to adopt the optimal combination of best practices from my prior experiences to apply to each of several projects.
AKA, winging it.
As I mentioned last time, I’d love to hear your thoughts and experiences (more best practices to adopt!)
Stand up and be counted – the industry experience
The senior managers at my last job were sent on training courses once or twice a year, coming back with the latest and trendiest management speak (ducks in a row, push-back, etc.) They also brought back the latest and trendiest management practices, some of which actually turned out to be useful, if sometimes rather painful. One such example was the stand-up meeting.
Unpopular due to their 8.45 am start time and compulsory attendance, stand-up meetings were a daily get-together of at least one representative from every department involved in a specific project. The meetings only lasted fifteen minutes (in theory), and everyone except the scribe stayed on their feet, to discourage idle chit-chat and other agenda killers. We’d go around the room, and each person would describe progress towards their team’s goals, as well as any problems they’d encountered. These problems could often be solved on the spot by a representative from another department, and if not, an action item would be written into a designated lab book along with the name of the person responsible and the target date. Once everyone had given their update, the scribe would read out all outstanding action items, and the person responsible would report on their progress (or excuses). The meetings kept everyone informed and on their toes, and really were enormously helpful when we were pushing towards a specific product launch date or other large-scale initiative.
Sit down and be grumpy – adapting industry practices to academia
I decided that the stand-up meeting format would be a good fit for one of my biggest projects. Actually comprising several sub-projects, the work is being done in collaboration with a corporate partner. We have well-defined milestones to hit, and a formal system of scientific and financial reports. Several people are involved at our end, including molecular biologists, a pathologist, a statistician, a team of bioinformaticians, and (from this week onwards) a new lab-based project manager. We all get together with our partner’s team two or three times a year, and people have regular teleconferences set up for some of the sub-projects. As is common in research, however, most people have an excellent grasp of the details of their own projects, but don’t always see the interconnections evident in the big picture (this will a topic of a future post that I’ve been drafting in my head for months). For example, hits from a screening project drop into the pipeline for several other projects; the statistician works on data generated by the pathologist and the bioinformaticians; the statistical results inform refinements of the screens; etc.
This lack of cohesion became clear when I had to submit our first quarterly report; I had to get everyone’s updates individually (involving lots of reminder emails, phone calls, and lurking at people’s desks for them to get back from the lab), and then turn them into a report that covered everything in an integrated way. It wasn’t easy, and I had to go back to some people several times to ask follow-up questions that they couldn’t always answer (“no, I don’t work on the validation, just the screen. No, I don’t know who’s doing the validation”), but I got it done on time, and ended up with a much better grasp of where the gaps lay and the best way to fill them.
So, a few months ago, I described the stand-up meeting format to my boss. He loved the idea, and agreed that it would be a good fit for this project.
In my last job, many of the team’s tasks were doable in a day or two – complete a piece of documentation, repeat one experiment, contact three beta testers for feedback, proofread the manual, etc. This is why a daily meeting made sense; you could usually report real progress in that time-frame. However, daily meetings wouldn’t have made any sense for a purely lab-based project. So I started us off on a weekly schedule, for half an hour at a time. After a few meetings in a row of “well I haven’t got the data back on that project yet”, I switched to biweekly meetings. A fortnight is not a long time in science!
The 8.30am on Mondays scheduling was grossly unpopular with everyone except my boss and me. I’d thought back to my own days in the lab, when mid-day meetings would disrupt experiments and end-of-day meetings excluded some parents and other people who had to leave early, and was surprised at the backlash. Even after I explained my reasoning, there was much grumbling for the first few weeks – partially placated when I bribed everyone with brownies.
And this is the biggest hurdle to adopting corporate practices in academia: people just aren’t used to it. What was just one more meeting to add to the list in my last job is A Big Deal for postdocs with only one other meeting in their weekly schedule, and no prior knowledge of these alien things called action items. The more relaxed atmosphere of academia (which I mostly love, by the way. Mostly), also sees people regularly showing up late, so what is supposed to be a team meeting sometimes turns into a series of one-on-one interviews between me and whoever’s just showed up. (We’ve also taken to sitting down instead of standing. The room we use has way too many comfy chairs in it for people to resist at that (apparently) ungodly time of the morning. This really doesn’t make any difference, however).
Even in the series-of-one-on-one-interviews format, though, the meetings have been extremely helpful to me, if perhaps less helpful to the other participants than if they were all to show up at once. I type, distribute, and archive each meeting’s minutes, and used them to write the last quarterly progress report in a tiny fraction of the time it took me at my first attempt (the ctrl, c, and v buttons on my keyboard are in danger of wearing out, but it’s a small price to pay). I’ve also been able to answer the frequent questions I get from my boss, other team members, and our collaborators much more easily and quickly than before, and our accountant has found the information very useful too.
Overall, this experience can be written into the “Success!” column. The problems we’ve had are primarily a function of the department’s culture, which is not as collegial as some others I’ve experienced, and those things don’t change overnight. But as people get used to the format, and as personnel rotate out of the lab and new hires are told “this is the way we manage this project”, things are already improving.
I have the support of my boss, his accountant, admin manager, and lab manager, and I can always buy more brownies if I need to.
