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:
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?