
Subscribe to
Computerworld February 10, 2003 (Computerworld) -- 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
![]()
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.
Know Your Champions
The types of individuals who gravitate toward the project champion and exit champion roles are similar, says Isabelle Royer, but there are key differences in the way their roles play out:
PROJECT CHAMPION
EXIT CHAMPION
Operates in an uncertain, ambiguous environment.
Removes ambiguity with hard evidence.
Violates or overrides procedures to remove obstacles to a project.
Restores procedures to ascertain project viability.
Risks reputation if project fails.
Risks reputation by challenging popular project.
Willing to take the initiative to assume critical roles that arent assigned.
Are energetic and determined enough to overcome obstacles, skepticism.
|
|
Print this Story |
|
Send Us Feedback |
|
E-mail this Story |
|
Digg this Story |
|
Slashdot this Story |
|
|
|
|
|
|
|
|
|
|
All Zones Application Performance Zone Enterprise-Class Security Zone Enterprise Solutions Zone The File Data Management Zone Grid Computing on Windows Zone Security Management Zone ITIL Best Practices Zone The SAS Zone Storage Virtualization Zone The Data Center Management Zone |
|
|
| ||||||||
| ||||||||
| ||||||||
|


Planning Virtualization for Production Environments The overwhelming complexity of the modern data center compounds the problem of how to safely virtualize IT environments. This paper provides an in-depth guide to analyzing complex environments for virtualization opportunities, particularly within production environments where stability, service levels and performance are of the upmost performance.Download this white paper now
|
Research Report: Steps to Improved Program and Portfolio Management Learn how to deliver improved PPM results. Read Gartner's Maturity Model to assess the maturity of your processes, financials, technology and business relationships. Determine investment priorities and establish incremental goals for IT improvement.
Download this white paper
|
![]() |
HP Compaq t5735 Thin Client
Linux-based thin client delivers desktop-like performance supporting a variety of open-source applications, creating a new paradigm in thin client computing. The NEW HP Compaq t5735 Thin Client provides convenient access to server-based solutions, Virtual Desktop Infrastructure (VDI) or to a variety of remote client solutions. Download this datasheet
|
Global Operations Uses HP Thin Clients to Improve Security and TCO
Do you need a secure standardized platform while maintaining a lower cost of ownership company wide and to help make the company more competitive? Read how the CIO of the world's largest manufacturer of polyethylene folding tables, chairs, picnic tables, and residential basketball equipment obtained his IT Goal with HP Thin Clients. Download this case study
|
HP's Virtualization: HP's Remote Client Solutions Webinar
- Hear from IDC analysts on PC Client Virtualization and Alternatives to Client Computing - Hear how customers solved IT challenges with HP's solution to Virtualization - Learn about different types of virtualization market analysis from HP's CTO - Hear from the VP of Netpads, Inc. how HP Thin Client solutions helped solve IT challenges, security concerns and lowered TCO for the emerging hospitality. View this webcast
|
| About Us Advertise Contacts Editorial Calendar Help Desk Jobs at IDG Privacy Policy Reprints Site Map |
|
CIO The Industry Standard |

