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.