Great Expectations: Turning Failure into Sucess—and Vice Versa
Like everything else, the definition of project failure is in a state of flux. With customer expectations and market pressures changing as fast as Gertie could gallop, how can we ensure success?
by Bud Baker
THE CEO ANNOUNCED THE PROJECT with great fanfare. It would be the biggest construction effort they'd ever undertaken, costing billions of dollars and taking 10 years or more to complete. But if the costs were great, so were the potential benefits: greater efficiency, enhanced safety, even the saving of countless human lives. Expectations were high.
But it didn't take long for those lofty ambitions to fade. Within a year—before the first ground was broken on the project—estimated costs had doubled, and then doubled again. The 10-year schedule was already obsolete, and the project's political support had nearly vanished.
A textbook project failure, you might think, one more example of a project first overpromising, and then underdelivering. But the truth isn't nearly so clear. The CEO in this case was President Dwight Eisenhower and the year of his announcement was 1954. The project: development of the United States’ massive interstate highway system. While the project certainly failed to meet the original thresholds set for it, few would argue today that our American interstate highways— the envy of the rest of the world—epitomize project failure.
Toward a Working Definition of Failure
Whether or not a project is a success is seldom obvious, at least not for a long time. It wasn't all that long ago that NASA‘s Hubble Space Telescope was being held up as a model of project disaster—billions of dollars spent to give scientists a hopelessly blurry view of outer space. Yet at this writing, NASA astronauts have just completed another successful trip to Hubble, once again enhancing its ability to see further into space and time than ever before. So is Hubble really a failure? Or a stunning success?
Some define project failure as the inability to meet client expectations regarding cost, schedule and technical performance. But those expectations are often seriously flawed, especially at the beginning of a project. President Eisenhower sold the American people on the interstate system largely because of its benefits to national defense: fast, modern highways would help the United States fight and then recover from a nuclear war. Four decades later, that expectation seems pretty quaint, and nowhere near as compelling as the highway system's benefits in terms of safety, economic development and enhancement of national commerce.
Not long ago the Hubble Space Telescope was held up as a model of project disaster—billions of dollars wasted to give scientists a hopelessly blurry view of outer space. Now NASA astronauts have completed yet another successful trip to Hubble, enhancing its ability to see further into space than ever before. So is Hubble a failure? Or a stunning success?
Further, limiting the definition of project success to the client's assessment is a narrow view. First, the client is often—especially in government projects—not the one paying the bills. Federal agencies, for example, often spend billions of taxpayer dollars to meet their own needs. But if the Internal Revenue Service's computers don't work, or if the Federal Aviation Administration's air traffic control systems fail, the price is borne not by those client organizations, but by all the rest of us as well.
Finally, our focus on cost, schedule and technical performance is incomplete. We need to assess a fourth dimension of project success: politics. It is possible for a project to succeed in terms of cost, schedule and technical performance, yet ultimately fail because of changing political realities. The Air Force's vaunted F-22 Advanced Tactical Fighter may be the most capable combat aircraft in history, yet it may never take to the skies. The problem won't be technical, or schedule-related, or even the $70 million-per-plane cost. What may shoot down the F-22 after a decade of development may be the same factor that dropped the B-2 bomber program from 132 aircraft to just 20: the political disappearance of the very enemy the planes were designed to combat.
A New Look at Project Failure
With all this in mind, let us propose a different interpretation of project failure, while recognizing that project success or failure is often not a black-or-white matter. Projects succeed—or fail—in direct proportion to how well they meet—or fail to meet—the evolving expectations of significant project stakeholders, in the areas of cost, schedule, technical performance and politics.
Failure in Cost. There are at least six cost-related sources of project failures. First, early overoptimism in cost, schedule, or technical areas will drive a project toward cost failure. Note that this has little to do with how well the ongoing project is managed. Rather, the seeds of this trouble are sown in the project planning phase. If the expectations in any area are overly optimistic, the result will be seen as an inability to manage cost. For example, the cost of a major aircraft program was estimated based on a production rate of 42 units per year. This was despite the fact that many believed such a rate to be highly unlikely, given funding pressures. But 42 aircraft per year produced the lowest total cost estimate, so that number continued to be used, despite the reservations many had about its realism. Ultimate result: Production rate never exceeded five units per year, total costs went up as the assembly line never reached efficient levels, and the project was seen as having a major cost problem, when the real failure was in the setting of the original expectations.
If overoptimism causes the perception of cost failure, so then does underperformance in technical or schedule areas. A defense project was pushing the state of the art in physics and in chemistry, and problems arose again and again. At a major performance review, the project manager began his talk by saying that “Never has a project gone so far with so little of the basic science understood.” Ominous words, and he was right. When the project was million of dollars over budget, the plug was finally pulled. But its cost problems were the effect, not the cause, of failure in other areas.
A third source of cost failure is simply error. Hard to believe, but one federal project came across a $100 million math error in a contractor proposal. When the contractor was shown the error, his response was not to correct it, but rather to go back and repropose. In their new effort, they fixed that $100 million mistake. And then they added $100 million to another part of their proposal.
Funding profiles change, resulting in a fourth cause of cost failure. A firm allocates $5 million per year to Project X, for a period of seven years. But as the corporation's profits wax and wane that promised investment may not be sustainable. Schedules slip, deliveries get stretched out, changes occur driven by reduced funding. Before long, Project X is over cost, driven there not by poor cost management but by funding shortfalls external to the project itself.
The fifth cause of cost failure is familiar to all project managers: scope creep. Scope creep often involves the project team's desire to satisfy a client by acceding to the client's requests for products or services beyond the original project requirements. Clients can be devious here: One government client, faced with a project manager determined to fight scope creep, offered to give up feature “A” in return for gaining feature “B”. The project manager reluctantly agreed, and began the necessary engineering change proposals. New feature “B” was fast-tracked at the client's request, while the ECP deleting “A” languished. It languished for so long, in fact, that it ultimately was set aside and forgotten. The project client received both “A” and “B”, and the project manager got a cost overrun, along with a valuable lesson in organizational politics.
“Perfect is the enemy of good enough,” and it brings us to our final cause of project cost problems: “If 100 percent of requirement is good, then 110 percent must be better.” Or so the thinking goes. But sometimes, major investments are made to achieve technical performance levels beyond the client's real needs. An Air Force missile system had generally adequate performance characteristics but age was cracking the missile's propellant, thus requiring a replacement missile. The using command specified that the replacement missile exceed the performance of the original, by a significant degree, despite the technical challenges all knew to be involved. Result: After years of work, the new missile never did reach the ambitious requirement. After numerous explosions, schedule delays and cost overruns, the project was ended. The combat command had to give up its decaying older missile, and never did receive a replacement system.
Failure in Schedule. As with cost, early over-optimism is a major cause of schedule failure. This doesn't mean that people don't know how to schedule, nor does it mean that schedulers intentionally underestimate the time required for a project. Though either of these things can certainly occur, more schedule problems seem to be generated by project managers’ tendencies to be fundamentally optimistic, especially in the early stages of their project.
Let's look further at the nature of this optimism. One project manager refers to the early portion of a project as “the brochure phase.” He means simply that early in a project's life, before the laws of economics, science and human nature have conspired to impede progress, all things seem possible. Relationships among all the project participants tend to be good, and promises can be easily made, in the knowledge that it may be years before those promises must be kept.
A second cause of schedule failure is client appeasement. Reaching a balance between trying to satisfy a client and just caving in is not an easy thing. In one large project, the prime contractor told the client that they projected a six-month schedule slip. The client said that was unacceptable. The contractor repeated his estimate, and the client repeated his position, more loudly this time. Finally the contractor said, “What do you want me to say?”
The client, under pressure from his own superiors, said he wanted to hear that the contractor would manage to the original schedule, with no delay. The contractor folded at that point, simply saying, “Fine.”
And, of course, the project came in six months late, as the contractor had warned, and then some.
As in the area of cost, some of the other sources of schedule failure can include scope growth—more tasks just take more time—and the reach for technical perfection.
A last area of schedule problems involves resource limits. This is especially true in multiproject organizations, where scarce or narrowly focused resources must be shared. Management guru Tom Peters has said that a key to successful project management is to “avoid the shared resources trap.” Easier said than done, of course: When Project A‘s schedule changes put it into, say, a crucial test facility that had been allocated to Project B, both projects’ schedules will suffer.
Failure in Technical Performance. When projects fail in this area, the results in many cases tend to be spectacular. Airplanes crash, buildings collapse, wayward missiles explode in garish balls of fire. But no matter how stupendous the final result, the root causes of technical failure tend to be more prosaic, and they have much in common, regardless of the particular projects involved.
Again, overoptimism is an issue. As one defense industry critic put it, “To sell a program to Congress, you have to lie about it first.” While that may strike some as a bit cynical, it's undeniably true that the same optimism that infects cost and schedule planning affects the areas of technical performance, too. Such optimism breeds high expectations, and these expectations then set the stage for project failure.
Some projects fail technically because of simple error. Since projects are by their very nature unique undertakings, the likelihood of error is great—after all, if projects were easy, everyone could do them.
Often the errors are technical in origin. Engineering students have for decades studied the tape of “Galloping Gertie,” the Tacoma Narrows suspension bridge that collapsed into Puget Sound due to a design miscalculation. A similar mistake caused a Kansas City hotel disaster, where a design error caused an atrium overlook to cave in, killing dozens.
In other cases, technical shortfalls are the result of business decisions. One automaker put such severe constraints on the developers of a two-seat sports car that the vehicle was probably doomed from the start. Even though studies showed that women buyers would be a primary market for the car, features known to be important to female drivers—like power steering—were omitted from the car's early models due to budget limits. And engine compromises—again due to fiscal constraints—were implicated in a rash of fires, which plagued the car through its brief life.
One more cause of technical failure is poor communication, both within project teams and between the project team and the client. A defense project fielded a highly capable weapon system, complete with its own sophisticated automatic test equipment. But communication between the vehicle's software designers and their test equipment counterparts was imperfect at best. Result: The vehicle and its test equipment were unable to communicate. The fix: software redesign, at a cost reported to be in the tens of millions of dollars.
This particular incident had an interesting aspect to it. Some people on the team apparently knew of, or at least suspected, the miscommunication problem. But the level of distrust, even fear, within the project influenced those people to hold their peace to avoid being the bearers of bad news.
Failures Arising From Politics. Can a project succeed in cost, schedule and technical areas, and yet still be a failure? As unlikely as that sounds, there are plenty of examples. The American nuclear power industry is one, some would claim. Another is surely the Northrop Corporation's F-20 Tigershark.
The Tigershark was a politically inspired airplane, a relatively low-budget fighter aircraft. When President Jimmy Carter balked at selling top-of-the-line F-15‘s and F-16‘s to Third World countries, Northrop developed the Tigershark for the export market. The airplane was a technological success, but not one was ever sold. When Ronald Reagan succeeded President Carter, he opened the floodgates for American weapons exporters, and foreign nations opted not for the Tigershark, but for its bigger, more capable, more prestigious competitors. Result:The project remains the single biggest project failure in history, costing stockholders a billion dollars.
Other cases are less clear, cases in which political failure provided the coup de grace for projects struggling in other areas. Ford's Edsel is one example: Most people who know of the Edsel are aware of its unusual appearance and awkward name. But the Edsel didn't fail because of those things alone. What people often forget is that the Edsel hit the market at the start of the worst recession since the end of the Great Depression. Nor do most people know that the Edsel—a big-engine, high-performance car—came to the market just as the federal government was leaning on carmakers to downplay such features as horsepower, speed and acceleration.
Bad political management—failing to consider the needs and reactions of all project stakeholders—call kill an otherwise viable project. And the converse is also true: Adept political management—as in the case of President Eisenhower's interstate highway system—can save a project that might otherwise be considered a failure.
PROJECT FAILURE, THEN, is not always a clear proposition. Projects succeed—or fail—to the extent that they meet the expectations of the project's stakeholders. Those expectations are not fixed—they evolve as the project evolves. And so it's likely that today's failure could be tomorrow's success story. ■
Bud Baker, Ph.D., is associate professor of management at Wright State University where he directs the MBA program in project management. He has served in the U.S. Air Force as a crew member, Strategic Air Command staff officer, and weapon system program manager. He is a frequent contributor to PM Network and the Project Management Journal.
PM Network • May 1997