If I have to rescue a project, where do I start?

Today begins a new series of posts on rescuing a troubled project. It is written entirely by our friend and colleague, Bob Louton. Enjoy.

At some point in a project-management career, we can find ourselves assigned to rescue someone else’s project. More often, we need to rescue our own project. This article is the first in a series about rescuing someone else’s project. That said, you might find that the approach described is equally valuable when rescuing your own project.

For anyone who has joined the leadership team on a project that is already underway, there is a lot for you to do just to get up to speed. Much of what you need to know is not written down anywhere. A lot of what the team is doing, how they are doing it, and why they are doing it that way is not captured anywhere that is easy to absorb. Instead, it’s tribal knowledge. It is understanding you have to glean by osmosis while doing your job. This tribal knowledge includes consensus in interpreting requirements, subtleties in milestone acceptance criteria, deviations from established process, unofficial arrangements of how decisions are made, and informal channels of stakeholder communication—just to name a few.

But what if you join a project mid-schedule that is in trouble? Not only do you face the typical ramp up, you face a mountain of problems that seem to stand in the way of progressing to successful closure. It is common to find schedule problems, quality problems, costs overruns, staffing shortages, skill-mix problems, morale problems, breakdowns in people working well together, blame games, confusion over the current version of what is committed, deliverables that don’t match the expectations, and on and on. For some projects, you must also contend with a frustrated or angry paying customer or underperforming vendors.

The short version is that there is a host of problems to solve. Solving problems is expected of the new people on the scene. They are the new blood. They are expected to grab the bull by the horns and start producing results.

And finally, there you are, the new project manager. What kind of baggage are you bringing to the equation? You come with knowledge and experience. You come with your self-image, or at least the self-image you hope to project. You will find that some on the team are suspects that got the project in to a big mess. When joining a project with problems, some of us will follow the urge to point out what others should have done.

Forget what should have been. You need to work with what is. And whatever you do, don’t criticize your predecessors. In a leadership role, you must lead by example. You need the team to focus on the problems. When you criticize your predecessor, you actually give the team permission to whine and criticize each other.  

So there is a mountain of problems to deal with. The question is “where do you start?” I have observed two common pitfalls.

The first pitfall: People tend to jump onto the problems that look familiar or at least manageable.Wouldn’t it be nice to have some early successes you can point to? But is this really serving the stakeholders well? It serves you as one of the stakeholders. What about the others? The answer is not a categorical yes or no because it depends on the situation. And that’s the point. Never allow yourself to drift into a prioritization based on your comfort zone.Prioritize deliberately based on the most urgent needs of the business.

The second pitfall: Work on a comprehensive plan to address all the problems. There is value in getting a comprehensive inventory of the problems. I have found no value in developing a plan that includes them all. Your plan to rescue a project is a perfect application for progressive elaboration–meaning learning more about a project as you go along. Why? Because at this point, you can’t afford this much planning. One lone wolf can’t outflank a large herd without the help of a pack. The PM needs to prioritize the problems and work on the most important first, the second-most after that, and so on. You can’t solve world hunger, but you can select the worst humanitarian disasters and send food there. So you prioritize and work your way down the list.

In my career, I have found myself assigned to problem projects when they are already well along. Over time, I discovered a particular priority order for tackling the problems on a project that has been broadly applicable. This order has consistently served me well. There could be situations in which a different ordering is superior to the one I ended up with. To date, those counterexamples haven’t occurred for me. So, I would take my prioritization as anecdotal but definitely grounded in first-hand experience.

This series of articles will walk through my top 5 areas of prioritization when coming into a project rescue. I now use this as a template for troubleshooting and planning even if I’m rescuing my own mess. We will go through them in descending priority urgency.

I’ve encountered objections to my approach from various people. Some feel another ranking is better. Frankly, those conversations are interesting and educational. I welcome them. But for most of those objecting, they have confused relative importance with relative urgency.

If you have an infection from a splinter, you need to order the steps you take. The right answer is that you do a quick cleaning and then go immediately after the splinter to get it out. Other steps like disinfecting are also important but not as urgent. Once the splinter is out, then you can clean out the wound and consider taking antibiotics. To say it again, all these steps are equally important. They are not equally urgent. To me, it’s just common sense.

I want to emphasize that my approach does not conflict with the PMI way. Some might think I’m imposing something on the Project Management Body of Knowledge (PMBoK) because I’m asserting a priority among the various aspects of project management. Let’s be clear. I’m not saying that one aspect is more important than another. What I’m saying is that, when you are rescuing a project, some aspects are intrinsically more urgent than others.

Comments are closed.