Twelve ways to get the least from yourself and your project
Denial, as they say, is not just a river in Egypt. It's one of a dozen traps that projects can fall into, never to climb back out.
by Jeffrey K. Pinto
ANALYZING PAST PROJECT FAILURES is fascinating, isn't it? Not our own, of course. About those, we often feel that the less said, the better. No, our morbid curiosity is piqued by knowledge of how other projects, with other project managers, have failed. Sometimes these failures occurred quietly, with funding being withdrawn from projects that became increasingly nonviable. Other project failures have been far more spectacular and sometimes deadly. The collapse of the overhead walkway at a hotel in Kansas City some years ago resulted in the deaths or serious injuries of hundreds of people. The famous collapse of the Tacoma Narrows suspension bridge in 1940 led to a reassessment of bridge building techniques and the role that aerodynamics must play in bridge design. All these examples, both the famous and mundane, have important lessons for project managers, if we are willing to listen to them objectively.
When analyzing project mistakes and their principal causes, there are two important lessons that should be apparent to every careful reader. First, all organizations, no matter how successful they have been or will continue to be, make mistakes. Ford Motor Company, IBM, Mitsui, Sears, and other corporate giants have all had their share of disasters to go along with the more-talked-about successes. This is the nature of business events—the cycle moves through highs and lows. For every project success, there will always be one or more failures. The second lesson is equally clear: Where there is failure, there is the potential for learning. This second lesson, however, is also potentially threatening. It says, in effect, that failure (particularly our past failures) is not to be pushed aside, but studied. Learn from mistakes—learn how not to do it.
Not every project deserving of success achieves it. Conversely, not every project heading for the scrap heap arrives. Clearly, there are any number of events beyond the control of the project team and parent organization that can help or hinder a project's chances of success. Nevertheless, when we consider those activities and decisions that can play an important role in a project's failure, my research and experience point toward some important contributing causes of project failure.
Ignore the Project Environment. One of the best ways to consign a project to almost certain failure is to manage it without regard for the organization's external environment, including those project stakeholders who can play such an important part in a project's success or failure. Project “stakeholders” is the term used to refer to any group, internal or external to the company, that has an active stake in the project's development. To ignore the potential power of such stakeholder groups is foolhardy and often results from either ignorance or complacency on the part of the developing organization.
Push a New Technology to Market Too Quickly. New technologies imply new and unknown risks. Sometimes the allure of being first to market with a new technology causes companies to cut corners, marginalize safety factors, or make quality trade-offs. In the end, these decisions almost invariably come back to haunt company executives. DeHavilland's desire to be first to the market with a commercial jet resulted in the creation in 1952 of the Comet I, a faulty design that ultimately killed scores of people, and by 1954 was withdrawn from the market.
Ever heard of the Xerox Alto? Xerox had a working prototype of a personal computer, complete with mouse, word processing software, and a laser printer by 1973. Why did a company create a sure-fire winner and then sit on it? Organizational inertia played a role. For want of the will to take a calculated risk, Xerox lost a dominant position in personal computers. The rest, as they say, is history.
New technologies are very tempting to exploit for exactly that reason: They are new. They offer the company a leg-up on competition. Unfortunately, in our rush to push new designs or technical achievements, there is a strong likelihood of inadequate or cursory pretesting that can result in disaster. There must be a proper balance between being the first to market and ensuring that the product will perform in positive, expected ways.
Don't Bother Building In Fallback Options. All projects run into trouble at one time or another. The question is not whether problems will occur, but rather to what matter of degree. When these difficulties start impeding progress, one of the tests of good project management is how quickly the project is brought back on course. This point is important because it disputes the notion some readers may have that “good” project managers are those whose projects never get into trouble. That belief is patently untrue. Not all problems are foreseeable. Effective managers must proactively search out likely problems rather than waiting for them to occur. The true test of successful project managers lies in their flexibility and capacity to respond in clear-headed ways to problems once they occur.
When Problems Occur, Shoot the Most Visible. Problems with projects, particularly on a large scale, tend to induce panic in top management. Many times, such panic leads to foreseeable and regrettable outcomes: the knee-jerk sanctioning of key personnel. Once top-management is in the panic state, it is common to see heads begin to roll, starting with the project manager and anyone else who is clearly seen as part of the decision-making team.
In the absence of obvious incompetence or misbehavior, the consequences of this extreme reaction should be clearly considered. Prior to making personnel changes, ask the question “What do we hope to accomplish by this change?” While there is no doubt that in the face of ongoing problems with a project it is tempting to demonstrate decisive action in the form of reorganizing and punishing, it is important to first consider the reason for such actions and the message we intend to send. Project managers who are constantly looking over their shoulders out of paranoia and fear of retribution are not project managers who are capable of taking necessary risks and acting in ways to further project success.
Let New Ideas Starve to Death Through Inertia. The flip side of pushing new technologies out the door without having spent adequate time assessing problem areas is to allow new products to remain in a holding pattern indefinitely. For example, few readers will recognize the Xerox Alto personal computer, in spite of the fact that Xerox had a working prototype of a personal computer, complete with mouse, word processing software and a laser printer by 1973. And yet, during the 1970s, Xerox, through a combination of political infighting and bureaucratic roadblocks never developed the Alto personal computer into a commercial product, thereby sacrificing millions in profits over the next two decades.
Why did a company create a sure-fire winner and then sit on it? Certainly, organizational inertia played a role. There was no obvious avenue for bringing these products to market and Xerox executives lacked the will to take a gamble. The irony is that this same company made its reputation by taking a large risk in introducing the model 914 copier in the early 1960s and revolutionized office technology. For want of the will to take another calculated risk, Xerox lost a dominant position in personal computers. The rest, as they say, is history.
Don't Bother Conducting Feasibility Studies. Why waste time checking to determine if a new technology will work? Why worry about harmful side-effects? Why bother considering customer concerns? The answer to each of these questions is that failing to do so is one of the surest roads to project failure. Feasibility planning is the stage at which an organization's planners do their up-front homework to put themselves in the position to conclude a project successfully. Feasibility studies require that project managers and upper-management devote sufficient time to understanding the project's risk analysis, cost analysis, time frame to completion, stakeholder analysis, and other relevant information before funding is approved.
Never Admit a Project is a Failure. Sooner or later, every project will turn itself around, right? Wrong. Many projects fail through mismanagement, miscalculation, or through fundamental changes in the external environment. To continue to push a project through to fruition regardless of whether or not it is still viable is obstinacy bordering on foolishness.
One of the common threads running through many well-known project failures is the company's unwillingness to back away from a poorly managed development process or product introduction, even when the project manager, team and top-management know the project is in trouble. This phenomenon is often referred to as escalation of commitment to a bad decision (for more discussion of this topic, see B.M. Staw and J. Ross’ article, “Behavior in escalation situation: Antecedents, prototypes, and solutions,” in Research in Organizational Behavior, Vol. 9). In essence, the theory shows that more often than not, managers do recognize the serious (even fatal) problems that exist in their projects. Nevertheless, they are usually loath to admit to a bad decision and will actually continue to support that course, even in the face of compelling evidence of failure (J. Brockner offers another view on this subject in “The escalation of commitment to a failing course of action: Toward theoretical progress,” Academy of Management Review, Vol. 17).
Overmanage Your Project Managers and Their Teams. Large corporations, loaded with layers of oversight and bureaucracy, are increasingly becoming some of the worst settings for achieving cutting-edge innovation. We see the same phenomenon with so-called “big science” projects. Is it possible to achieve greatness inside a large corporation? Certainly, but the odds are stacked against you. The sheer size and inertia of the organization make it virtually impossible to react quickly or expedite technology transfer to exploit commercial opportunities.
The term “lean and mean” has come to mean the types of organizations that enjoy better-than-average success with new product development. The lean-and-mean organization has shed the cloak of bureaucracy, is flexible, has pushed decision-making authority down to lower levels where project managers can make product development decisions without endless rounds of review and modification.
Never, Never Conduct Post-Failure Reviews. What can we possibly learn from a failed project? This common question is usually voiced by managers who are frustrated and/or embarrassed with the leftovers from a failed project. The first inclination is to sweep the results under the rug as quietly as possible and then move on as though nothing happened. Failures are written off as flukes or due to events beyond our control. Yet denial is the worst attitude one can possibly take toward business in general and project management in particular. Clearly, such an attitude cannot be in the best interests of the organization nor does it help a project manager's career, particularly in the long run.
Never Bother to Understand Project Trade-offs. Like it or not, when managing projects we are often faced with a series of unappetizing alternatives. These trade-offs often come down to “dollar-day” determination, which frequently are balancing acts among rival (and equally compelling) demands. Do we understand the implications of crashing a project? Have we considered the budget impact of such a decision? If the answer to either or both of these questions is no, clearly we are not making decisions on the basis of rational insight. Hard decisions are the perquisite of project management; uninformed decisions, however, are its bane.
Allow Political Expediency and Infighting to Dictate Important Project Decisions. It will not surprise most canny readers that many operating decisions are made with less-than-perfect motives. Unfortunately, in the politicized environment of most organizations, any number of potentially momentous decisions are motivated far more by personal agendas than by any desire to satisfy overall corporate needs. Project decisions that are made on the basis of power plays and maintaining executive prerogatives are bound to be less than effective. In effect, the project becomes a hostage pawn in a larger, more personal game of acquiring and keeping power.
Make Sure the Project is Run by a Weak Leader. “Weak leader” is an oxymoron. Successful leaders exhibit many traits, but a weakness is not one of them. Leadership is essential in project success. To borrow a concept from the physical sciences, projects, if left to their own devices, tend to run toward entropy. That is, the natural project state is more often chaotic and disordered than logical and pragmatic. In the absence of a strong leader to keep the project team operating on track, most projects begin to experience the vacuum of indecision, orders given and rescinded, and a general sense of aimlessness.
The key is the project leader; this is the one person who has to make the project succeed by marshaling resources, motivating team personnel, negotiating with stakeholders, cheerleading the development process, and constantly keeping an eye on the ultimate prize: the successfully completed project.
WHAT CONCLUSIONS can we draw from our study of project failure? First, that failure is a byproduct of risky ventures. Projects often involve untested or novel technologies and processes. Risk of technical failure is always present in these circumstances. Further, projects upset the status quo of the organization. They operate outside formal channels with temporary groups of diverse individuals pulled together for one purpose. They oftentimes violate political relationships and established chains of command. Given the environment within which many projects operate, failure is a very real possibility with any project undertaking.
The second conclusion is that past failure need not discourage future efforts. Indeed, it is through past failures that we gain the experience and wisdom to push on toward successful conclusions. There are two equally erroneous responses managers can have toward past failure. The first is to brush failure aside with as little thought as possible—in effect, out of sight and out of mind. The other error is the mirror opposite: to become so focused on past failure that it handcuffs an organization from taking the necessary steps for new ventures and project start-ups. It is important not to become a victim of past failure, either through a mulish unwillingness to learn from it or through excessive timidity in trying again. ■
Portions of this article were excerpted from What Made Gertie Gallop? Learning From Project Failures, by O.P. Kharbanda and J.K. Pinto, 1996,Van Nostrand Reinhold.
Jeffrey K. Pinto is the Samuel A. and Elizabeth B. Breene University Endowed Fellow in management and associate professor of management in the School of Business at Penn State–Erie. His most recent books are What Made Gertie Gallop? (Van Nostrand Reinhold, 1996) and Power and Politics in Project Management (PMI Publications, 1996).
PM Network • May 1997