Picking Up a Project Mid-Stream

I was recently asked to take over the management of a project that was already running.  This wasn’t a rescue mission- the project wasn’t failing, exactly, but it wasn’t finishing on time, either. The original project manager needed to move on and therefore I was asked to step in. I decided to take the opportunity to try to really notice what I do as a project manager when picking up an in flight project.

I’ve done this many, many times before, but I couldn’t have written a set of “how to” instructions. There is a big difference between being able to do something- even at an expert level- and being able to explain how to do it. Discussions of this discrepancy between knowing how to do and knowing how to teach something and ideas for how to do a better job teaching novices about technical topics are some of the many, many things I got from following Kathy Sierra as Seriouspony on Twitter, and are some of the many, many reasons I am so sad and angry that she has had to leave.

Inspired by Sierra’s observations, I paid attention more attention to what I was doing this time, and kept notes. Here are my observations about how to successfully pick up a project that is already underway.

The very first thing to do is clarify the goals of the project. It is fairly common for goals to become muddied as a project is running, so don’t be surprised if different people tell you different goals. Identify the key stakeholders- i.e., the people who have caused this project to be started and who will determine whether or not it is considered successful- and talk to them to figure out what the true goals are. Then make sure to communicate these goals to anyone who told you different ones.

Once you have clarity on the goals, you need to identify the key risks to achieving them. This is an area I need to pay more attention to during future projects, because I still cannot really describe how to identify risks. My process was something like this: talk to the people involved in the project and get an accurate sense of the status of all the work underway and an understanding of what has been done to date, then (magic happens and) the risks are clear. I truly wish I could explain the “magic happens” part, but right now all I can say is that based on my years of experience running similar projects, the risks were obvious to me. Perhaps the best advice is to just get in touch with your inner worrywart and think about all the things that could go wrong.

The next step is to figure out which risks to mitigate and how to mitigate them. A lot of project management methods talk about classifying risks by likelihood and severity, and focusing on those that are most likely and/or the most severe. I do something similar, but I think there is some “magic happens” in this step, too, because I don’t strictly adhere to this method of deciding which risks to mitigate. I generally consider all the risks I’ve identified and think about likelihood, severity, and costs of mitigation, and decide from that which need mitigation. If an unlikely risk is easy and cheap to mitigate, I’ll probably go ahead and mitigate it, even while deciding not to mitigate a more likely risk that has a more costly potential mitigation.

Often, mitigating risks just means tackling those parts of the project earlier, so that you have more time to deal with things going pear-shaped. In other cases, you can mitigate a risk by scheduling in an extra practice run for a tricky procedure, by getting advice from someone who’s done something similar, or by having a back up plan (or two). The ways to mitigate risks are as varied as the risks themselves, but it is almost always easier to do the mitigation if you have more time. This is why it is so useful to identify your risks as early as you can.

Only after I had a good sense of the major risks on the project did I sit down and sketch out a plan for completing the project. At this point, taking over a project is not that different from starting a new one. There is a list of tasks that need to get completed, and there are dependencies among the tasks. There is a time constraint from the stakeholders, which may or may not be a hard deadline. There is a budget. You have a team identified, and some idea of what they can to do. You mix all of those things together and produce a plan. There is probably still some “and then magic happens” in my understanding of how to create a project plan, but I do have some concrete ideas about how to accomplish this step. They are probably best saved for a future post, though, when I can focus solely on the various methods for creating a plan for your project.

The project I picked up is still mid-stream. I won’t lie and report completely smooth sailing- one of the risks I identified and chose not to mitigate came to fruition and caused some drama. Lessons were learned, and the project continues, though, and sometimes, that’s the best you can do.

Have you ever picked up a project in flight? If so, tell me how you did it in the comments!