Project Disasters and Career Management

“My project’s going down the tubes. How do I keep them from making me the scapegoat?”

- RN, Washington, DC

There’s an old joke about the stages in a project life cycle. First comes enthusiasm, then disillusionment, followed quickly by panic. Then comes the search for the guilty, resulting in punishment for the innocent, praise for non-participants, and when everyone sees what a disaster it’s been comes the final stage: figuring out what we should have been doing in the first place.

By the time the project’s in trouble, it’s usually too late to do much about it. That’s why project managers know the real secret is to keep your project out of trouble in the first place. It doesn’t matter whether the problems are actually your fault; it matters whether you could possibly have prevented it, fixed it, or managed it. That’s called risk management, a forward-looking approach to project uncertainties. What could go wrong? Why could it go wrong? And what can you do to prevent the problem or deal with it if it occurs?

A risk management plan can be a huge, formal document or it can be comparatively casual, but either way, you need one. Start with risk identification, a list of potential issues. You can brainstorm with your team, you can ask people who’ve done similar projects, and you can review the documentation (requirements, contracts, statements of work). Prioritize the risks by how serious they are, and take some time to dig into the bigger ones.

There are basically five things you can do about a risk, and your job is to pick the best choice. For example, if you’re the owner or captain of RMS Titanic, and you know there are icebergs in the North Atlantic, you can do the following:

1. Avoid the risk. Change the course far enough to the south, and there are no icebergs. Of course, the trip will take longer.
2. Transfer the risk. Buy insurance so that someone else will pick up the bill in the event of sinking.
3. Mitigate the risk. Mitigation reduces a risk without getting rid of it altogether. For example, the British inquiry into the sinking concluded that the Titanic was going too fast. It might have hit an iceberg anyway, but a slower collision might have reduced the damage. 
4. Have a contingency plan. More lifeboats (the Titanic only had enough for about a third of its passengers and crew) wouldn’t have prevented the sinking, but would have reduced loss of life.
5. Accept the risk. Some risks you just have to deal with. If you’ve done everything that seems practical and appropriate, risk isn’t exactly zero. The remaining risk is something you simply accept. Save the rich and leave the poor in steerage.

Risk management is something you do in advance. Once the Titanic hits the iceberg, the game changes from risk management to problem solving. There, unfortunately, the options tend to be dramatically reduced.

What if the project appears to be impossible? People say “nothing’s impossible,” but that’s if you have unlimited time, unlimited resources, and really flexible standards. Are the constraints on the project (time, cost, expected performance) too tight? Is that because of a management decision, or are the constraints imposed by external circumstances? Management decisions may change, but if the money isn’t there or the deadline is unstoppable, management may have no more power than you do.

If a project is impossible as contemplated, that doesn’t mean it’s impossible period. Maybe you can do something different, or do it in a different way. Look for flexibility and opportunity wherever it may be found. If you can’t do everything they’re asking for, perhaps there’s a “good enough” level that meets the objective.

In the aftermath of a big project disaster, there may be some kind of investigation, and if you’re in charge, it’s perfectly reasonable that people will look at you. That doesn’t automatically mean that scapegoating is taking place. Yes, there’s usually blame to go around, and it may be appropriate and fair for you to own a piece of it. Sometimes it’s good strategy to accept your share of any blame early. And, to be perfectly fair, if you’re in charge of the project, you normally deserve at least some share of both credit and blame.

When scapegoating actually occurs, it’s normally an attempt to deflect responsibility from someone higher in the management food chain onto a more vulnerable target: you, for example. And again, you normally have ample warning if you’re paying attention. That person’s goal, remember, isn’t to scapegoat you, it’s to avoid getting himself or herself in hot water. If you can keep that person out of trouble without getting yourself hurt, that may be a win/win. (Don’t yield to the temptation to deflect the trouble onto someone still lower on the food chain, unless that’s the person who’s actually responsible. It’s not only immoral, but other people will notice and your reputation will suffer.)

If everything else fails, advance notice gives you one more opportunity. There’s an old management joke about an outgoing project manager who had some words of wisdom for the incoming one. “I’ve left you three envelopes in my desk drawer, and they have the answers to the first three crises you hit,” the outgoing PM said.

The answer to the first problem was “Blame your predecessor.” To the second, it was “Reorganize the team.” And to the third, it was “Prepare three envelopes.”

Sometimes you have to know how to get while the getting is still good.