The CHAOS Report (Managing Impossible Projects, Part 3)

Photo: Baggage system, Denver International Airport


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 annual Standish Group’s CHAOS Report, which tracks software project performance reported these abysmal numbers for 2009:

• 32% on time, on budget, to spec
• 44% finished late, over budget, or partially completed
• 24% failed, cancelled, or abandoned

Why do so many projects fail, either in part or in whole?

Certainly, there are badly managed projects — even some headed by PMPs. But it’s hard to blame a 68% defect rate on poor practitioners alone.

Sometimes the problem is the definition of success. By the logic of project management, the Leaning Tower of Pisa was an abysmal failure: late, over budget, and…well, aren’t buildings supposed to be straight? The Standish Group would clearly label the tower as a failed project, yet if the tower didn’t lean, who today would bother to visit?

The third reason, of course, is that the project was problematic to begin with — arguably or actually impossible. This can happen for a variety of reasons. In the case of Apollo 13, the constraints of time, resources, and performance were established by the situation, not by the will or desire of the project managers or owners. They were what they were — whether they were achievable was a separate issue.

In the Battle of the Bulge, the German Ardennes offensive had already begun. We would be able to get troops to the front to relieve the pressure on beleaguered First Army units, or we wouldn’t. Neither project managers nor project owners necessarily control the constraints that drive their projects.

Sometimes we’re just making a guess when we establish a project’s constraints. The original budget for Denver International Airport was $1.2 billion, and the original deadline was October 1993. The final price came in at $4.8 billion and the actual opening date was February 1995. (The infamous automated baggage system, budgeted at $186 million, wasn’t cancelled until 2005, by which time its construction costs were increasing at a staggering $1 million a day!)

Denver wasn’t an example of engineering or technical failure — no, not even the baggage system. The failure was driven by political considerations, including a nonstop war among several key stakeholders. When customer conflict generates mutually exclusive requirements, “impossible” becomes just another word for nothing left to lose.

In any event, we project managers are hired hands. Sometimes we may do double duty as customers or sponsors of our own projects, but when we put on our PMP hats, we’re here not to decide, but to execute. We are bound by the decisions and choices of others, and sometimes we start the project on the precipice of failure. After all, how many of you get to decide your own timelines, set your own budgets, and establish your own performance requirement?

I didn’t think so.

Still, you don’t want to be too quick to pull the trigger. Let’s imagine that you have a project and your experience tells you it can’t be done. Isn’t delaying the inevitable bad news just going to make the problem worse?

That depends on what you do in between receiving the assignment and giving the answer. Even if your project’s impossible, or at least compromised, there’s still a customer problem needing to be solved. Telling people what they can do and what they can have tends to get a better reception than telling people what they can’t do and what they can’t have.

That’s why the first step in managing a potentially impossible project is analysis. When you analyze an apparently impossible or potentially impossible project, you may learn different things.

1. You confirm that the project is in fact impossible, and can provide evidence to the customer. You and the customer can begin to figure out what alternatives may exist or how to deal with the consequences of an unsuccessful project.
2. You confirm that the project as originally proposed is in fact impossible, but are able to find potential changes that will make the project possible, which you can present to the customer.
3. You confirm that the project as stated is in fact impossible, but are able to offer alternatives and compromises that might satisfy at least some of the customer’s requirements and needs, or close part of the gap.
4. You can’t confirm that the project is in fact impossible, but you can identify at least some of the risks and challenges you face, which you and the customer can then assess.
5. You find a creative way around the barrier that made the project impossible, and achieve the original goal.

Even if your analysis leads to the first outcome (it’s just flat impossible), however, your situation is still improved by your ability to give a thoughtful reply with supporting evidence, and your attitude in making a good-faith attempt to solve the problem.

Partial successes (outcomes two, three, and four) are a marked improvement. Even if the project is impossible — or highly risky — as stated, the customer may be able to get a significant portion of what he or she wants. Plus, it’s well known that the first approximation of available constraints may not be the final word. There may be more to draw on. And again, people tend to react better to hearing what they can have, and less well to hearing what they can’t have.

We renovated our house last summer, and the project was on time, exceeded our expectations — and cost about twice as much as we’d planned. We still call it a rousing success, because we never really expected to meet the budget anyway. It was a hope, not a realistic assessment. The Standish Group would call it a failure, but we don’t — and the customer is always right.

The fifth outcome (solve the problem with creativity) is ideal, but often challenging and not always successful.  The best direction to find the creative answer is, paradoxically, to focus on the barriers in the first place.

Next Week: The Power of Negative Thinking!

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!

If I Had a Lever (Managing Impossible Projects, Part 1)

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. 



If I Had a Lever...

When we say “nothing’s impossible,” we usually mean that given unlimited time, unlimited resources, and really flexible performance standards, we can do anything. “Give me a lever long enough and a platform to rest it on, and I will move the world,” said Archimedes, but he was obviously not a project manager. Our projects are constrained: the iron triangle of resources, time, and mandatory scope are only three of the dimensions that restrict our options.

There are many types of impossibility: legal impossibility, scientific impossibility, metaphysical impossibility, and logical impossibility, to name a few. Each has its own definition and its own specific context. Our question is more focused: what does “impossible” mean in the context of project management — and more importantly, in the context of your project?

We define a project as “operationally impossible” if it cannot be accomplished within the boundaries of its mandatory constraints. Of course, seemingly “impossible” projects succeed all the time, and there are a number of proven strategies that work — at least part of the time.

• Sometimes a team discovers a brilliant critical insight, or is simply smart enough and good enough to achieve what lesser mortals cannot.
• Sometimes the team gets it done by sheer Herculean effort, working harder and longer than anyone expects. The project succeeds, but sometimes the organization pays a long-term price.
• Sometimes the team gets it done, but the outcome is compromised. Maybe the project cost more, or took longer, or did less. Sometimes we can point to the corpses of the projects we sacrificed in order to make the current project succeed
• And sometimes the team fakes it, slaps a coat of paint on it, and hopes nobody notices that the wheels have fallen off. (Make sure your résumé is up to date first.)

There are, fortunately, some better answers, and in this and the next few blog posts we’ll journey through history to see what lessons we can pick up.

Patton and the Bulge

Let’s set the Way-Bac machine for December 19, 1944, where the Allied High Command is meeting in Verdun to plan its response to the German offensive Wacht am Rhein, popularly known as the Battle of the Bulge. 

Elements of the United States First Army, supposedly in a quiet sector of the front, are pinned down in Bastogne. Eisenhower asks the assembled generals how long it will be before Allied forces will be able to relieve the beleaguered Americans at Bastogne. British Field Marshal Bernard Montgomery says it will take weeks.

George Patton, commander of the United States Third Army, jumps in. . (Patton, by the way, sounded a lot less like George C. Scott than he did like Ross Perot.)

“I can attack with three divisions in 48 hours,” he says.

The response from the other generals was not polite.

Patton’s boss, General Omar Bradley, was not amused. “Ike wants a realistic estimate, George. You’re in the middle of a fight now. It’s over a hundred miles to Bastogne.”

They were, of course, right to be skeptical. Extricating three divisions from a tough fight and moving them 100 miles in 48 hours?  That’s not just difficult, that’s downright impossible. 

Let’s see why.

A division is an Army unit consisting of approximately 15,000 soldiers, along with everything they need to do their job. Imagine picking up a town of 45,000, along with all the services needed to keep them going, and moving 100 miles in 48 hours…and forget the interstates; there aren’t any. Just for starters, if you don't have a detailed movement plan, you'll end up with the world's biggest traffic jam. 

Armored vehicles are gas-guzzlers, people have to eat, and soldiers need ammunition. That means you'll have to pre-position gas, food and supplies along the route. 

A moving division is more vulnerable than a division on defense. That means you need fighting units to protect moving units, and they need more gas and food and ammunition.

A move of this nature requires a planning staff in the hundreds. In World War II, without cell phones, laptops, and GPS units, orders were typed on mimeograph stencils, duplicated, and hand-carried to unit commanders stretched out over an immense area. Today's technology is far superior, but so are the demands involved.

It takes weeks to pull off an operation like this. It really can’t be done in 48 hours. It’s an impossible project — flat out impossible.

And yet it was done.

But wait a minute. If it was done, then wasn’t it by definition possible?

Like with any good magic trick, the key often lies in challenging your assumptions. Eisenhower’s headquarters learned about the German Ardennes offensive late in the game, and that’s why Patton needed to move within 48 hours. But Patton, alone among senior Allied commanders, had anticipated the possibility, deployed his own intelligence resources, identified the threat, and bought himself the extra time he needed. He didn’t do it in 48 hours. He changed the constraints.

There’s a scene earlier in the movie in which he instructs his staff to begin planning the move northward. His staff had several weeks to prepare three different contingency plans. All Patton had to do when the meeting broke up was walk downstairs to his jeep, call his headquarters on the radio, say “Nickle,” and the forces were on their way. (His driver, Sergeant Mims, reportedly said, “I don’t know why they need all them other generals. You and me can run this whole war out of your jeep.”)

If a project can’t be done within its constraints, one obvious approach is to follow Patton’s example, and alter the constraints, but of course, that’s not always an option. Sometimes, the project is inherently likely to fail — but that doesn’t mean you don’t still have to manage it.

Next week — Failure IS An Option!

Riddikulus! (Part 14 of Fallacies)

More red herrings, argumentative fallacies that distract from the argument rather than address it directly. This week, the final three appeals to emotion: the appeal to ridicule, the appeal to spite, and wishful thinking.

Reductio Ad Ridiculum

Riddikulus! As all Harry Potter fans know, the way to defeat a boggart is to convert it from an object of terror to an object of mockery. While the spell clearly works, in real life, the appeal to ridicule is a type of red herring fallacy in which the opponent presents the original argument in a way that turns it into a mockery of itself, either by emphasizing the counter-intuitive aspects of the original argument, or by creating a straw man to debunk it.

An example of the first approach is the argument, “If Einstein's theory of relativity is right, that would mean that when I drive my car it gets shorter and more massive the faster I go. That's crazy!” It’s also true. The problem is that the effects are not easily measured at automobile speeds, but only become significant as the object nears the speed of light.

The second approach misrepresents the argument in order to ridicule it. “If evolution were true, that would mean that all the apes wouldn't be here any more, since they all would have evolved into humans!” That’s ridiculous indeed — but it’s not actually implied or stated in the Theory of Evolution.

Argumentum Ad Odium

The appeal to spite exploits existing bitterness or dislike in its attack. The various attacks on union benefits (such as retirement), particularly in government workers, relies on the negative emotions aimed at the target group as the primary justification for cutting back or cancelling previously agreed-upon benefits. “Why should people enjoy a comfortable retirement with my tax dollars?”

Wishful Thinking

Wishful thinking is based on the premise “I wish P were true/false, therefore P is true/false.” You see this in a lot of superstitious behavior, from chain letters to the belief in UFOs. Personally, I think it would be really cool if aliens did in fact visit Earth — but that doesn’t make it true.