Tuesday, October 18, 2011

Potentially Impossible (Managing Impossible Projects, Part 2)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. 

The Most Dangerous Word

At the outset of the project, you may not always know whether the project is possible or not. That’s why the process of managing an impossible — or potentially impossible — project begins at the outset, during the very first stages of project initiation.

Here’s one of Dobson’s Laws of Project Management: The most dangerous word in project management is a premature “yes.”

Premature certainty, whether it’s positive or negative, can backfire. Saying “yes” before you really know what you’ve said “yes” to can result in a world of trouble.

You can also get in a world of trouble by being too quick to say “no.” Even if your experience and wisdom tell you the project’s impossible on the face of it, saying so too quickly will produce a negative reaction. And, frankly, sometimes “no” is just not going to be an acceptable answer.

When you say, “Sorry, that’s impossible,” they think, “You didn’t even try!”

Failure, Alas, Is an Option 

Let’s set the Way-Bac machine for April 14, 1970, just about 56 hours into the flight of Apollo 13. With the spacecraft about 200,000 miles away from Earth, Mission Control asked the crew to turn on the hydrogen and oxygen tank stirring fans. About 93 seconds later there was a loud “bang.” Oxygen tank #2 had exploded.

If American Movie Classics ever ran a series of “Great Project Management Movies,” surely Ron Howard’s Apollo 13 would be a natural candidate. Faced with a potentially disastrous accident, project teams overcome one potentially fatal barrier after another to bring the crew safely back to earth, guided by mission director Gene Kranz’s mantra, “Failure is not an option.”

But of course failure is an option, and in the case of the Apollo 13 mission, the odds were heavily stacked against a happy outcome— and everybody (including Gene Kranz) had to be well aware of that fact. Within the overall project “get the astronauts home safely,” there were numerous subprojects, including:

  • Develop a power-up sequence that draws fewer than 20 amps
  • Calculate a burn rate to get the reentry angle within tolerance using the sight of the Earth in the capsule window as the sole reference point
  • Design a way to fit the square command module carbon dioxide scrubber filter into the round Lunar Excursion Module (LEM) filter socket.

That last subproject was vital, because the LEM’s carbon dioxide scrubbers were designed to take care of he needs of two people for a day and a half, not three people for three days. And nobody ever imagined that the command module scrubbers would need to be used in the LEM, so they weren’t designed to be compatible. They’re square, and the necessary holes are round. Meanwhile, the carbon dioxide levels are already past 8, and at 15 things become dangerous, and eventually deadly. As the engineers gather in a conference room, boxes of miscellaneous junk — basically everything that’s loose on board the spacecraft — are being dumped on tables.

Managing a Crisis Project

Let’s look at the project management problem.

It’s easy to build a carbon dioxide filter on Earth; there’s a standard specification, a deadline measured in weeks, if not months, and all the resources you need are easy to acquire. In a crisis situation, such as existed aboard Apollo 13, the project looks a little different.

At the beginning of the project, the engineers involved could not know whether the project would turn out to be ultimately impossible. Impossibility could exist in any of the three fundamental constraints.

  • Does the time available to accomplish the project equal or exceed the time necessary? 

In developing a replacement for the Apollo 13 mission’s overloaded carbon dioxide filter, engineers were constrained by the amount of time until the astronauts became too impaired to build what they designed. If the deadline turns out to be too short, then the project is impossible.

  • Are the resources needed to accomplish the project less than or equal to the resources available? 

The project was constrained by what was actually available on the spacecraft. If their resources are short by even one critical component, no matter how small — a 20¢ screw — the project is impossible.

  • Are the performance criteria achievable within the outer boundaries of the other constraints? 

If the improvised filter can’t be made to work long enough for the astronauts to reach Earth orbit when they can return to the command module, then the project is impossible.

As we all know, the Apollo 13 engineers did come up with a workable solution, but that was hardly guaranteed. Had the constraints been slightly different — less time, fewer resources, more challenging performance standards — the outcome would likely have been failure.

But that doesn't mean you shouldn't try.

Next Week: The CHAOS Report!

No comments:

Post a Comment