Despite advances in software engineering, project failure remains a critical challenge for the software development community. According to the Standish Group's 1998 survey, only 26% of such projects were delivered on time, on budget, and with promised functionality, wasting billions of dollars annually; 46% were completed over budget and behind schedule, with fewer functions and features than originally specified, and could therefore be classified as runaway projects [10]. In 1994, a survey by consulting company KPMG of 120 organizations in the UK found 62% of them had experienced a runaway project [7]. Today, you can fill your shelves with books covering numerous examples of runaway software projects [3].
The behavior underlying many runaway projects resembles "escalation of commitment to a failing course of action," a phenomenon documented in the general management literature [1] and applied to the management of software projects [4]. Escalation occurs when decision makers throw good money after bad, pursuing a course of action that is not yielding the desired result. According to a more recent study, escalation occurs in 30%40% of all software projects and is associated with schedule and cost overruns averaging more than 150% [5]. Less than 25% of them are ultimately completed and judged successful by IS auditors.
By another definition, a runaway project has "failed significantly to achieve its objectives and/or has exceeded its original budget by at least 30%" [7].
Anecdotal evidence [9] and our own 1999 study of troubled software projects suggest that escalation can be exacerbated by the reluctance of organizational employees, as well as outside contractors, to transmit unwelcome, yet valuable and constructive, information concerning projects and their status. Thus, while evidence of a failing project may exist in the lower ranks of an organization, accurate information about failure may fail to move up the organizational hierarchy. Consequently, decision makers with the authority to change the direction of the project are too often unaware of its true status.
As an example, consider a system called Confirm; originally budgeted at $55.7 million in 1988 and scheduled to take three years to complete, it was to be a leading-edge computerized travel reservation system combining airline, rental car, and hotel information. In 1992, following 3.5 years of development and $125 million, the project was cancelled amid allegations that the chief developer, AMR Information Services (AMRIS), had misled its three partners (Marriott, Hilton, and Budget Rent-a-Car) about the project's status. (AMR is the holding company of American Airlines.) In a letter to the partners, AMRIS's chairman admitted: "Individuals whom we gave responsibility for managing Confirm . . . have apparently deliberately concealed a number of important technical and performance problems" [9].
"I sure wouldn't want to march into this guy's office and tell him the project that he had been championing for all these years should be put to death" (Case #44).
Publicized fiascoes, including Confirm, raise important questions about the communication of bad news up the hierarchy, or "blowing the whistle." Most people find it difficult to blow the whistle, even when troubled IS projects clearly need to be turned around.
Here, we present some of the findings from our study of IS auditors asked to share their experiences as potential whistle blowers on troubled projects (see the sidebar "How the Study Was Done"). We chose IS auditors because of their role in monitoring IS projects. Auditors are likely to be more objective than IS managers or project team members and more willing to blow the whistle on troubled projects. We interviewed both internal and external IS auditors for the study. Internal auditors usually report to the audit department; external auditors are hired as outside consultants to perform specific auditing tasks.
Even where projects are monitored, the study revealed that IS auditors may censor themselves, a phenomenon called the "mum effect" [11]. Thus, while some auditors told us why they blew the whistle, others explained why they chose not to blow the whistle. The study also revealed that even when auditors execute their responsibility to blow the whistle on troubled projects, the people responsible for controlling IS projects may refuse to pay attention, a phenomenon called the "deaf effect" [6]. The auditors we interviewed explained why bad news often falls on deaf ears and described organizational factors they believed would contribute to a healthier climate for communicating negative information about software projects.
Four patterns of responses emerged from our analysis of the interviews. First, many IS auditors reported that they or someone else did blow the whistle on a project. In many cases, this action led to constructive attempts to regain control, reduce the commitment of resources, or terminate the project. Second, some IS auditors in our sample said they did not blow the whistle on a troubled software project, even though they knew it was in serious trouble. Third, even when auditors did blow the whistle, management frequently ignored them. In some cases, auditors paid a high price for trying to convey unwelcome bad news. Finally, the auditors felt the conditions for effective whistle blowing varied across organizations.
Some internal IS auditors clearly feel obligated to blow the whistle on troubled projects. As one expressed it: "As an auditor, it's my job, I feel, to blow the whistle when the whistle needs to be blown" (Case #200). Whistle blowing was viewed by internal auditors as instrumental for removing resources from projects in which they might otherwise be squandered. Whistle blowing was also viewed as a means of protecting the organization from a software system that might harm business processes. One internal auditor warned that the system being developed could crash core business processes; he blew the whistle, and the project was stopped. This auditor also confided that blowing the whistle was very difficult. He contemplated quitting but ultimately drew support from the audit group and executive management. "I thought I could quit, I could start drinking, or all kinds of things," he told us (Case #182). This comment reveals how difficult a decision to blow the whistle can be, especially for an internal auditor. Serious contemplation of a job change or self-destructive activity suggests that whistle blowers struggle with their responsibility.
In several of our cases, an external auditor (or consultant) served as a project's whistle blower. In one, an external auditor was retained to offer advice on whether or not a project could be treated as a capital expenditure for accounting purposes. In researching the project, the auditor coincidentally discovered the project was in trouble. He reported: "We came in as external auditors as part of our annual work, working with their internal auditors, and found that the project really was off track . . . We took a look at itjust kind of ballpark numbersand said, 'Why is management not coming in here and kicking your butts. It's way over budget already' (Case #174).
In two other cases, external auditors were retained to review system design and ended up blowing the whistle on entire projects. In Case #418, an external auditor told us that project management was so "shoddy," it made the audit team uncomfortable, prompting them to inform the controller and executive management. In Case #161, external auditors managed to force a change in the project. "We went right to the CIO and the CFO . . . and told them that we were going to have to walk out of this project unless things changed" (Case #161).
In these cases, it is clear that both internal and external auditors acted responsibly to draw attention to troubled projects. But internal auditors exposing project difficulties assumed greater personal risk than external auditors, because they were more dependent on the organization than their external auditor counterparts.
Despite accepting responsibility for whistle blowing, several internal auditors told us they decided not to blow the whistle because of risks to their own careers. One internal auditor explained that blowing the whistle would probably be "career suicide, to be honest. Me as a little staff auditor? I'm going to go to the executive VP of the company and tell him that this is a worthless project, and he should pull the plug on it? I sure wouldn't want to march into this guy's office and tell him the project that he had been championing for all these years should be put to death" (Case #44).
We also learned that even the heads of audit departments are likely to preserve their careers by remaining mum in the face of trouble (Case #142). The following illustrates the struggle whistle blowers experience weighing their personal risks against their responsibilities. The auditor reported: "It would have been political suicide to go and to speak up, for those of us that had bills to pay and all that other good stuff. You do what you're asked to do, and I wasn't asked to. I had some pretty candid conversations with the man that I worked for. I said that there are so many things here that are going wrong, how can we continue to do this? 'Because we have to do it; that's our job.' And maybe if I had had the support of my manager, I would have felt more comfortable going to the next level to tell him. But I wasn't going to go in there by myself . . . I've been the whistle blower once in my life and wound up standing on the unemployment line. I decided, with a house and a family, there was no way I was going to put myself in that position" (Case #14).
Thus, the prospective whistle blower needs to face the reality that the critical audit report may contradict the best judgment and vested interests of the powerful players backing a project. From the whistle blower's personal perspective, not much is gained resisting the tide. Although responsible for exposing project ills, IS auditors (and other potential whistle blowers) often remain mum due to fear of reprisals.
Overcoming the mum effect is not the only challenge in attempting to redirect or terminate troubled projects. IS auditors also reported that management sometimes turned a deaf ear to their reports. CIOs and other senior executives were portrayed as people who received auditor reports but who downplayed the seriousness of the problems documented in them (Cases #174 and #142). In a case representing a good example of the deaf effect, an auditor explained: "We were trying to quantify and tell them, convey the seriousness of the situation. And I don't think they believed that it would be that serious. I think a lot of that was because they were hearing different information from the head of IS and the operations guy and the project manager. It was very frustrating for me, a little demoralizing" (Case #418).
"They took me out to lunch and said, 'We really appreciate what you've done, but we really won't be needing you anymore' (Case #508).
Sometimes the deaf effect can be overcome by going over the head of the person who refuses to listen and reporting to a higher authority. This practice of organizational leapfrogging was described by an auditor who viewed the vice president of IS as "hear-no-evil, see-no-evil." As his team tried desperately to convince the vice president that a project was in trouble, the "lowly peons," as he described his audit group, were ignored. So the audit team began to write memos to executives higher up the hierarchy (Case #200).
In some cases, however, even appeals to higher authority fall on deaf ears. The following indicates the pervasiveness and consequences of the deaf effect. An auditor said: "I wrote a lot of reports. I escalated things as much as I could, but in the end they basically said, 'We really appreciate your efforts, but thanks, but no thanks.' They took me out to lunch and said, 'We really appreciate what you've done, but we really won't be needing you anymore' (Case #508).
By remaining deaf to warning signs, executives may insulate themselves from having to deal with problems in the short run. They may also disassociate themselves from a failing endeavor, thereby escaping blame. When senior executives are unreceptive to bad news, the risks to the persistent whistle blower are likely to increase.
The mum and deaf effects occur more often under certain organizational conditions than others. Some organizations have larger internal audit staffs than others, their clout often corresponding to their size. In banks and financial institutions, for example, the audit function is well established (to protect the assets of the corporation), and internal IS auditors can proceed more confidently reviewing high-risk projects and making recommendations.
By contrast, smaller audit staffs are easier to ignore. One auditor reported his experiences working for a company with a small audit department. He said: "The company really wasn't that big, and the audit department was like a joke. It was like a figurehead. It was like, 'Oh yes, we have an internal audit department; there they are.' But they would never let us get into something real serious. A couple of times I had written what I thought were serious exposures, and they just blew it off. They said they would study the issue, they would set up a task force, but it was just a token kind of thing. They never really went after it" (Case #142).
Along with differences between organizations, there can be considerable differences across subunits within the same organization, where different operating environments lead to different levels of consciousness about audit and control practices. In some units, IS auditors are encouraged to identify problems with software projects. In others, "People don't even want to know" (Case #508).
Given such variance in credibility enjoyed by the internal audit and control function, what factors can create an environment for effective whistle blowing? Part of the answer lies in the relationship between the audit function and senior management. As one of our respondents noted: "You have to have a very secure audit department that knows its value and is connected to senior management . . . [so] if he makes a recommendation, he feels comfortable he can do it, because he's got the support of senior management" (Case #142).
This auditor also described his experience with a company that had IS project reviews in which the auditor was supposed to sit in on the system's development and design, raise control issues, and flag runaway projects. But he said: "I never saw a computer system stopped dead because internal audit issued a report." Where audit has support from other units in the organization, senior management might listen, but audit usually lacks the power to stop projects on its own.
One auditor pointed to structural problems within most organizations inhibiting internal auditors from transmitting bad news. He reported: "You're not independent enough. I mean, you're never independent, because you're in the same organization. There has to be some separation. If you report to the guy who's running the project, there's a problem with the structure, and that's why a lot of people probably wouldn't say anything" (Case #1001).
Several auditors underscored the importance of developing relationships with other units in the organization. Paradoxically, the comfort auditors feel in blowing the whistle may depend on positioning the audit function, so auditors are not viewed as whistle blowers but as team players whose job is to help keep projects on track. The following account of a whistle blowing incident by an IS auditor illustrates this point. "I think," he said, "the way we handled it made a difference. We suggested they really look at these issues. We've got some major problems, and I think just the way we came about it, as a team player instead of a policeman. And that 'We want to help you; we see that this project's out of control; we can see that maybe some things you're not getting the truth on because you're so close to it; but this is what we see.' Even though we are an independent appraisal organization, we are still part of the same corporate team, and our goals are their goals basically. We all want the company to do well. That's how we sold ourselves" (Case #182).
Thus, effective whistle blowing may depend on organizational factors, like organizational size, the historical commitment by senior management to the internal audit function, the independence of auditing from management authority, and the formation of team relationships between audit departments and the departments leading projects.
Our study found that, although whistle blowing is a noble activity carrying the organization's interest close to its heart, whistle blowers assume serious risks. Even for those charged with auditing and monitoring the progress of IS projects, job security is often more important than pressing for accountability for misspent budgets. Indeed, whistle blowing is frequently regarded as an "illegitimate" activity, even when institutionalized into a formal audit role [12]. As a result, many internal auditors remain mum instead of asserting their responsibility to report bad news.
In addition, key executives committed to IS projects can lose their objectivity, refusing to acknowledge any criticism. This was clearly the case in Helga Drummond's (of the University of Liverpool) 1989 analysis of the London Stock Exchange's Taurus project, which was designed to automate the trade-settlement process. Drummond wrote the following about the difficulty the Exchange's chief executive had convincing other key decision makers of the need to scrap the project: "These were big men . . . [yet] the plain fact of the matter is that they were terrified. 'What do you mean we might have to stop this? How can you say that now?' . . . They didn't believe it . . . They wanted to believe I was wrong. They were fighting to find some reason to carry on" [2].
Even unambiguous negative information can fall on deaf ears, as key decision makers stubbornly cling to prevailing myths about a project's importance. The potential whistle blower has to present rational information, which may be insufficient to sway mythical beliefs. Not only must the mum effect be overcome, it is also necessary to overcome the deaf effect to get troubled projects under control. Figure 1 defines four types of organizations and how they experience different degrees of the mum and deaf effects.
In the deaf-dumb-blind organization, in which both mum and deaf effects are powerful, there is little chance for whistles to be either blown or heard. Even formally established audit functions do not operate effectively. In the cover-up organization, in which the mum effect is strong but the deaf effect is weak, the game is to conceal bad news from a management that wants to hear it. (In this type of organization, nobody wants to point fingers at a peer, so there is a tendency to cover up bad news, as the group working on the project tries to protect itself and its members.)
In the ostrich organization, managers prefer being deaf, preferring to avoid learning what whistle blowers have to say. Auditors are likely to be frustrated and critical of top management and may eventually become cynical about their auditing and reporting responsibilities.
Finally, in the healthy organization, people are not afraid to transmit bad news; they see that managers are receptive to criticism and willing to do something about it. Healthy organizations are "learning organizations," because they use feedback from their own performance to correct errors.
Implications for IS professionals. No IS professional is immune from the pressures associated with troubled projects. It is difficult for IS project members to be unaware of cost overruns and delays, but they are often confused about what to do. Should they, despite their relatively low status, expose project ills, or remain mum? Although guided by codes of ethical conduct [9], IS professionals may experience great difficulty in acting responsibly at the critical moment. Nevertheless, IS professionals should look to identify which quadrant of the grid in Figure 1 best represents the climate of their organization. If it is healthy, whistle blowing should carry rewards, not penalties. Where top managers behave like ostriches, avoiding bad news, IS professionals have little incentive to convey bad news. But blowing the whistle in the ostrich organization may still be viewed as an exercise in professional responsibility and may ultimately result in some form of corrective action. The more difficult situations for the ethical IS professional are in the cover-up and deaf-dumb-blind organizations; those compelled to blow the whistle take serious risks. Whistle blowers with little job security or mobility have the most to lose and little to gain, except for self-respect.
Implications for senior executives. Fortunately, our findings also suggest ways senior executives might create healthier climates for whistle blowing. Larger organizations with more established and legitimate audit staffs, such as those in financial institutions, are likely to be healthy already in light of their historical commitment to internal control. Large IS audit staffs are more difficult to ignore than small, token units. Nothing signals the importance of whistle blowing more directly than the presence of professional staff with the qualifications and mission to audit IS projects.
Audit staffs are also likely to be more effective when separated organizationally from the authority of those whose projects are being monitored. Although IS auditors share many of the skills of other IS professionals, they should never report to CIOs or CTOs responsible for IS projects. Blowing the whistle is tough enough without having to blow it on the boss. For this reason, most audit staffs should be independent authorities.
Unfortunately, independence also makes it more difficult to establish a teamwork relationship between IS auditors and project managers. Our findings indicate that, for an IS auditor, being a team player is a more constructive metaphor than being a policeman and is perhaps the key to organizational health.
Creating a healthy climate for whistle blowing is essential for controlling software project escalation. The framework we've presented here can help both IS professionals and senior executives examine their organizations and plot a course toward the healthy-organization quadrant in Figure 1. When fiascoes like Confirm occur, many people blame the technology, but the mum and deaf effects are likely to be major contributing factors behind runaway projects. Better communication of project status, especially bad news, can reduce the incidence of software runaways.
1. Brockner, J. The escalation of commitment to a failing course of action: Toward theoretical progress. AMR 17, 1 (1992), 3961.
2. Drummond, H. Escalation in Decision-Making: The Tragedy of Taurus. Oxford University Press, Oxford, UK, 1996.
3. Glass, R. Software Runaways. Prentice-Hall, Inc., Upper Saddle River, NJ, 1998.
4. Keil, M. Pulling the plug: Software project management and the problem of project escalation. MIS Quart. 19, 4 (1995), 421447.
5. Keil, M. and Rai, A. Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Quart. 24, 4 (Dec. 1997), 631664.
6. Keil, M. and Robey, D. Turning around troubled software projects: An exploratory study of the de-escalation of commitment to failing courses of action. J. Mgnt. Info. Syst. 15, 4 (1999), 6387.
7. KPMG, Runaway projects: Causes and effects. Soft. World 26, 3 (1995), 35.
8. Mann, J. The Role of Project Escalation in Explaining Runaway Information Systems Development Projects: A Field Study, unpubl. doct. dissert., Georgia State University, 1996.
9. Oz, E. When professional standards are lax: The Confirm failure and its lessons. Commun. ACM 37, 10 (Oct. 1994), 2936.
10. Standish Group, Inc. CHAOS: A Recipe for Success, res. rep. 1999; see www.standishgroup.com.
11. Tesser, A. and Rosen, S. The reluctance to transmit bad news. Adv. Experi. Soc. Psych. 8 (1975), 193232.
12. Weinstein, D. Bureaucratic Opposition: Challenging Abuses in the Workplace. Pergamon Press, New York, 1979.
©2001 ACM 0002-0782/01/0400 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.
No entries found
Table. Projects studied.