Everyone has seen it: the IT project that takes on such a life of its own that it becomes virtually impossible to stop, even though all signs point to its ultimate failure. How do projects create this kind of momentum, and why is it so difficult to pull the plug on a clear loser? In this month's Harvard Business Review, Isabelle Royer, an assistant professor at the University of Paris, Dauphine, blames an irrational optimism that blinds everyone involved to the reality of the project. Royer recently spoke with Computerworld to explain the origins of this "collective belief" and suggest ways that IT project teams can avoid it.

You tell some amazing stories about doomed projects that sucked up tremendous amounts of time and resources before anyone pulled the plug. Why do companies often find it so hard to kill bad projects? One could think of managerial incompetence or bureaucratic inertia. What I found is rather that companies cannot envision that the project is going to fail. This happens because there is a collective belief among managers in the eventual success of the project.

What is collective belief, and how does it adversely affect an organization? What I call a collective belief is a strong conviction based on feeling rather than evidence that the project will eventually succeed. This conviction is shared by most of the decision-makers. This collective belief blinds them to negative feedback. Moreover, even when they are able to spot problems, this leads them to increase their commitment and pursue the project more ardently. They are too enthusiastic and emotionally attached to the project to envision a failure.

Isabelle Royer, an assistant professor at the University of Paris, Dauphine

How does the project champion contribute to this problem? The project champion plays a key role in building and sustaining the collective belief. He or she is usually the original true believer who will spread the belief to others using his or her credibility and charisma. When problems are identified, the project champion participates to sustain the belief by his or her enthusiasm, or even with false reports.

You note that individuals often have their own agendas that strengthen this belief in success. Yes, each individual has personal expectations in a company. The CEO might see the project as a way to sustain activity in a division, the project manager as a road to promotion to a higher position. The belief is adopted more easily and is stronger when it fulfills individual expectations.

What happens to dissenters when you have collective belief? Believers just don't pay attention. When dissenters insist, believers don't address their concern but rather try to discredit them. Typically, they accuse dissenters of a lack of competence. So after a while, dissenters stop voicing their opinion. This gives the impression of unanimity.

I see the danger, but how can you rally a project team unless it truly believes in the project? At the beginning of a project, there is lots of uncertainty, especially when the project is highly innovative. Belief is needed to start a project, since evidence is lacking. But as the project unfolds, data amass that allow checking whether this belief becomes reality or not. When the collective belief is too strong, team members don't interpret negative feedback as a sign of failure.

Most IT projects have to pass periodic gateway reviews before they can proceed. Doesn't that solve these problems? This is only a first step. Periodic gateway reviews are set up to evaluate the project and decide whether to continue, stop or modify it. When a collective belief dominates, the review process is not followed rigorously. For instance, rather than checking that a problem has been solved, saying that the solution is at hand would be enough to go ahead.

You talk about some early staffing decisions that can short-circuit the development of collective belief. Tell me about those. Oftentimes, managers staff project teams based on enthusiasm to participate and good personal relationships. In doing so, they create a cohesive group of believers that will have a tendency to escalate. To avoid that, it's important to involve people who are more skeptical and able to point out potential problems. It is also important to replace some of the decision-makers during the course of action, because newcomers will look at the project with fresh eyes.

But smoothly running, cohesive project teams are the Holy Grail in IT. Wouldn't this approach jeopardize that goal? This is a matter of balance. Personal rivalry or dissent in a group would jeopardize the goal, but so would too much cohesion. When the cohesion is too strong, there is no debate whatsoever inside the group about the project. Skeptics in a group ask for more explanations and evidence than others [before they will agree to move ahead]. This might lead to a conflict, but a positive one, leading to better evaluations and decisions.

Above all, you stress the need for an "exit champion." Who is that, and what does he or she do? Well, when most of the people involved are blinded by their belief, and when the procedure is lenient, failing projects are unlikely to be stopped without an exit champion. Exit champions take the initiative to defend exit, which will usually lead to conflict with believers. To convince others that exit is a better course than continuation, they have to bring evidence, which usually means introducing or restoring a rigorous evaluation procedure. This role requires many qualities similar to those of champions, such as credibility and risk taking.

What's the difference between an exit champion and the kind of naysayer that can sap the life out of a project team? Naysayers are known to always have a negative opinion, which undermines their credibility. On the contrary, the exit champion is not always negative. Many of them have also been project champions in the past. Further, naysayers usually merely voice their negative opinion, whereas exit champions take action to defend exit.

Exit champion seems like a thankless role. How do you get it to be valued in the company so people will step up to this role - and be listened to when they do? Top managers may point out they value this role by telling stories of courageous exit champions who saved their organization millions of dollars. They should at least make it clear that challenges to a popular project are welcome. At the same time, they need to demand strong evidence regarding the need to end a project. Failing to do so would systematically favor exit, which would discourage new projects. Here again, there is a balance to be found.

Melymuka is a Computerworld contributing writer. Contact her at kmelymuka@earthlink.net.