| ||||
Why can't companies kill projects that are clearly doomed? Is it just poor management? Bureaucratic inertia? My research has uncovered something quite different. Hardly the product of managerial incompetence or entrenched bureaucracy, the failures I've examined resulted, ironically, from a fervent and widespread belief among managers in the inevitability of their projects' ultimate success. This sentiment typically originates, naturally enough, with a project's champion; it then spreads throughout the organization, often to the highest levels, reinforcing itself each step of the way. The result is what I call collective belief, and it can lead an otherwise rational organization into some very irrational behavior.
Of course, a strongly held conviction and the refusal to let inevitable setbacks undermine it are just what you need to get a project up and running. But there is a dark side: As the project moves forward, faith can blind you to increasingly negative feedback—from the lab, from vendors and partners, from customers.
To better understand why this happens and what can be done to prevent it, I analyzed two failed product innovations at two large French companies. One was a new lens created by Essilor, the world's largest maker of corrective lenses for eyeglasses. The other was an industrial additive used in manufacturing paper, paint, and plastics, developed by Lafarge, the largest producer of building materials. In both cases, the projects absorbed millions of dollars of investment before the companies finally abandoned them. ...
The Consequences of Belief. The greatest danger posed by an organization's collective belief in a project is that problems, even if acknowledged, won't be seen as signs of failure—or at least as issues that should be resolved before moving on to the next stage of development. At Essilor, some managers explained away the lukewarm initial demand for the lens as an aberration related to the soon-to-be-solved technical problem of layer separation, forgetting that the market was generally unaware of this problem. At Lafarge, one manager knew that the decision to build the plant was probably premature, given the available test results for the product, but he said nothing because he was eager to move forward on an enterprise everyone was certain would succeed. Managers at both companies referred to the blindness that resulted from their faith in the projects.
This blindness persists in part because collective belief undermines normal organizational procedures and safeguards. For one thing, the enthusiasm generated by faith in a project can lead to an unrealistically tight development timetable. Essilor canceled some tests and substituted shorter, less reliable ones in order to stick to its aggressive development schedule. A test to see how durable the lenses remained over time, for example, was shortened from two years to six months. Lafarge's desire to remain on schedule was the driving force in the construction of the plant before necessary tests on the additive had been completed.
| All too often, project teams are self-selected. |
| —Isabelle Royer |
Enthusiasm also can result in lenient procedures for reviewing the viability of a product throughout its development. For instance, scratch-resistance specifications for Essilor's new lens were not defined until 1990, eight years after the product was initially launched. Furthermore, widespread enthusiasm can lead to the formation of a project team filled with, and overseen by, uncritical boosters of the initiative.
Together, these factors can create a reinforcing chain that perpetuates collective belief. Decision makers' faith in the project results in an absence of clear decision criteria, which leads to ambiguous information, which in turn favors wishful thinking by those decision makers and further bolsters their belief in the project's success. In a sense, the project takes on a life of its own.
Avoiding the Dangers of Blind Faith
In your own company, you have undoubtedly known projects that dragged on but went nowhere. You may be aware of a handful of bad projects that are grinding along, or even picking up speed, right now. How can companies prevent this sort of thing? How could the managers at Essilor, for example, have known that the composite lens project wouldn't turn out the way the Varilux lens effort did?
They probably couldn't, at least for a while. But they could have done a number of things that would have made them better able to judge their progress and counteract the distorting effects of collective belief. Two kinds of safeguards can be built into a project before it even gets under way. Another one requires a manager involved in a project to play an important, new role.
Beware of cheerleading squads. All too often, project teams are self-selected. They include people who have volunteered because they share an initial enthusiasm for the project. They may even have worked together on successful projects in the past. They know the drill and can anticipate one another's moves. In fact, they know them too well. As they interact, there are none of the awkward missteps or misunderstandings that can produce unexpected insights—or signs of trouble. Warning flags that do appear may be ignored; after all, everyone is rooting for something they believe in. Executives launching a project would do well, then, to include skeptics along with believers in the project teams from the outset, paying particular attention to those who will be directly involved in making decisions. Then, over the course of the initiative, some decision makers should be replaced with others, who will look at the project with fresh eyes.
At Essilor and Lafarge, top management populated the projects with true believers. In fact, in both cases, the sole initial critics joined the projects somewhat by chance. Essilor's director of research and manufacturing was involved only because he was the immediate supervisor of the manager of the plant where the lens would be made. Lafarge's mineral-fillers manager had originally been hired for another job and joined the project only because Lafarge had difficulty finding someone with both minerals and project expertise to fill out the team. At Essilor, personal relationships also came into play; some members had been friends for twenty years—a further reason that robust criticism, which might jeopardize those friendships, didn't emerge.
Only when turnover occurred for reasons unrelated to the project—retirement, health problems, the restructuring of a company-wide research function—was the cohesiveness of the project groups disrupted and some measure of objectivity introduced.
Establish an early warning system. From the start, no matter how exciting or important a project is, a company needs to make sure that its control procedures and criteria for evaluating project viability at each stage of development are truly working—that they are clearly defined, rigorous, and actually met. Big companies like Essilor and Lafarge typically have these kinds of effective internal controls for all sorts of processes—for example, "stage gates" that companies must go through as they proceed with a potential acquisition. But they can easily forget to establish such structures at the beginning of a project that seems bound for glory. Or even if they do establish processes for good decision making, they can end up ignoring them—or the results—amid the excitement generated by a new project.
Lafarge executives concede that they failed to adhere to their own decision criteria when they went ahead and built the plant—although the criteria were vague enough to make this fairly easy to do. Essilor had several clear procedures for testing the lens during development that weren't followed; others produced negative results, which were ignored. As one Essilor manager said: "The decision to launch was implicit. It was just a question of when."
Recognize the role of the exit champion. Sometimes it takes an individual, rather than growing evidence, to shake the collective belief of a project team. If the problem with unbridled enthusiasm starts as an unintended consequence of the legitimate work of a project champion, then what may be needed is a countervailing force—an exit champion. These people are more than devil's advocates. Instead of simply raising questions about a project, they seek objective evidence showing that problems in fact exist. This allows them to challenge—or, given the ambiguity of existing data, conceivably even to confirm—the viability of a project. They then take action based on the data. At both Essilor and Lafarge, exit champions—the new research manager at Essilor, and the new operations director at Lafarge—joined the projects as evidence of their unpromising futures was mounting. But supporters were still clinging to the shreds of positive evidence that occasionally emerged—or ignoring the evidence altogether. Had it not been for these exit champions, team members said later, the projects probably would have continued for months or even years.
To be effective, an exit champion needs to be directly involved in the project; a negative assessment from someone based elsewhere in the company is too easy to dismiss as ill-informed or motivated by organizational rivalry. The exit champion also needs a high degree of personal credibility. The managers at Essilor and Lafarge who had raised questions about the lens and paper filler during the early development stages lacked this credibility. Essilor's director of research and manufacturing was known within the organization as a naysayer; Lafarge's mineral-fillers manager, who came from another company, appeared to lack industry experience. The exit champions, by contrast, had been with their companies for a long time and were well regarded by top management. Both had a strong network of people at different levels of the company ready to provide support when they decided the project should be killed.
| Perhaps most important, exit champions need to have some incentive for putting themselves out to halt a bad project. |
| —Isabelle Royer |
What kind of person would willingly assume such a role? Even if killing a project doesn't put an exit champion out of a job—the individuals at Essilor and Lafarge had responsibilities beyond the projects in question—the role, unlike that of a traditional project champion, seems to offer little in the way of prestige or other personal rewards. In fact, the exit champion faces inevitable hostility from project supporters; those at Essilor and Lafarge were variously described as villains or dream breakers.
Consequently, exit champions need to be fearless, willing to put their reputations on the line and face the likelihood of exclusion from the camaraderie of the project team. They need to be determined: Both Essilor's and Lafarge's exit champions failed in their first attempts to stop their projects. Perhaps most important, exit champions need to have some incentive for putting themselves out to halt a bad project. For many, this will simply be an acute distaste for wasted effort. As one exit champion at another company I researched said, "When I work, I need to believe in what I do. I don't want to waste time on something that is worthless."
It is important to understand that an exit champion is not a henchman sent by top management to kill the project. The exit champions at Essilor and Lafarge certainly weren't: They were assigned their positions only because their predecessors had left the company, and they simply took the initiative to determine if their projects were likely to be successful. Indeed, it wasn't initially clear to either of them that their respective projects should be killed. Although signs that the projects wouldn't succeed were accumulating, in neither case was the evidence conclusive because it wasn't based on hard data.
Senior executives need to recognize the exit champion as a defined role that someone might play in the organization—otherwise, they may not know an exit champion for who he is and give him the support he will need. And they can take steps to create an environment in which such a savior would be more likely to emerge. Just as companies celebrate and recount stories of the great successes of product champions, they could perhaps identify and spread tales of courageous exit champions in their midst (or at other companies) who saved their organizations millions of dollars. Top managers should at the least make it clear that challenges to a popular project would be welcome or even rewarded. At the same time, though, they need to demand from the exit champion strong evidence of the project's weaknesses—just as they should have earlier demanded growing evidence of its viability.