The Ol' Yeller Maneuver (Managing Impossible Projects, Part 6 of 6)

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 You Build It, Will They Come?

Earlier, we discussed the story of the infamous automated baggage handling system at Denver International Airport (DIA), which burned through $250 million before being abandoned as unworkable.

There’s nothing inherently impossible about the concept of an automated baggage handling system, though obviously the implementation is tougher than it appears. No, this is the kind of project in which impossibility is situational: a function of the constraints. While we’ve focused on the Triple Constraints because of their universal application in project management, individual projects have other constraints as well.

The airlines themselves, oddly, had little initial involvement in the airport planning. This gave them substantial leverage later in the process. “If you build it, they will come” often carries a hefty price tag. In order to keep its costs down, United Airlines needed the baggage transfer system to take no longer than 45 minutes to route luggage among its flights.

In 1992, the automated baggage handling system was shoehorned into existing construction in what amounted to a “Hail Mary” play. In terms of project scope, the engineering involved amounted to a great leap forward from third-generation to sixth-generation technology.

Performance, obviously, was the project driver, with budget unavoidably the weak constraint. Significant cost and schedule overruns were guaranteed, and to a large extent acceptable — as long as performance goals were achieved.

So far, we have a very challenging project, but there’s no reason for a project manager to propose killing it. It’s not operationally impossible, and the value of closing the gap justifies a very high level of effort.

The Second Frog

The BAE project team officially recognized these key risks:

• Very large scale of the project. 
• Enormous complexity. 
• Newness of the technology. 
• Large number of entities to be served by the system. 
• The high degree of technical and project definition uncertainty. 

The most important risk, however, was not mentioned: the complex stakeholder environment. The initial project was simply to serve United. DIA management expanded the contract to cover all terminals. DIA rejected the BAE proposal to build a 50,000 square foot prototype. Scheduling issues with other construction activities caused huge conflict.

There’s the old joke about the two frogs who fell into pots of water. One pot had hot water, and the frog immediately jumped in. The other pot was warming slowly, so the other frog felt no urgency about escaping until it was too late.

BAE was the second frog.

Politically Impossible

Because the project was not impossible from an engineering perspective, the fact that it became operationally impossible because of the constraints of the stakeholder environment tended to escape notice until it’s too late.

On the other hand, political problems aren’t exactly unheard of. Project managers are supposed to perform a stakeholder analysis. This isn’t just about figuring out your customers — it’s about analyzing the political landscape.

The earlier we identify a risk or problem, the more options are available. If you accompany the sales team when bidding on a job, don’t confine yourself to a study of the technical issues. As project manager, you’re going to have to spend your days dealing with the people, and you can’t tell the players without a scorecard. If you detect political dangers, they need to be part of your risk analysis for the job. This need to affect pricing and schedule, not just for your sake as project manager, but for the sake of the entire job.

If you get into the job and find that these issues are getting out of control, you likely don’t have the power to get out of the problem by yourself. You need allies, and you need them to figure out the problem for themselves. Most project managers see reporting (no matter how necessary) as something that takes time away from doing the work. Reporting, however, is a strategic tool to lay the information groundwork with your stakeholder community to bring them toward the correct understanding of the real situation.

The Ol' Yeller Maneuver

The best way to kill a project is to help the key stakeholders and decision makers reach the conclusion on their own, rather than you telling them. Remember that “operationally impossible” means you can’t figure out an answer. Leave open the possibility that someone else might have an answer you’ve missed. Sometimes they do have an answer for you. And if they don’t, they’re more likely to agree with your assessment.

Sometimes canceling a project is peaceful, sometimes bloody. This one ended with mutual lawsuits. That’s a powerful argument for acting early when the project is likely to be operationally impossible.

So let’s wrap up. A project is operationally impossible if you can’t do it within the stated constraints. There might be too little time, insufficient or wrong resources, or unrealistic or wrong performance criteria.

Sometimes the constraints can be changed, be made more flexible, or in some cases ignored altogether. If the constraints can’t be changed, perhaps you can work around them or accomplish the project in spite of its barriers. 

If the project’s still impossible — well, earlier I mentioned the idea of an American Movie Classics film festival of great project management movies. Apollo 13 is one candidate…but another is Ol’ Yeller. Sometimes a project manager’s job is to kill his own dog.

If the dog won’t hunt, and can’t be killed, the last solution is self-preservation. While captains are supposed to go down with their ships, we project managers are better off living to fight another day. 

The Three Envelopes

There’s the old joke about the outgoing project manager who left three numbered envelopes in a drawer, and told his successor that those envelopes contained the answers to the next three crises the project would face.

Inside the first envelope was a note that read, “Blame your predecessor.” The new person often has flexibility denied to the person previously holding the bag. You may have better luck challenging project assumptions and constraints.

Inside the second envelope, the note read, “Reorganize the department,” because — let’s face it — shuffling deck chairs on the Titanic is a long, noble tradition.

And in the third envelope, the note read, “Prepare three envelopes.” If in the final analysis the project really is impossible, it’s time to get while the getting is still good.

And that’s how to manage an impossible project.

The End.

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!