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