Project Management in Academia 101: Managing your own project vs. Managing a lab

After discussing why you should care about Project Management (PM) in academia and that there are multiple PM techniques available, we can start getting down to business talking about possible applications. There is a big leap between managing an individual project and managing a lab. If you start using PM techniques early, it will make it easier to juggle managing multiple projects later, or just changing your role and transitioning into a different type of PM role in pharma or the private sector.

Managing Yourself

Let's start with managing your own project. If you have read the previous posts, you already should have some ideas on how to apply PM techniques to your daily work. If you haven't read them, click on the links above and come back in a bit.

If you are a student or postdoc, managing your project is one of the most difficult things you need to learn, often through trial and error. While PIs must have some elements of PM to hit all the deadlines necessary to submit papers, grants, and job applications for getting and keeping their jobs, most are not trained PMs and just expect you to figure stuff out like they did. Unless your boss is a total control freak that needs to double check everything, they will be ecstatic if you come up with a clear question and experimental plan (which includes deadlines for deliverables on their calendar). They will discuss ideas with you, then get off your back, tell you to ask for advice if you have any problems, and wait for the data to flow in. In some labs, especially in the US, the boss may just let you do whatever you want, and there you really need to know how to manage your time and experiments!

In the first post I outlined how to Initiate and Plan a project leading to a research paper and what are the necessary questions to ask yourself, but here I would like to delve a bit more in the mechanics of Executing and Monitoring. Because science is a recursive loop of experimenting, troubleshooting, and analyzing data leading to more experiments, the Agile PM approaches are a lot more adaptable as my guest blogger Duc Phan presented. Kanban, which is Duc's method of choice is a great place to start. Kanban meaning "card" in Japanese uses visual cues such as cards, diagrams or flowcharts to outline the project. Having tasks clearly ordered in "to be completed", "in process" and "done" is a great way to start and he discusses a great way to use the Trello software to do this here.

As you perform experiments, you need to think at two levels: 1) questions/hypotheses and 2) actual experiments. Anyone with some training can do tons of experiments, but one of the most important skills in science is to identify important questions and design the best experiments to answer them with appropriate controls. You will save yourself a lot of time and grief if you remain grounded in the big picture. So I recommend that you title cards with the question the experiments are going to answer, e.g. "What is the developmental expression profile of gene X?" "Does transcription factor Y repress activity of gene Z?". At the end you should have an image or a figure with data that answers the question, leading to other questions. Asana is another software that will allow you to organize experiments under specific headings. To get started you can also just print out an empty monthly calendar and plot out your month, or do a thorough job on Google Calendar in planning your weekly experiments. Blocking time for specific experiments and scheduling things around seminars, meeting and lectures, is one of the ways I figured out how to organize my day in grad school. What else can you do during that 2hr incubation?

This leads easily to a process we use in my lab to write papers which is also based on cards, but borrowed from screenwriting, which is storyboarding on index cards. Each piece of data/answer (graph or images) is pasted on an index card or printed out on a sheet of paper, then attached on a white board where we look at all the data to decide how to present the story. Experiments are rarely presented in chronological order in an article, and are often organized to fit a narrative. Some supporting data will end in the supplemental information and other data will need to be showcased in the first figure. Some data will be set aside because it may belong into a different paper. (Daily reminder on rigor: no data should be set aside because it contradicts the main hypothesis). By rearranging the cards in front of you, you will see how the data fits together in figures and where there are holes that need more work, leading to another round of traditional Plan/Execute/Monitor or agile Speculate/Explore/Adapt.

From Matt van dar Meer (U Waterloo)

Managing a lab

Once one moves into managing a lab, the requirements of the job often change dramatically. After the first few years time to do experiments declines, and you are balancing teaching, admin work, travel, writing grants and papers with tons of other random things you never thought could be part of your job. Deadlines come at you without interruption, and sometime without much warning. So there are two requirements now: managing your own job and managing everyone involved in the research which is people in the lab, collaborators and research administrators. I was reminded recently on Twitter that having a 5 year plan really comes in handy and I wrote about it a while ago. Briefly, plot out month by month your next 5 years: conferences, grant deadlines, desired paper submission deadlines, beginning/end of grants with progress reports, and everything else you need to get to the next level.

Then, your management style really depends on you and on your lab culture. In general, as a new investigator you will almost never be able to get postdocs that were just like you, so you will have to also budget substantial amounts of time for training and budget time for trainees to learn how to think on their own. While you may need to be patient at the beginning when you just want to tell them what to do and they ask for your opinion on everything, teaching to trust themselves and develop their own ideas, will pay you back in spades in the future when they decide to ignore you for a month because they need to get s--t done. As an advanced PM, it will be really up to you to move between traditional sequential Waterfall methods and recursive Agile methods depending on the project that needs to be completed and the stage it is at. One simple approach may be to have a separate project outline for each grant and then one for each manuscript that would fit into it.

I want to spend some time talking about Scrum. Scrum is a PM method that combines both traditional and agile concepts to get a project done in small parcels. The advantage is that there are both a long term goal, but also short term goals that give the group continuous sense of accomplishment. Each task is completed within a 2-4 week sprint which is managed sequentially like a traditional project. I find this particularly suitable when you rapidly need to generate preliminary data or when finishing a paper, because it adds a sense of urgency and focus. Responsibilities are divided between the Project Owner, Scrum Master, and Team. The Project Owner inititates and plans the project, but the Scrum Master is in charge of the sprints and of getting the Team going. You can easily imaging your Scrum Master to be a senior grad student or postdoc. I'm still working on really understanding how to adapt Scrum to the lab, but here is a nice little guide that can get you thinking.

Overall, having a plan and a general sense of whether the "lab machine" is humming or stalled will hopefully reduce your stress level and free time for other things you need to do as a leader, including going on vacation.

Project Management for Academia 101: an Introduction to Traditional Project Management and Agile Project Management

Guest post from Duc Phan, University of California, Irvine

I am currently a PhD candidate in biomedical sciences. I developed a keen interest in project management (PM) while working on my thesis project and have been an advocate for teaching/learning PM in academia. I’m planning to become certified as a project manager after I defend. These are some ideas that stemmed from my readings about PM.  

“What is a project?” 

“A project is a temporary endeavor with a beginning and an end and it must be used to create a unique product, service or result.” 

“Temporary” and “unique” are 2 important concepts here that affect how a project is managed. A project is temporary because it does not run forever, but has a beginning and an end. It is unique because it is not a routine work but set out to accomplish some specific goals. Once these goals are achieved, the project is completed. These 2 concepts are kind of confusing in academia, because we rarely think this way. We do our research, and we follow where the results lead. We keep chasing the lead, get excited about it, and tend to forget about everything else. We blur the line between a project and an operation (i.e. a routine thing), which makes it harder to manage. It just feels like a never-ending run, and everything is chaotic. 

If we think a project is temporary and unique such as one manuscript or an aim in a grant proposal, we will approach it differently. Because it is unique with specific goals, we need to define the scope, the outcomes, and the benchmark criteria (i.e. milestones). With that in mind, we can look at resources (i.e. budget) in hand to meet these requirements. And because a project has a beginning and an end, we need to plan a timeline accordingly. 

Traditional project management vs. Agile project management:  

Each project is unique, so there is no one-size-fit-all approach. However, there are formalized systems (with knowledge, skills, and tools) that have been tried and tested by professionals in different industries. It is generally accepted that they fall into 2 groups: 

Traditional project management (TPM), as in its name, is the basic and traditional method to manage a project. It’s also called Waterfall Model (or Waterfall Project Management), because it is structured in a linear, sequential order. TPM system and methodology stemmed from the heavy industries (e.g. manufacturing, construction) in the mid 50-60’s of the 20^th century, and it is still a popular system today. 

TPM emphasizes on a clearly defined management plan to deliver project outcomes on-time and within a stringent budget. In the ideal TPM world, everything has to be planned out, documented, and followed according to the plan. As introduced in our first post, TPM breaks a project into 5 phases: Initiating, Planning, Executing, Monitoring/Controlling, and Closing. In TPM ideal world, one phase must be completed before the next phase can start (i.e. You can’t plan a project without initiating it, you can’t execute a project without planning it, so on and so forth). In addition, any changes during execution (scope creep, schedule change, budget change) must be reviewed and approved by higher level management and related parties.

Let’s translate TPM concept to academic research. A good example of a straightforward waterfall project could be generating preliminary data for a grant and writing the grant. 

You decide to write an R01 proposal for the NIH (Initiating). This entails outlining 5 years of research in a large project with 2-3 Specific Aims/Hypotheses. In the Planning phase, you outline your aims and define whether you have all preliminary data to support your hypotheses and feasibility. You gather your lab personnel and assign one or more pieces of missing data to each person, giving them a specific deadline. You sort out details with the grants office to define which documents are needed when and who is going to do what, including documents needed from collaborators. You outline the project budget for all groups involved. You have a set of tasks spread across multiple people each with deadlines. Your lab starts working on the project (Executing), you oversee the process (Monitoring/Controlling). In a real waterfall scenario, you start writing the grant when the necessary data is obtained (more Executing). In reality, it’s probably in parallel as the data starts coming in. You prepare all documents needed and your grants office checks them (more Monitoring/Controlling). The grant is completed and submitted by the NIH deadline (Closing). 

The strength of TPM (and its skills/tools/techniques) is to keep a project on track. With clearly defined objectives and milestones to hit, you are less likely to wander around and waste your time/resources. TPM can work for PIs or heads of a research group to have a global view of a project and its related aspects (scope, time, budget/cost, human resources, risk, stakeholders, etc.). However, the weakness of TPM is that it takes a lot of advance planning and it is not as flexible to changes, which happens so much and so fast while doing exploratory research. 

Let’s explore the other end of the spectrum.       

Agile project management, as its name suggests, focuses on rapid and adaptive management. Agile itself is rather a concept/strategy, and there are several management systems that fall under this banner, including Scrum, Kanban, Lean, to name a few (here and here). Agile began in the software development industry, but has since becoming popular and overshadowing TPM. The motivation behind Agile is that TPM is too bulky and slow, thus cannot keep up with rapid changes of a project, especially in digital age.  

Instead of breaking down a project into 5 sequential stages where one phase has to finish before the next one starts in TPM, Agile management de-emphasizes rigid management structure, strict timeline, and documentations. Instead, it splits the project into small work packages (or features) that can be independently addressed, and deliver each one as steps toward the final project objectives. The goal is to carve out these work packages so you don’t necessarily have to do them in sequential order, nor they are hard to change. Agile divides and conquers small work package according to level of priority, available resources in hand (manpower, expertise, budget, facility…), and feedback from stakeholders (project sponsor, higher management, public…). Each package has a specific deadline and deliverables so that overall working in short bursts increases the feeling of accomplishment in the group. 

That doesn’t mean Agile is unorganized. Agile still have a framework with 5 phases: Envision, Speculate, Explore, Adapt, and Close. The project will iterate through the Speculate, Explore, and Adapt phases until all objectives are reached. Results and feedbacks will be evaluated after each cycle.  

Let’s translate Agile concept to academic research with a moonshot idea:  

Drug development is too slow right now (Fact: It could go up to 10 years) and the pre-clinical screening process is ineffective (Fact: 9 of 10 drugs fail Phase 2 trials or after, and about 2/3 is due to efficacy and toxicity issues), so I want to develop a new drug screening platform. I set out 6 months for a pilot study.

I envision that if I have something more similar to a human body to screen compounds in lab. It will be better than testing with cells on a petri dish.  So how should this look like? 

I start to speculate the features for this new assay based on prior knowledge, educational guessing, and imagination. It should mimic human vital organ structures and functions to certain level. It should have blood vessel and flow because I want to look at systemic drug delivery. At the same time, I want it to be cheaper than animal models and easy to handle, so I can screen a good number of compounds in lab. I am an expert in a few things here, and I know some colleagues on campus who might be able to help me out. I will need expertise in bio-engineering, anatomy, physiology, pharmacology, and medicinal chemistry. Let’s gather everyone and cook up something!

We hold meetings and explore what it takes to get the features we sketched out. We come up with a list of experiments and their priorities. Some are doable within our expertise and in-house resources, while some are pretty challenging. But whatever, we will start doing stuff because it’s now or never. We decide what needs to be done to decide whether this is even feasible, divide the workload, and set out 4-week block for this round. 

After 4 weeks, we come up with the first iteration. It was much harder than we think, but we have something to test, and a list of issues/incomplete features. We start some testing to adapt our cooked-up Frankenstein to drug treatment. People mostly hate it (ouch, that hurts) but they give us a list of things they like/hate. We also realize that some original features that we thought are just overkilled and not practical. We repeat the Speculate-Explore-Adapt cycle again and again. 

After 6 months, we close the pilot study with version 6 of our Frankenstein and lessons learned. It’s obviously nowhere near what we envisioned, but we have come up with new ideas for developing different tissues in vitro and for promoting vascularization. 

As mentioned above, there are many Agile management systems like Scrum, Lean, Kanban, etc. Each has pros and cons depending on your project, but you can click here to explore the differences. 

My favorite is Kanban and it has been my go-to strategy. Kanban, "card" in Japanese, is a PM system implemented by Toyota in the 1950s, and has been widely adopted in the tech industry. The core of Kanban management strategy is using visual cues (i.e. cards) to keep track of tasks at different stages of a whole project. Kanban focuses on statuses rather than due dates to create a continuous workflow. I have written 2 blog posts on why I chose Kanban and how I use this method to manage my research project.

Recommended reading and resources:

The gold standard for TPM is the Project Management Body of Knowledge PMBOK Guide developed by the Project Management Institute (PMI).

PMI is the globally recognized organization that represents PM professionals and provides formal training/certification to project managers. It is not the only professional organization in the world, but it’s the most recognized, and its Project Management Professional (PMP) certification remains a standard for senior-level PM positions in the industry.

You can also read The Fast Forward MBA in Project Management (Fast Forward MBA Series) by Eric Verzuh and Agile Project Management: QuickStart Guide - The Simplified Beginners Guide To Agile Project Management (Agile Project Management, Agile Software Development, Agile Development, Scrum) by Ed Stark

5 years on the tenure track

Sometimes I wonder what made me think that April 1 was a good start date for my faculty job! But here it is, the April Fool's PI once again. I just completed year 5.

As customary in this occasion I go back to my past lab-birthday posts which reflect on the year that passed and on plans for the new year (Y1, Y2, Y3, Y4). The historical memory of this blog is one of the things I love the most (after my readers) because it give me prospective on my efforts and feelings. I am very glad that everything I put in place last year allowed me to survive this year. It was touch and go there for a minute, but the lab is good and back on its footing again. The new hires are great and after taking the time to get everyone up and going in 2017, things are moving along, papers are getting out and being published or in revision, we have cool new data, and we finally got our much needed R01 funding!

I have reflected a lot about what resilience means in academia during this process. The first month after getting the R01, when people were coming into my office to hug me or high-five me, I was stunned. I felt I had just come back from war. I was injured and psychologically devastated and there was no reason to cheer. A feeling I found so many of my friends who had been in the same boat shared. I don't know if it's true that the NIH throws you a bone at the very last second before drowning, but I have definitely heard of single-digit percentile R01s born out of extreme desperation.

Then a friend who is more senior mentioned that when you get your first R01 is when you realize you will survive, when you know that people trust you. And this is true. I still remember the joy of getting my very first grant as a postdoc, the sense of accomplishment and belonging "I can do this!" The disconnect in the past couple of years was that I knew I could do the job, but study sections didn't believe me, so I had to figure out how to convince them.

I feel like I am still recovering, but the outlook is a lot more optimistic. I made sure I had vacations planned to clear my head in case of both good or bad outcomes, and I'm ready to get back in the ring. This year I want to close this first chapter and really think about the future and what I can do with this lab now that there is some security for the next 5 years. There are still 2 more R01s in the pipeline...and I want to recapture the wonder and excitement I had on Day 1 of my faculty job.
I can also spend more time to focus on my other passion which is professional development for young scientists. After the Project Management series is done there will be more things in the pipeline.