Printer Friendly

When professional standards are lax: the CONFIRM failure and its lessons.

In 1988, a consortium comprised of Hilton Hotels Corporation, Marriott Corporation, and Budget Rent-A-Car Corporation subcontracted a large-scale project to AMR Information Services, Inc., a subsidiary of American Airlines Corporation. The consulting firm was to develop a new information system (IS) called CONFIRM, which was supposed to be a leading-edge comprehensive travel industry reservation program combining airline, rental car and hotel information. A new organization, Intrico, was especially established for running the new system. The consortium had grand plans to market the service to other companies, but major problems surfaced when Hilton tested the system. Due to malfunctions, Intrico announced an 18-month delay. The problems could not be resolved, however, and three-and-half years after the project had begun and a total of $125 million had been invested, the project was canceled.

In a letter to employees, Max Hopper, American Airlines Information Services chief, wrote: "Some people who have been part of CONFIRM management did not disclose the true status of the project in a timely manner. This has created more difficult problems--of both business ethics and finance--than would have existed if those people had come forward with accurate information. Honesty is an imperative in our business--it is an ethical and technical imperatives." Apparently, the clients were misled into continuing to invest in an operation plagued with problems in database, decision-support, and integration technologies [7].

Undoubtedly, software developers, as experienced as they may be, may legitimately run into technical difficulties. The questions we, as IS professionals, should ask are: does a failure of this magnitude have to happen? If the developers realize they are facing technical problems, should they notify the client? How severe should the difficulties be to warrant alerting the client? If management does not share information with the client, are the individual members of the project team expected to blow the whistle?

These questions should be addressed by professional codes of ethics and standards of conduct. The purpose of this article is to present the case and examine how IS codes of ethics address the issues raised. We will also try to draw practical lessons for providers of IS services and their clients.


In 1987, a potential market caught the attention of AMR: centralized hotel reservations. As the company discovered, only 20% of hotel reservations were made through a centralized service, while in the airline business 80% of the reservations are made through a central system like AMR's SABRE. The company decided to take advantage of this situation in the form of a new, comprehensive system.

CONFIRM was the name given to an IS that was supposed to be the most advanced reservation system in the combined industry of travel, lodging, and car rental. The clients relied on the professionalism of the specialists who developed the highly successful airline reservation system SABRE. SABRE was a classic example of how an IS can gain strategic advantages for its user organization.

There are more than 85 hotel companies in North America. The major national hotel chains are Marriott, Hilton, Hyatt, Westin, and ITT Sheraton. The ease with which travelers can make reservations is vital to this industry. Over the past 16 years, each of these chains acquired a computer-based reservation system. The systems provide information to travel agents throughout the world. Some chains developed their own systems; others had vendors develop their systems. The systems varied in efficiency and effectiveness. For example, Marriott's MARSHA has been recognized as one of the best in the industry, while Hilton's NORTH dated from the early 1960s, and was inadequate and inefficient.

Like the major hotel chains, air-lines, too, have acquired reservation systems. The most notable are SABRE and APOLLO. SABRE was developed by AMR, the parent of American Airlines Corporation; APOLLO was developed by United Airlines Corporation. The former has gained acclaim as the world's most successful airline reservation system. The system was installed in 1976 and has since been continually upgraded.

In 1986, AMR formed AMRIS, the information systems arm of the corporation. AMR's chairman hired Max Hopper to head AMRIS and offered him "a chance to combine running the SABRE business ... and expanding it into other businesses, really leveraging it." AMRIS was to exploit its success with SABRE for business in other areas. But, unfortunately, the success of one system does not always guarantee the good fortune of a more advanced system. What follows is the chronicles of the events that led to the CONFIRM "disaster." The information is taken from media reports and the lawsuit filed by Marriott [15].

The CONFIRM Chronicles

On March 13, 1987, AMRIS representatives made a presentation to Marriott executives about a new reservation system they were preparing to develop. The system, named CONFIRM, would be superior to any existing reservation system in the industry. The representatives claimed it would be a state-of-the-art reservation system meeting all business needs of hotels and car-rental partners in the joint venture. According to the proposal, AMRIS, as a managing partner, would be in charge of the design and development of the system. The hotels would pay for this effort and would input the necessary data.

The partners, hotels and car-rental businesses, would use the system for their daily operations. In addition, they would join AMR in an effort to market customized versions of the system to other hotel and car-rental companies for profit. AMRIS was to operate the data processing center of the system.

From May through August of 1987, Marriott and other potential partners met with AMRIS executives to negotiate the deal. AMRIS people repeatedly assured the partners that CONFIRM would be superior to any current reservation system, while not more costly to use. They also promised that the project would be completed in time to outpace the competition in the hotel and car-rental industries.

On September 2, 1987, Marriott, a major partner in the venture, agreed to consider the AMRIS proposal although it already had an excellent system. The company's vice-president emphasized: "Marriott is pleased with its current reservation system ... we have one of the best reservation systems in the industry in terms of both functionality and cost." Thus, he said his company would join the venture if "the joint venture can develop a reservation system that is functionally richer than the system we intend to operate [and that Marriott costs] will be less than the costs to operate our proposed system."

The first three partners to the joint venture were Marriott, Hilton, and Budget Rent-a-Car. In October 1987, they formed a consortium and named it Intrico. In late 1987 and early 1988, technical representatives from the four partners started to plan detailed performance capabilities of the new system. On May 24, 1988, AMRIS issued a press release announcing the commencement of the CONFIRM design process. In the meantime, the Intrico partners funneled large sums of money into the project. By September of 1988, Marriott alone spent more than $1.45 million on the preliminary design.

In September 1988, after a year of negotiations, Marriott, Hilton, and Budget signed a partnership agreement with AMRIS. According to the agreement, the objectives of the joint venture were:

* to design, develop, operate, and maintain a new "state-of-the-art" reservation-processing system to be marketed worldwide;

* to design and develop "interfaces" with airline computer reservation systems so consumers could make airline, hotel and car rental reservations through a single, computerized system;

* to market the reservations system and other communication services to customers for a profit; and

* to convert each of the partners' reservation systems to the newly-developed system.

AMRIS was designated "Managing Partner, Development" of CONFIRM. The agreement made the company responsible for all aspects of the design and development of the new system. The four partners undertook to pay AMRIS $55 million for the development. Each partner was to appoint a professional team that would be stationed in Dallas, at AMRIS headquarters, so that the partners would provide input as to what functions were needed, and also test and evaluate the system as it was developed.

The agreement stated two phases: the design phase and the development phase. The design phase was to take seven months, and the development phase was to be completed within 45 months after the agreement was signed. Thus, the deadline was the end of June 1992.

The contract provided that the total expenditure to develop CONFIRM would not exceed $55.7 million. AMRIS warranted that it had "no reason to believe" that the development costs would exceed this amount. The company also undertook to develop the system so that operation costs would be limited to $1.05 per reservation.

On December 30, 1988, AMRIS presented a "base design" of the system. Marriott claimed the functional specifications were not adequate. A 1992 internal audit by AMR's SABRE personnel stated that "these documents describe the expected functionality in general terms; they do not provide sufficient detail for a developer to understand what the user is expecting."

In March 1989, AMRIS declared the functional and technical specifications were complete. Late that month, the company circulated a preliminary development plan. The plan was unacceptable to the partners. The next six months were devoted to revision of the plan. During this time, AMRIS executives reassured the partner's that the system would comply with all the requirements, and that it would be ready on time.

AMRIS completed the design phase in September 1989 and circulated a proposed development plan for the partners' review. At this time, the company increased the price of the project from $55.7 million to $72.6 million. It also stated that the cost per reservation would be $1.30 (instead of the original $1.05) in the first year of full operation, and decline to $0.72 and $0.40 in the fourth and fifth years, respectively.

According to the partnership contract, the three client-partners could withdraw when the development plan was presented. (A penalty of $1 million was involved.) The partners had to make the decision at this point. The per-reservation cost was crucial information in their decision-making.

On August 8 and August 15 of 1989, AMRIS representatives met with those of Marriott, Hilton, and Budget to review AMRIS' pro forma financial statements. Two years later, in August 1991, Marriott found that the statements were false. AMRIS understated the costs of personnel and other operating costs. The company also used numbers that overstated the total number of reservations. The actual processing cost per reservation was then estimated at $2.00.

Based on these statements, the client-partners decided not to exercise their option to withdraw. To Marriott, for instance, the value of the project declined by $1 million, but still promised a net present value of more than $3 million. In September 1989, the partners accepted the development plan. The deadline was revised from June 1992 to July 1992.

The contract outlined four major development phases: the business area analysis (BAA) to develop business models; the business system design (BSD) to enumerate detailed descriptions of the application systems; construction of the system's code (construction), and testing activities (testing).

On October 16, 1989, AMRIS assured the partners that the project was on time and on budget. However, in January 1990, the company missed the contractual deadline of completing the terminal-screen design. In February 1990, AMRIS missed the completion milestone of the BAA phase. Apparently, the developers redefined the unfinished work of this phase to become a part of the next phase.

In February 1990, AMRIS admitted it was more than 13 weeks behind schedule, but claimed it could catchup and recapture much of that lag. In March 1990, the company began a six-week "replanning" effort.

Millions of dollars kept flowing into the project. On May 15, 1990, AMRIS made a presentation to the partners saying the project was still on time and that the system would be ready by its deadline. At the same time, major players in the development effort were chastised for delays.

During the summer of 1990, both Budget and Marriott expressed concerns that the project was behind schedule and that its management was ineffective. While employees at the project office estimated CONFIRM would not be ready in time, they were instructed by management to change their revised dates so that they reflect the original project calendar. In August of that year, AMRIS declared the first phase complete, and entered the second major phase (BSD). When Marriott representatives asked to see some "deliverables" of the completed phase, the developers refused to show or explain their status. In October, the company admitted to the partners it was one year behind schedule. But company executives claimed they would still meet the deadline.

In February 1991, AMRIS presented a "Re-Plan" to replace the original development plan. According to the Re-Plan, only Hilton would be using the system by June 1992, and Marriott would not receive all the features it was promised before March 1993. Marriott later claimed that AMRIS executives knew they could not meet the new schedule. The hotel company said AMRIS forced employees to artificially change their timetable to reflect the new schedule, and that those who refused either were reassigned to other projects, resigned, or were fired. The Re-Plan attached a new price tag: $92 million, far above the original $55 million and the previously revised $72 million. The AMRIS president resigned in October 1991, and during the end of that year and the beginning of 1992 about 20 additional employees resigned.

AMRIS employees were dissatisfied with the way management handled the project. They believed their managers kept stating unrealistic schedules and lied about the project status. Many realized the "schedule" could not be met even with nine-hour workdays and work on weekends. By the summer of 1991, about half of the people assigned to CON FIRM (slightly more than 180 employees) were looking for new positions. A consultant was hired by AMRIS to evaluate the project. Dissatisfied with his findings, a vice-president "buried" the report and dismissed the consultant.

An evaluation by Marriott concluded that the developers could not complete the project. However, the hotel chain still gave them a chance: "As a partner, we hope that you will be able to perform as promised. However, as a user, we do not, based on experience to date, believe you can" [15]. AMR, the developers' parent company responded that CONFIRM's development was on target and that the system would be fully functional. AMRIS continued to bill Marriott at a rate of more than $1 million per month.

Finally, in April 1992, AMRIS admitted it was approximately two to six months behind schedule. Like Marriott management, Hilton management was still hopeful that "whatever has been broken can be fixed to meet the original schedule" [15]. But there was no basis for these hopes. That month, major problems surfaced when Hilton tried the system as CONFIRM's first beta-test user [7]. On April 29, 1992 the AMRIS chairperson wrote to the three partners:

"Unfortunately, things have not gone as planned. Specifically: (1) The individuals whom we gave responsibility for managing CONFIRM have proven to be inept. Additionally, they have apparently deliberately concealed a number of important technical and performance problems. (2) The technical staff, while skilled, has failed in the construction of the very demanding interfaces between the systems, and the extensive database, which will both be part of the completed CONFIRM system. The bottom line, gentlemen, is that in our best current judgment the system is 15 to 18 months from completion ...[15].

The company promised to repay 100% of the investment to any partner who wished to withdraw from the joint venture. A senior officer of AMRIS blamed employees for lying and the project management of concealing problems. The project, he said, was actually two years behind schedule.

On April 28, 1992, AMRIS fired eight top executives and replaced another fifteen employees. On May 1, 1992, the company's vice-chairperson circulated a letter to employees acknowledging that CONFIRM's "system interfaces and databases are inadequate to providing the necessary performance and system reliability." He explained:

Our CONFIRM RS problem has many roots--one more serious than the other. Some people who have been part of CONFIRM RS management did not disclose the true status of the project in a timely manner. This has created more difficult problems--of both business ethics and finance--than would have existed if those people had come forward with accurate information [15].

In July 1992, after three-and-a-half years, and after spending $125 million on the project, the Intrico consortium disbanded. Technically, the developers' main problem was to tie CONFIRM's transaction-processing facility-based central reservation system with its decision-support system. AMRIS's president admitted: "We found they were not integratable." Also, it was later discovered that the database was irrecoverable in the event of a crash.

Apparently, some of the failure is due to bad management practices of all the four partners in the Intrico consortium. The client-partners teams met with the developer's representatives just once a month. An AMRIS executive said: "You cannot manage a development effort of this magnitude by getting together once a month. Had they allowed the president of Intrico to function as CEO in a normal sense and empowered their senior reps [to] work together with common goal and objective, it would have worked" [10].

AMR filed a countersuit against Marriott, Budget, and Hilton in September 1992. On May 14, 1993, AMR amended its suit to suggest that its partner-clients changed an approved plan to determine specifications for the common reservation system. Instead of a single system, AMR claims, the developers were encouraged to create three individual systems trader CONFIRM. The company accused its clients of being "selfish" [11]. By January 1994, AMRIS had reached out-of-court settlements with all of its partners for undisclosed amounts. Some sources say the firm was facing damages suits of more than $500 million, and therefore agreed to pay about $160 million [18].


The CONFIRM case is likely to reverberate for a long time because of the huge investment that was lost in the effort to develop the system. This is not, however, the first colossal failure to develop an IS. For example, in 1988, the Bank of America's trust investment system, TrustPlus, was scrapped after insurmountable difficulties of the developer, a private consulting firm, and the Bank's staff to resolve program errors. The bank spent $20 million on the development project and another $60 million on trials to fix it. Consequently, the bank sold its trust portfolios to other banks and withdrew from this lucrative business altogether [3].

Software development failures are not rare occurrences. According to one survey, an astonishing 75% of all system development undertaken is either never completed or the resulting systems are not used [5]. Unfortunately, despite the great impact of such incidents on society and businesses, the topic has not been studied methodically. The reason may be the paucity of objective data. Therefore, we have to rely on anecdotal information when discussing this important issue.

Clearly, journalistic accounts of these cases tend to be simplistic and to highlight the sensational. Also, lawsuits tend to emphasize the other party's failures to comply with the contract, rather than to outline the subtleties of interaction between the parties. Thus, the reader should not take every claim, by either party, at face value. Also, the lack of industry-wide reliable data does not allow us to compare this case to general industry practice. In sum, there is very little reported research on the topic. It is in this light that we have to consider the case.

The quoted words of the AMRIS president raise the issue of managers' unethical conduct. Robert Jackall [12] and other writers on the subject of business ethics indicate that Milton Friedman's assertion that the social responsibility of corporations is to maximize the profit for their stockholders [4] has proved itself realistic. Or, at least, that is what corporate managers think is their responsibility. But should this be at the expense of professional integrity?

No one in their right mind would accuse a respected software developer of deliberately hindering his own effort. A project may be plagued with technical problems that were not anticipated before the project began. But one suspects that unprofessional behavior might have contributed to the mishap. Before we discuss "professional behavior" as it relates to this and similar cases, let us examine our status as "professionals."

Who is a professional? A professional is an expert whose services are required because of increasing technological or other specialty demands [2]. Individuals and organizations seek the services of professionals because professionals are assumed to have knowledge far beyond that of lay people. Individuals and corporations trust their interests to professionals. While some people debate the label "computer professional" (especially because of the variety of occupations within this broad term), software developers usually consider themselves professionals. In fact, their responsibilities may be more comprehensive, and therefore may require them to be more careful about their conduct, than other, more traditional professions.

Mylott equates computer professionals to other professions: "In the services they perform, computer professionals most resemble a combination of accountants, architects, and engineers. Like architects and engineers, computer professionals create specifications and supervise the implementation of specifications. Yet, while architects and engineers rarely construct the buildings they have designed, computer professionals usually create the object of their specifications; they write computer software and propose combinations of hardware and software to purchasers. In order to develop computer software and to assemble configurations of computer hardware and software, computer professionals, like accountants, often perform financial and business analysis" [14].

Deborah Johnson [13] suggests that professional codes of ethics address these four types of obligations:

1) obligations to society, 2) obligations to employer, 3) obligations to clients, and 4) obligations to colleagues and to professional organizations.

In cases like CONFIRM, obligations 2), 3), and, to a certain extent 3), are at issue. When professionals are employed by a corporation they are faced with two sets of standards used to evaluate their behavior, and the two are not always mutually compatible. Professionals are faced on the one hand with the standards of the organization that dictate success in terms of organizational goals; and on the other hand, they are faced with the standards of their professions [2]. In cases like the CONFIRM project, at least some employees noticed that not all was well. If their superior does not act to remedy the failure or inform the client, then they are faced with a dilemma: they have to choose among the interests of the employer, the well-being of the client, and their obligation to the profession.

What do professional organizations expect of computer professionals? Each professional organization has its own code of ethics. However, all, in one way or another, expect the member to honor the above four types of obligations. The codes of the ACM, DPMA, BCS, ICCP, CIPS, and ITAA and the analysis thereof are detailed in [17]; for a summary of the codes' principles see [16].

One important obligation to the public at large and to clients in particular is to avoid misrepresentation of information technology (IT). The DPMA (Data Processing Management Association) Standards of Conduct, require members "not [to] misrepresent or withhold information concerning the capabilities of equipment, software or systems." The ACM Code of Ethics and Professional Conduct mandates that the organization's members "ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements" (Clause 3.4). The ICCP (Institute of Certified Computer Professionals) Code of Ethics decrees: "One shall not make false or exaggerated statements as to the state of affairs existing or expected regarding any aspect of information technology or the use of computers" (Clause 3.4). Other IS professional organizations in the U.S. and other countries (e.g., Canadian Information Processing Society and British Computer Society) expect similar behavior of their members.

Most professional organizations require their members to disclose limitations of the systems they develop. For example, the ACM code mandates: "Honesty is an essential component of trust. Without trust an organization cannot function effectively. The honest computing professional will not make deliberately false or deceptive claims about a system or system design. He or she will offer full disclosure of all pertinent system limitations and problems" (Clause 1.3), and the ICCP code reads: "The personal accountability of consultants and technical experts is especially important because of the positions of unique trust inherent in their advisory roles. Consequently, they are accountable for seeing to it that known limitations of their work are fully disclosed, documented and explained" (Clause 2.7).

Typically, development ventures involve risk. Development of IS is not different. We cannot expect project leaders to make the client aware of every mishap along the development effort. Often, the developers face obstacles that are eventually overcome. How far should the developers go in their effort to overcome a major problem without notifying the client? Obviously, this is a question of professional judgment. If the project leaders feel that the problem is grave enough to jeopardize time and money constraints, they should immediately inform the client. They should certainly do so if they believe that the product is completely unattainable.

When employees develop the system, it is their obligation to inform the employer, that is, management. Management, then, has to disclose the information to the client. Most professional codes of ethics in the IS field do not require the individual IS professional to make a preference between obligation to the employer and obligation to the client. In fact, some codes even mention the employer and the client in the same clause. For example, the ICCP code reads: "Certified computer professionals have an obligation to serve the interests of their employers and clients loyally, diligently and honestly," and the ACM code lumps the employer and the client together in some of its directives (e.g., clauses 2.5 and 2.6). Thus, the employed professional may face a dilemma in choosing between the interests of these two parties.

Management, on the other hand, is not faced with this dilemma. Management has an obligation only to the client. The ITAA (Information Technology Association of America), an association of companies engaged in the development of IS products and services, clearly requires the member organization (and the organization's employees) to prefer the client to other parties: "The judgment of a "professional services company and its data processing practitioners should be exercised solely for the benefit of a client and free of compromising influences. Neither the interest nor the desires of any other party should be permitted to alter objectivity and independence when rendering recommendations in a professional situation or climate" (Basic Principle #1). Since AMRIS is a member of ITAA, the company is expected to follow this principle.

The code anticipates hardships in development projects and prescribes what the company (read: management) should do: "If unforeseen circumstances make completion unreasonable, the professional services company or data processing practitioner should be prepared to make just and appropriate compensation to the client."

What can we learn from CONFIRM and similar cases? Experience shows that one or a combination of the following occurrences are the reasons for failure to develop a satisfactory IS:

1) Unforeseen and insurmountable technical difficulties;

2) Underestimation of cost and completion dates;

3) Failure of the developers to understand the system's requirements, or changing the requirements after the project started.

In its countersuit AMRIS claims the project failed because of the clients' demand to make changes long after the project started. What really happened and who is culpable in the CONFIRM case will probably never be determined. It may well be that all of the three reasons contributed to the failure. However, it seems that much of the damage in CONFIRM-like cases can be avoided with several simple principles. One could immediately see the relationship between the aforementioned codes of ethics and professional conduct, and the following principles.

Principles to Minimize the Damage in IS Development Failure

Principles for Managers of the Service Provider.

1) In the business of software development, you always know when you start a project, but you never know when you will complete it. The consultant responsible for Bank of America's TrustPlus boasted he could complete the system by 1983. Attempts to salvage the system continued until 1988 [3]. When outlining the project schedule, be realistic and include an adequate "slack" time. Technical and other problems may occur. Problems often occur when a project involves interfacing two or more IS. Trying to entice the client with an unrealistically short schedule is not only unethical, but may eventually hurt your own effort.

2) When the phases must be sequential to assure quality, never start phase n before you resolve all of the problems of phase n-1, and avoid shortcuts. AMRIS left bugs to be resolved at a later time, while it went on with the next phase. Reports of other large-scale development failures point out similar practice. One former executive of Bank of America said: "There were still bugs, but the users felt they could run with it and work out the bugs as we went along" [3]. You should view the project plan as a part of the contract with your client, even if it is formally not. The client counts on you to manage the project to your best professional ability. Failure to do so betrays the client's trust.

3) Executives should not make any "calming" statements about the project status before they learn the facts. Making uncorroborated statements is not only unethical to the client; it may also send wrong signals to employees.

4) Adopt a Code of Professional Standards and communicate it to your employees. The code should detail what an employee is to do when experiencing a persistent problem with systems under development, to whom he or she should report the problem, and what steps he or she should take if immediate supervisors are not responsive to complaints. A clear policy ensures that both managers and their employees know what is expected of them, and fosters more ethical behavior.

5) Most important: being dishonest may hurt your client, but it may also hurt you and your company. The financial impact of lost business because of a failure due to lies may prove much greater than the lost income from a single mishap. If it is not the monetary gain that drives your judgment but the reluctance to admit professional weakness, think again. Failure to disclose the real status of the project to the client may exacerbate the damage. Unfortunately, honesty is not always one's economic sell-interest. Often, there is economic incentive to lying (e.g., when the transaction is a one-shot deal and if information of the incident does not spread [1]). But in this age of fast communication, especially in the IS industry, the news will travel fast. And your own employees may follow the bad example: they will lie to their superiors.

Principles for Employees.

The first to observe technical problems are, usually, the employees: systems analysts and programmers. Employees have an obligation both to their employer and the client. When you realize there is a persistent problem, notify your supervisor. One wonders how long it took until the first employee stepped forward and did so in the CONFIRM case. However, some employees did complain about the technical problems--several of them paid for this with their jobs.

Principles for Clients.

1) It seems that the three partner-clients kept loose vigil over AMRIS. This is surprising due to the fact that they had liaison teams that were supposed to keep track of the project progress. It is tempting to rely on a company that demonstrated success with another system. But this is not the same system. Previous success does not guarantee success with the system that is developed for you. Check the status of the project periodically. If you do not have qualified personnel, hire an independent consultant to do that for you.

2) In a suit filed by AMRIS against Marriott, Hilton and Budget Rent-a-Car, the plaintiff complained that the three client-partners in the Intrico partnership missed a deadline for providing a clear definition of system functionality [8]. Communicate to the developers exactly what your requirements from the new system are. You must realize that later modifications may result in a higher price and a later completion date.

3) Pay attention to alerting signals. When executives and other employees of the developer are either massively dismissed or voluntarily look for new positions, ask questions. When the rats abandon the ship, it is probably sinking.


A word of caution before we conclude: as pointed out several times in this article, there is no conclusive data from which to draw hard conclusions about reasons for failure in systems development. Ideally, we would collect data on a large number of cases and find patterns. For obvious reasons, such data are extremely difficult to come by, if not impossible. However, it seems that the CONFIRM case contains many ingredients that are common in cases that have been reported in the media and trade journals.

An ancient proverb says: "You are a wise person if you do not make mistakes; you are a clever person if you make a mistake but do not repeat it; you are a stupid person if you make a mistake and repeat it." It may be hard to be wise the first time around, but let us not be stupid, either. As professionals, we are expected to learn from our own and our colleagues' mistakes.

The CONFIRM case draws attention because of the magnitude of resources expended. It is also a case of what seems to be the result of miscommunication at best or grand deception at worst. But there is reason to believe it is only one of many such cases. To minimize the probability of such mishaps, IS organizations have to adopt detailed codes of professional standards. The codes should outline to both managers and employees how to behave when projects do not proceed as expected.

Large development projects rarely proceed exactly as planned. This is true of IS development efforts as well. Management should be deeply involved in the progress of large-scale projects. If the professional team cannot overcome difficulties to comply with promised cost and timetable, it is the professionals' responsibility to duly report to management; then, it is management's responsibility to disclose the difficulties to the client and mutually outline a resolution.

Of course, there is no point in promoting a code of ethics and professional standards if executives do not demonstrate personal example. If not for reasons of moral obligation, at least for utilitarian principles, IS organizations should be honest with their clients. In the long run, honesty, indeed, is the best policy.


I thank Blake Ives for bringing this case to my attention. I am also indebted to my students Marsha Klopfer and Ken Horbatiuk for their assistance.


1. Carson, T.L. and Wokutch, R.E. The moral status of bluffing and deception. In Robinson, W.L., Pritchard, M.S., and Ellin, J., Eds., Profits and Professions. Humana Press, Clifton, N.J., 1993, 141-155.

2. Donaldson, T. Accountability and the bureaucratization of corporations. In Robison, W.L., Pritchard, M.S., and Ellin, J., Eds., Profits and Professions, Humana Press, Clifton, N.J., 1993, 215-224.

3. Frantz, D. B of A's plans for computer don't add up. Los Angeles times, February 8, 1988. Reprinted in Dunlop, C., and Kling, R., Eds., Computerization and Controversy: Value Conflicts and Social Choices, Academic Press, Boston, Mass., 1991.

4. Friedman, M. The social responsibility of business is tn increase profit. The New York Times Magazine. (Sept. 13, 1970).

5. Gladden, G.R. Stop the life cycle, I want to get off. Softw. Eng. Not. 7, 2 (1982), 35-39.

6. Halper, M. Outsourcer confirms demise of reservation coalition plan. Computerworld 26, 31 (Aug. 3, 1992), 1.

7. Halper, M. IS cover-up charged in system kill. Computerworld 26, 32 (Aug. 10, 1992), 1.

8. Halper, M. AMR sues partners over failed venture. Computerworld 26, 40 (Oct. 5, 1992), 1.

9. Halper, M. Marriott suit damns AMR role in CONFIRM. Computerworld 26, 41 (Oct. 12, 1992), 1.

10. Halper, M. Too many pilots. Computerworld 26, 41 (Oct. 12, 1992), 8.

11. Halper, M. AMR calls CONFIRM partners selfish. Computerworld 27, 21 (May 24, 1993), 4.

12. Jackall, R. Moral Mazes: The World of Corporate Managers. Oxford University Press, New York, 1988.

13. Johnson, D. Computer Ethics. Prentice-Hall, Englewood Cliffs, N.J., 1985.

14. Mylott, T.R. III. Computer professional malpractice. Santa Clara Computer and High Technology Law Journal, 2 (1986), 239-270.

15. Suit: Marriott v. AMR, filed with the Circuit Court for Montgomery County, Maryland (Case No. 96336), September 26, 1992.

16. Oz, E. "Professional Standards for Information Systems Professionals: A Case for a Unified Code of Ethics", MIS Quarterly 16, 4 (Dec. 1992), 423-433.

17. Oz, E. Ethics for the Information Age, Wm. C. Brown, Dubuque, Iowa, 1994.

18. Zelner, W. Portrait of a project as a total disaster. Business Week. (Jan. 17, 1994), 36.

EFFY OZ is an assistant professor and coordinator of the MIS program at Wayne State University. Current research interests include the impact of information technology on decision-making and computer ethics. Author's Present Address: Department of Accounting, School of Business Administration, 207 Rands House, Detroit, MI 48202-1222; email: effy_oz
COPYRIGHT 1994 Association for Computing Machinery, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1994 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:information systems development
Author:Oz, Effy
Publication:Communications of the ACM
Article Type:Product/Service Evaluation
Date:Oct 1, 1994
Previous Article:Mobile wireless computing.
Next Article:Turing Award lecture: on computational complexity and the nature of computer science.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters