Monday, February 11, 2013

Project Planning 101

I've run into several people lately who have told me that you can't make a project plan for a research project. This always amuses me, because I've made lots of project plans for research projects, and found them to be very useful. In fact, one of my pipe dream job ideas is to go around helping people figure out how to write useful project plans for their research projects. (You can tell it is a pipe dream because I am writing about it here, under a pseudonym, rather than starting up a "professional blog" and trying to turn myself into a project management guru. Given the number of people who confidently tell me that it is impossible to make a project plan for a research project, I don't think this would be a very lucrative line of work, so I'll leave it in the pipe dream bucket. I'm not big on tilting against windmills.)

There might be a few people out there who are open to the idea, though, so I thought I'd write a blog post about how to write a useful project plan for a research project. Then I realized I'd want to reference a lot of basic concepts about project planning that I have never discussed here. Therefore, instead of the post that might actually interest some of you, I'm writing a post about the basics of project planning. Consider it a down payment on the interesting post.

First of all, we need to discuss what makes a project plan useful. To me, a useful project plan is one that helps you get more work done faster, without burning your project team to crispy toast in the process. It also produces credible timelines that you can communicate to other people interested in your project ("stakeholders" in the jargon- this could be upper management or a funding agency, for instance). Note the emphasis on credible- we don't want to just pull milestone dates out of thin air. We want dates we actually have some chance of coming close to hitting.

Given that definition, you can probably guess why I think research projects are plannable. I think almost everything is plannable. Basically, if I want to get it done and don't want it to consume my life while I am doing it, I make a plan for it. The exception may be parenting, but given the lists and calendars I keep around parenting, I'm not even sure that is an exception. I'll have to think about that.

A good project plan lets team members plan their time better. It reduces the "dead time" when one team member is waiting for another team member to finish a task. And it helps the entire team avoid those horrible moments when you realize you've forgotten to do something essential and you are all now doomed.

So, without further ado, here is my basic workflow for developing a project plan, in seven steps. I won't pretend they are always easy, but a lot of things that are worth doing aren't easy.

Step 1: Determine the overall goal of the project. 
When will you call this project "done"? I aim for projects that will run for 3-6 months, although I have occasionally written plans for year long projects. I think that detailed plans get less and less useful as they reach further into the future, though.

If my true overall goal will take longer than ~6 months to accomplish, I subdivide it and work on a plan for the first subgoal. Sometimes, figuring out how to break the work into 6 month chunks is a major planning undertaking in its own right, and I will end up with a high level plan showing the big subgoals as well as detailed plans for each subgoal.

An example might make this more clear. I recently needed to roll out a new intranet site. I broke this into three projects: (1) an administrative site with things like travel expense forms and human resources information, (2) an exemplar departmental site, with other departmental sites to come later as departments requested them, and (3) project sites.

My overall plan looked like this:
I planned the first two projects (the administrative site and the exemplar departmental site) out in detail, and left the project to create project site nebulous until the first project finished.

Only you can define what your overall goal is, and if you can't define your overall goal you should probably stop and fix that problem before you do anything else.

Step 2: Break the goal down into tasks
There is more than a little art to getting the right level of detail on the tasks. If they are too broad, the plan won't really help you much. If they are too detailed, you'll spend way too much time tweaking the timelines in your plan. There is no magic formula I can give you for this- you'll just have to try and see what works best for you and the type of projects you run.

Remember, though, that the plan is not necessarily your only project management tool. For instance, for most of my software development projects, the plan shows the length of the development iterations ("sprints" in the agile development jargon), how many iterations we'll do in a given project, and the testing, training, and other release steps for each iteration. It doesn't, however, list the specific features we'll develop. Those are tracked in our bug tracking software.

Step 3: Note the dependencies between tasks
Put your list of tasks in rough chronological order, and then start noting which tasks must be completed before the next task can begin. An example of this type of dependency is the protein production and purification cascade- you can't purify protein until you've created the biomass, and you can't create the biomass until you've created the clone, etc., etc. Also look for tasks that can start before the predecessor task finishes, but can't finish before it does. An example of this type of dependency is the fact that training plans can (and probably should) be started before software development completes, but they usually can't be considered complete until the code is at least feature-complete.

Do not, under any circumstances, be tempted to skip this step. I personally find the dependency analysis to be the most valuable part of the planning process. Managing dependencies is in fact the entire reason I continue to use Microsoft Project, even though no one else in my company looks at my MS Project files. (You don't have to use MS Project to manage your dependencies, though. There are other tools to manage dependencies- I'm just too lazy to learn them, since Project is working fine for me.)

Step 4: Assign people to tasks
Who will do the work? If you don't have names, just list roles. But try to get names. There is no generic "scientist" or "developer" who is going to show up and start working on your project. You're going to need an actual person, with a name. And if you don't know who that person is, that's a major risk to your project and one that I would start trying to resolve right away.

Step 5: Add the durations to your tasks
How long will each task take to complete? You can get super fancy here, and try to have your tool help you determine this based on the other tasks assigned to the people doing the work, but I find that to be more trouble than it is worth. I just make an estimate based on how long I think the task should take (or how long the person doing the work tells me it will take) and how many other things that person is working on.

Note that the durations are always estimates. They will be wrong. The goal isn't to get them exactly right, it is to get them in the right ballpark. Since you took the time to figure out the dependencies in your project, you will be able to tell when you need to really fight a slip and when you can just let a task slip because it won't make much difference to the overall timeline.

Also, this is one aspect of project planning that definitely gets easier with practice. The durations in my early project plans were laughably wrong. Now I can get them so close to right that it sometimes frightens me.

Step 6: Add some risk reserve
Things go wrong. Schedules slip. So add in some time to account for the inevitable problems before you communicate your plan to others.

How much risk reserve to add will depend on who cares about your timelines, how much they care, and the relative cost of missing a milestone versus making a too laid back plan. Again, there is quite a bit of art in this, and it gets easier with practice.

Step 7: Discuss the plan with others and iterate
Everyone on your team should have a chance to tell you that it will be impossible to hit your milestones. You don't necessarily have to incorporate their feedback into your plan, but you should listen to their concerns and make a conscious decision about whether or not to add more time. Your team members can also help you identify missing tasks or forgotten dependencies. I have never, ever, ever written a plan and had it be completely correct in the first iteration. It is worth the time and effort to improve the plan up front so that you will spend less time at panic stations later in the project.

And that's it! That's what I do when I need to plan out a new project. Anyone have any questions? Any project managers out there want to tell me what they do differently?


  1. Anonymous5:22 AM

    I do these things with my research projects. :)

    The problem is that I have yet to be able to find a coauthor who works well with our agreed upon plan, no matter what said plan is. I have one who just puts things off and eventually puts things down. I have another who enjoys making me do the hurry up and wait thing. And so on.

    Which is probably why I have so many single-authored papers. I may be good at managing project, but not people, or at least not people at the same organizational level I'm at. (I've had some success with RAs.)

    1. Ah, yes. This is an eternal problem of project management. It is probably somewhat better in industry, where you can always try appealing to someone's boss. But if you use that option too much you will soon be completely ineffective and will almost certainly not advance. So basically, you spend a lot of time reminding people to do their jobs. Very frustrating.

    2. Anonymous8:17 AM

      As a grown-up with a job, when I watch Perry Mason I think how awesome it would be to always work with people who are organized and competent.

    3. "you spend a lot of time reminding people to do their jobs."

      We're in very different fields, but I can relate. One of the most effective (but high-pressure) work environments I was ever in was one where they had teams arranged in open floor plans in clusters, so nobody's computer screen was ever private, and you could talk to each other easily no matter what level they were. IIRC, some management consultancy like McKinsey or BGC recommended it, even though we all hated it (especially the senior people who lost their cush private offices), I have to admit it worked. I felt like physically bringing everyone out in the open to face each other made it so nobody was able to slack/hide and ignore the reminders to do the work.

    4. I do similar steps when I write my books, but yes, it's only dependent on me (and maybe one other person on occasion), which makes things much easier. I might screw up or miss a deadline, but the loathing and recrimination are then all internal.

  2. I attempt to organize my projects; when you write a proposal you need to show a timeline similar to what you have on the graph above (usually I give it as a table of task versus months). But, working with students, you can't have too detailed of a plan because they slack off or have classes/exams or often both, and things get delayed... So these plans are only rough estimates with students.

    With collaborators? It's impossible. Everyone has their own timeline and there is a lot of waiting involved for someone to get some free time from other crap to get back to the project. My priority is not another faculty's and I have no carrot or stick over them. So I sigh and wait a lot (while doing other stuff in the meantime). In academia, everything takes much longer than necessary, but such is life when you can't really sack people or offer them money (or any other incentive) for doing well.

    1. If you could teach your students to be able to estimate the impact of classes and exams on the amount of lab work they can expect to get done, that would be doing them a HUGE favor... but I know that they aren't necessarily the all that willing to learn this skill.

      My priority is not my colleague's priority, either. We do theoretically all work towards a common goal, but sometimes I doubt even that! Maybe I should do a post about the tricks I use to try to get less than cooperative colleagues to do what I need for my projects. But I'm not sure I could do that topic justice and stick to my rules about what work things I'll blog about. I'll have to think about it.

    2. Maybe I should do a post about the tricks I use to try to get less than cooperative colleagues to do what I need for my projects.

      Yes, yes, please! Mind control FTW!

    3. I'll think about it- I need to think carefully to see if I can blog about some of my methods without saying more than I should about my work (and some of my colleagues). So it may take awhile, but I'll write a post if I can think of a good way to do it.

  3. Anonymous12:40 PM

    Do you have any suggestion for a basic software that you can use to keep track of your plan? Or do you stick with paper and pen or just text files?

    1. I use MS Project, but that costs several hundred dollars. Back when I did a project plan for my wedding (yes, I did a project plan for my wedding) I used OpenProject and found that to have the basic functionality I needed.

      I like to use specialty project management software for the help in tracking dependencies and using them to automatically cascade schedule slips. But you could make do with Excel or a table in a word processing program or just pen and paper.

  4. Normally, I just lurk, but (as part of my New Year's resolutions: Part February) I've decided to start commenting on blogs I like and overcoming my (irrational) anxiety about posting.

    Anyhow, this was really interesting for me. I'm a postdoc and I'm trying my hand at managing two underlings (undergrads) along with my own work/anything that's dumped on me by my advisor. I've been doing a lot of your steps, but the problem I run into is when something unexpected happens (freezer fails, Advisor decides to have me edit a ~200 page journal issue, etc.). Maybe I just need to add more "risk reserve"?

    Anyhow, I'm interested in reading the rest of the series!

    1. Thanks for commenting!

      Remember, the point of the timeline isn't to be 100% right (particularly in your situation, where there aren't huge penalties for slips), it is to help you manage your project and balance competing demands. So, you could say to your adviser: sure I can edit that journal issue, but it will make XYZ run 2 weeks late.

      There's not much you can do about a freezer failing- you have to just deal with it. So you are right, that is a classic reason to have a risk reserve in your timeline. Or you just slip the schedule. In practice, risk reserves are most important on projects that have a high penalty for schedule slips- for instance, in contracting, sometimes you make a "fixed price" bid, which is saying you will deliver something for a given price, no matter what. When you are estimating the price (which includes labor costs), you put in a hefty risk reserve because otherwise you might end up losing money on the project.

  5. For your readers that may not wish to (or do not own) Microsoft Project but have access to Microsoft Excel, I humbly offer a freely downloadable Excel Project Planning template on my blog. Initially, I struggled with creating project plans using various tools… and realized that sharing project communication was difficult if members and stakeholders didn't own MS Project. Then I created a microsoft excel project planning template that incorporates a visual project Gantt. The template is available for download at no charge at

  6. This comment has been removed by the author.


Sorry for the CAPTCHA, folks. The spammers were stealing too much of my time.