IS Development and Implementation in a Business Context

Winter exam, December 2014

___________________________________________________________________________

Full name and study programme (IM/BI) of the

group members: (COMPLETE IN BLOCK LETTERS)

BOBBY BRIX PEDERSEN IM

LIWEI CHEN BI

Written Group Project

Information Systems Development - The CONFIRM Project: A Case Study with an

Agile Perspective

_______________________________________________________________

Your group report has to be handed in

on 15 December 2014 before 12:00 noon on WISEFLOW

AARHUS UNIVERSITET BUSINESS AND SOCIAL SCIENCES

INSTITUT FOR MARKETING OG ORGANISATION

Table of Content 1 Introduction ................................................................................................................................... 4

1.1 Problem Statement ........................................................................................................................... 5

1.2 Delimitaion ........................................................................................................................................ 6

2 Research Method ........................................................................................................................... 6

2.1 Data Collection .................................................................................................................................. 7

2.1.1 Scientific articles ........................................................................................................................ 7

2.1.2 Books ......................................................................................................................................... 7

2.1.3 Other sources ............................................................................................................................ 8

2.2 Structure of the paper ....................................................................................................................... 8

3 Theory ............................................................................................................................................ 9

3.1 The evolution of Development Methodologies ................................................................................ 9

3.2 The Agile Principles .......................................................................................................................... 10

3.3 Traditional vs. Agile Development................................................................................................... 12

4 Case Description ........................................................................................................................... 13

4.1 Overview .......................................................................................................................................... 13

4.2 Timeline ........................................................................................................................................... 14

4.3 Problems of the CONFIRM project .................................................................................................. 15

5 Categorization of CONFIRM problems ........................................................................................... 17

5.1 Goals ................................................................................................................................................ 19

5.2 Economic issues ............................................................................................................................... 21

5.3 Self-Image ........................................................................................................................................ 21

5.4 Code and Ethics ............................................................................................................................... 22

5.5 Technical issues ............................................................................................................................... 22

5.6 Process Features .............................................................................................................................. 24

6 The Confirm problems with an agile perspective ............................................................................ 25

6.1 Suitable changes for the CONFIRM project ..................................................................................... 27

7 Conclusion .................................................................................................................................... 33

8 References ................................................................................................................................... 34

9 Appendix ...................................................................................................................................... 38

List of tables

Table 1 – Timeline (Ozzy 1994, Clark 2013, Ewusi-Mensah 2003) ................................................. 15

Table 2 - Reconstructed from Lyytinen (1987) ................................................................................. 18

Table 3 - Categorized CONFIRM problems ...................................................................................... 19

List of Figures

Figure 1 - Source: Flowers (1997) Structure of CONFIRM project ................................................. 24

Figure 2 - Ramasubba et al. 2011 - Nested cycles of software process ambidexterity ...................... 32

Side 4 af 39

1 Introduction

Nowadays, information systems are the foundation and competitive necessity for conducting

business as companies rely heavily on the capability of the information systems in terms of

processing data from various sources and generating useful and accurate information that facilitate

the daily operation. An increasing number of organizations have realized that developing

information system is not only about applying Information Technology for the organization, but

also managing the people, activities and other processes that together form the system.

Nevertheless, from a historical perspective the failure rate of developing IS project is high,

especially in large projects and project in public sector. Heeks (2008) found that 35% of e-

government projects were total failure, while 50% were partial failure and only 15% were

considered successful. Dorsey (2000) in his Top 10 reasons Why Systems projects Fail pointed out

that 50%-80% of the large IS projects fail. Similarly, a study conducted by Gheorghiu (2006) also

indicated that 70-80% of the information technology and system in the company fail. After having

reviewed the article about infamous failure of IT and IS projects, it further confirmed that most of

the failure projects are public sector projects and almost all the projects are quite large with the

losses over 100 million. Interestingly, the timeline of these failure projects showed that most of the

failures happened in the late 1980s until the late 1990s. During that time period, two groups of

methodologies were most adopted by companies and organizations in developing information

systems- structural and object methodologies (Tumbas & Matkovic, 2006). The former, which is

known for its sequential and plan-based development style, is still widely applied by many

organizations today especially in public sector, where strict regulations and standard procedures as

well as clarity in procurements, etc are required. The latter which is based on iterative and

incremental development of information systems, has become even more popular in the 21st century

when it evolves into the agile methodologies (Tumbas & Matkovic, 2006).

Among the 10 classic project failure cases, the CONFIRM project interests the writers most. There

are several reasons that motivate the authors to choose this case. First, as mentioned before, the

requirements and restrictions of developing an IS project in public sector make it hard to apply non-

structured methodologies. In the CONFIRM project, unlike other projects, the stakeholders

involved in the project were all private companies, which gives more flexibility. Second, the

problems occurred in the CONFIRM project had a strong connection with development process.

Side 5 af 39

The project was not even implemented when the project was canceled. Last but not least, the project

started in the late 80s and was abandoned in 1992. This period was the period where structured

methodologies were quite mature while the object methodologies and incremental development just

emerged. The CONFIRM project existed under such background where changes in the system

development methodologies had happened but adoption rare by the companies quite rare especially

for large projects (Iivari & Maansaari, 1998).

In this study, the authors will focus on the IS development processes and methods in the CONFIRM

case. Furthermore, the authors fully realized the limitations regarding the IS development

methodologies during that period of time. However, given the fact of the popularity and advantages

of agile methodologies in current era, it would be interesting to discuss the problems in the case

combining with agile thinking and principles to see if some of problems would have been avoided.

1.1 Problem Statement

This paper seeks to answer the following problem statement

Evaluate the CONFIRM project by categorizing the problems and discuss suggestions for change

and thereby derive a more suitable development approach for the CONFIRM project.

To better answer for overall problem statement a two sub questions are stated.

Sub questions:

What are the problems during the development phase of the CONFIRM project?

How could the problems in the CONFIRM project have been avoided?

The first sub question are answered in section 4 as a part of the case description where the problems

in the CONFIRM project are stated. The second sub question will be answered in section 5 which is

the analysis through a categorization and evaluation of the problems based on the agile principles.

Side 6 af 39

1.2 Delimitaion

This paper will be focusing on agile theories and how the principles in agile could have helped the

CONFIRM project. The agile principles presented in the agile manifesto and presented by Fowler et

al. (2001) will be used as the primary theory and generate arguments and suggestions for change in

the CONFIRM project. The thoughts of traditional methodology will be used to ensure a that the

discussion of changes contains the best of both methodologies for the CONFIRM project.

2 Research Method

An explanatory case study approach has been chosen for this project to best research and answer the

presented research question. Secondly this is a single case study where the CONFIRM project from

1989 will be evaluated. The chosen case study is approximately 25 years old which means that there

will be some delimitation in the possible data gathering regarding the CONFIRM project. A broad

variety of information has been used for this paper and the validity of the information can

sometimes be questioned but to ensure validity off the information regarding the CONFIRM project

triangularization will be used to ensure the problems we find in the CONFIRM project are shared

and valid problems highlighted and mentioned in different articles in the last 25 years.

Triangularization is a way to combine different statements or methods to enlighten the same

subject and thereby increase validity (Appendix - table 1). This approach is considered a useful

technique when doing an explanatory case study (Naresh et al. 2011). This serves as the best

possible way of choosing problems for the analysis and the following discussion. The validity of

data sources will be further discussed in the underlying section as a part of the source criticism.

According to Ole Riis data collected for a paper can be divided into two groups, Primary data and

secondary data. Primary data consist of data from understandings based on ex. interviews or

observations where secondary data consist of information from other people such as scientific

articles and textbooks (Riis 2003). This paper will only consist of secondary data which will be

elaborated in the following section. Secondary data is our only source of information because the

CONFIRM project is approximately 25 years old and it is therefore near impossible to find

respondents to interact in interviews regarding the project. The use of secondary data as only

Side 7 af 39

source for this paper requires a rational source criticism to ensure that the data used in this paper are

substantial and valid for use.

In the following section the chosen literature will be discussed in regard of the different categories

of data used in this paper.

2.1 Data Collection

2.1.1 Scientific articles

The primary source for this paper is scientific articles published by different academic journals.

Most of the scientific articles are part of the curriculum and therefore handed over in class and

therefore valid sources for this paper. Other articles not expressed in the curriculum are found

through databases at AU library which also secures validation.

These articles used in this paper mainly descriptive and explanatory regarding agile development

and traditional development which provides the foundation for analyzing the problems in the

CONFIRM project. One of the articles are a case study regarding the CONFIRM project that tries to

establish a much needed context for the CONFIRM project. This case study are, amongst others,

some of the data used to establish common understanding of the context and the problems within

the CONFIRM project.

The scientific articles used in this paper are all considered valid based on the fact that they are all

published by known academic journals found in the au library databases or Google scholar.

2.1.2 Books

Information Systems Development: Methods in action by Fitzgerald et al. (2002) are part of the

course curriculum and are used as common inspiration and understanding of the different subjects

mainly within agile development.

Side 8 af 39

This book is considered valid sources for this paper given the fact that they are part of course

curriculum in different courses at Aarhus Business and Social Sciences within the institute of

business administration.

2.1.3 Other sources

Sources within this category are sometimes hard to indentify and the validation of these can

sometimes be even harder. These Sources are all describing the CONFIRM project and the

problems that followed the project. Some of them are identified as blogs other as education material

or minor presentations regarding the CONFIRM project. All of them are thoroughly evaluated by

the writers of this paper through a rational approach. If there are any doubts we consult with our

supervisor to secure that the given data is valid and can be used.

Most of the data in this category are information regarding the different problems faced in the

CONFIRM project and it is often very subjective sources that describes specific problems in the

CONFIRM project. The problems described are often depending on the perspective the author have

and what he believes to be the significant problem or problems in this case. The chosen problems

for this paper are all in some way presented in previous work by other authors and almost all of the

problems analyzed in this paper are presented more than once in the data chosen for this paper.

2.2 Structure of the paper

This section will provide insight of how this paper will be presented and how the different parts are

connected.

Section 4 will consist of a case description and thereby setting the foundation for following

analysis. This part will be a descriptive part where the context regarding the CONFIRM project

will be established. This section will mainly work as an establishment of common understanding of

the actors a timeline of the project and a highlight of the chosen problems in the CONFIRM project.

These problems will work as the foundation for the following analysis.

In Section 5 the problems presented in chapter 4 will analyzed through the use of an analytical

framework that categorizes the problems. Furthermore, this part will lead to section 6 suggestions

Side 9 af 39

for change and how these problems could have been avoided with different agile principles in the

project. After the categorization, the problems will be elaborated further by using agile principles.

This should help to further understand and elaborate on the problems faced in the CONFIRM

project

In Section 6 the problems from the analysis in section 5 will be discussed with a different

perspective. First off the problems will be further elaborated through the use of agile principles.

Secondly this chapter is to come up with a discussion off possible changes in the CONFIRM project

and discuss how a mix of agile principles and traditional principles could have complemented each

other in a more sufficient way.

3 Theory

The following sections will provide the theoretical foundation for the paper. The Theory will be

based on traditional and agile development because a shared understanding of the two

methodologies and their differences are essential to assess how and why the CONFIRM project

failed and thereby contribute with a discussion of suggestions for change when developing a large

scale information system, such as the CONFIRM project.

3.1 The evolution of Development Methodologies

In the Beginning of IS development no explicit methodology for developing IS was used and people

tend to develop IS based on their experience. The development focused on programming and the

requirements was rarely defined which led to applications that was of poor use. This lack of

standards in the way IS development was conducted led to the first IS development methodologies,

the systems development life cycle (SDLC) better known as the waterfall model (Avison et al.

2006).

The Waterfall model was introduced by Dr. Winston W. Royce in 1970. It emphasized the need for

analysis before coding. The Waterfall model is at stage by stage model that illustrates that you need

to finish stage 1 before continuing to stage 2. In that way it is a sequential life cycle that is starting

Side 10 af 39

at the top with gathering of requirements and ends at the bottom with deployment. This sequential

development is recommended to be used when the requirements are stable and no changes to the

project or the environment occurs (Stoica et al. 2013). Even though the Waterfall model is widely

known and used it has its clear limitations such as instability due to the fact that changes in the

environment and business often occurs (Avison et al. 2006). In the years that followed Dr. Winston

W. Royce’s Waterfall model, other SDLC models were developed as a response to the criticism of

the Waterfall model. One of the models introduced by Barry W. Boehm (1988) was the Spiral

model it differed from the traditional Waterfall model by being more flexible even though it had

clear inspiration from the Waterfall model (Boehm et al. 1988).

A second approach to the IS development is the agile development methodology which is based on

more flexibility and the ability to proactively embrace change. The agile methodology and its core

principles were established by Fowler et. al. (2001) and it explains 4 value statements that a further

elaborated through 12 core principles of The Agile Manifesto (Fowler et al. 2001) which will be

further elaborated in the following section.

3.2 The Agile Principles

The agile methodology saw the light when Fowler et al. (2001) presented the agile manifesto but

before elaborating on this, a definition of agility is needed to establish a common understanding of

agility in this paper. The definition of agility presented by Conboy (2009) will act as the shared

understanding of agility in this paper. “Continual readiness of an ISD method to rapidly or

inherently create change, proactively or reactively embrace change, and learn from change while

contributing to perceived customer value (economy, quality and simplicity), through its collective

components and relationships with its environment.” (Conboy 2009, p. 340). Together with the

agile manifesto this will provide a shared understanding of the agile approaches and principles

being presented to the CONFIRM project.

A deeper understanding of agile and agile methodology can be expressed with the agile manifesto

that Fowler et al. (2001) presented. It contains four statements that is the core value of agile

methodology. First; Individuals and interactions over processes and tools, second; Working

software over comprehensive documentation, third; Customer collaboration over contract

Side 11 af 39

negotiation, fourth; Responding to change over a plan (Fowler et al. 2001). These four value

statements were furthermore elaborated with the 12 core principles that are presented in the article.

The 12 Principles of the Agile Manifesto (Fowler et al. 2001)

1. Our highest priority is to satisfy the customer through early and continues delivery of valuable

software.

2. Welcome changing requirements, even late in development. Agile processes harness change for

the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of month, with a

preference for the shorter time scale.

4. Business people and developers work together daily throughout the project.

5. Build projects around motivated individuals, give them the environment and support they need

and trust them to get the job done

6. The most efficient and effective method of conveying information with and within a development

team is face-to-face conversation

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers and users should be

able to maintain constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architecture, requirements and design emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its

behavior accordingly.

Fowler et al. 2001 - The agile manifesto

One of the most important perspectives of the agile principles is the understanding of people as

main drivers for a project to be successful. This was argued by Highsmith & Cockburn (2001) and

combining people in focus with intense focus on effectiveness theses new principles would define a

new agile view (Highsmith et al. 2001). These principles have furthermore been the foundation for

various agile development methods such as Extreme Programming and Scrum (Goh et al. 2013) just

to mention a few.

Side 12 af 39

The definition of agile and the agile manifesto presented by Fowler et al. (2001) will be used as the

overall foundation to analyze and explain the different problems presented in the CONFIRM

project.

3.3 Traditional vs. Agile Development

The article Software Development: Agile vs. Traditional written by Marian Stoica, Marinela Mircea

and Bogdan Ghilic-Micu (2013) is proposing an incursion in the software development, from

traditional to agile (Stoica et al. 2013). One of their main contributions is table 1 where they

compare traditional development to agile development. The traditional development are systems

where requirements are specified and developed through extended planning and on the contrary

agile development is software developed by small teams through continues improvement and

testing (Stoica et al. 2013). Another interesting difference highlighted in the article is the use of

traditional development in large scale IS projects and agile development to medium and small scale

projects (Stoica et al. 2013). They also highlight a clear distinction between requirements and size

where traditional development requires very stable and known requirements with preferably large

teams whereas agile is emergent, with rapid changes and preferably work in small teams (Stoica et

al. 2013). These opinions of basic differences between the two development methods are shared by

Highsmith & Cockburn (2001).

A couple of studies compare the agile development method with traditional development method.

There are several dimensions that are often used by different authors when comparing traditional

and agile method (Appendix - table 2). Leau et.al (2012) pointed out even though agile

development methods triumph traditional methods in many aspects, there are still limitations and

problems for agile software development, which would not be a problem in the traditional method.

The first potential issue is concerned with the documentation. As agile development method

follows the principle of minimum documentation and treat the code itself as a document. This

would be problematic especially for novice developers who are not knowledgeable enough to

comprehend the entire project and complete the task without reading the documentation. Very

likely, they would consult the other team members for help, which could cost a lot of time and

cause the delivery of working products at each iteration to be delayed. This in turn may indirectly

increase the development costs. The second issue may occur in the agile development project is

Side 13 af 39

related to communication as agile development stress the communication and engagement with

customers and continuous interaction between team members. Under this premise, interpersonal and

social skills are crucial for the entire development team during each iteration. This also means that

developers should be able to communicate with customers effectively by clearly expressing the

difficulties and issues occurred during the development process while at the same time, being able

to understand the customer’s requirements and convert it into technical language and reflect it in the

development. A third issue is related to stress of team members. Agile development put great

emphasis on breaking down tasks into sub tasks and maximizing one’s productivity in each iteration

by completing more tasks. The tight schedule of each short iteration for developers are very likely

to cause them stressful and frequent meetings with members, customers and stakeholders will

become tedious in the long-run. It is very important that the project manager or other responsible

team leaders pay attention to the mentality and mood of each member and keep a positive morale

(Leau, Loo, Tham, & Tan, 2012).

New thoughts have emerged to question some of the differences between traditional and agile

development, where agile development methods have been used in large-scale IT projects. Goh et

al. (2013) develops two ways of working with agile developments practices, sensing-based agile IS

development practices and responding-based agile IS development practices. These practices should

help organizations to better respond to uncertainties and changes that follow large-scale IT projects

and thereby be a helping tool to develop agile in large IT projects (Goh et al. 2013). Working with

agile in large IT projects is also mentioned by Ramasubbu et al. (2011) and his thoughts of an

ambidexterity approach where the emphasis of either a traditional or agile approach are decided by

the different variables in the project, such as project size, environment, requirements etc.

(Ramasubbu et al. 2011).

4 Case Description

4.1 Overview

Side 14 af 39

The CONFIRM project was initiated by the AMR corporation, who is the parent company of

American airlines. It all started in 1987 when AMR realized that there was great market potential

and opportunity to develop a reservation system that integrates industry of travel, car rental and

lodging. The company found out that only 20 percent of the hotel reservations were made through a

centralized reservation system while in the airline industry 80 percent of the reservations are made

through the centralized system. In 1988, with the aim and ambition of creating the most advanced

reservation system in several industries, a consortium named Intrico was formed, comprising of

Hilton Hotels Corporation, Marriott Corporation, and Budget Rent-a-car. The development of the

new system was subcontracted to AMR Information Services, Inc, who had developed the most

notable SABRE system. AMRIS claimed that the new system would be superior to any existing

system at the time. It can be customized and tailored to satisfy the needs of each member in the

consortium, providing a new stream of revenue after recovering the costs (Clark, 2013) (Ewusi-

Mensah, 1997) (Oz, 1994) (Zellner, 1994).

However, the success of the SABRE system does not guarantee the success of the new reservation

system. In 1992, after running the project for three and a half years, the CONFIRM project was

finally cancelled. The cost of the new system was initially estimated to not exceed 55.7 million

dollars. But by the time when the project was canceled, a total of 125 million dollars had been

invested in the project (Clark, 2013) (Oz, 1994) (Zellner, 1994).

Increase in the cost of the new system development is not the only reason that the project failed.

Various problems occurred during the system development process. We will look at the timeline of

the project development and summarize the major problems occurred in this project based on the

information available.

4.2 Timeline

Date Event

March 13, 1987 AMRIS representatives made a presentation to Marriott executives about a new

reservation system

May - August

1987

Marriott and other potential partners had a meeting with AMRIS representatives

to discuss the potential cooperation

October 1987 A consortium named Intrico composed of Marriott, Hilton, and Budget Rent-a-

Car was formed.

May 24 1988 AMRIS published a press release announcing the official commencement of the

CONFIRM design process.

September 1988 A partnership agreement was reached among the consortium partners. The

Side 15 af 39

agreement stated the objectives of the CONFIRM project. It also stated the two

phases of the project: Design phase and Development phase. The design phase

would take 7 months while the development phase was to be completed within

45 months with the deadline at the end of June 1992.

December 30,

1988

A “base design” of the reservation system was presented by AMRIS. However,

Marriott claimed the functional specifications were not appropriate.

March 1989 AMRIS claimed that functional and technical specifications of the system were

complete. AMRIS also provided a preliminary development plan even though

partners did not approve it.

September, 1989 AMRIS completed the design phase and circulated a revised development plan

for partners’ approval.

August 8 and

August 15 of 1989

A review of pro forma financial statement between AMRIS representatives and

partners.

September 1989 The partners accepted the development plan with the deadline revised from June

1992 to July 1992.

January 1990 AMRIS missed the contractual deadline to complete the terminal-screen design.

February 1990 AMRIS missed the deadline of completing milestone of the business area

analysis phase. AMRIS also admitted it was more than 13 weeks behind

schedule, but AMRIS claimed that it could catch up the schedule in the future.

May 1990 AMRIS revised the development plan and presented to the partners stating that

they could still meet the deadline.

August 1990 Management instructed the employees to revise the dates of the project calendar.

AMRIS declared the completion of the first phase and entered the second major

phase (BSD).

October 1990 AMRIS again admitted to their partners that they were behind schedule for 1

year, but executives claimed that they could still meet the deadline.

February 1991 AMRIS replaced the original plan with the new plan and informed the partners

that only Hilton would be able to use the new system by June 1992 and Marriott

would not be able to use the system with the required features before March

1993.

Marriott responded that they knew AMRIS could not finish the project within the

new deadline and they accused AMRIS of forcing employees to artificially

change the timetable to create the unrealistic schedule.

October 1991 The AMRIS president resigned and later that year at the beginning of 1992, 20

additional employees resigned.

April 1992 AMRIS admitted that the project was approximately two to six months late.

Eight executives of AMRIS were fired and another 15 employees were replaced.

July 1992 The CONFIRM project was abandoned and the Intrico consortium were

disbanded. Throughout the three-and-a-half years, 125 million dollars were spent

on the project.

Table 1 – Timeline (Ozzy 1994, Clark 2013, Ewusi-Mensah 2003)

4.3 Problems of the CONFIRM project

Side 16 af 39

The timeline of the CONFIRM project documented some of the most important events and

activities happened during the three-year project. It provides us with a clear view of how the

CONFIRM project came into place and faced various challenges all the way until it was claimed to

be a failure. Even though that CONFIRM project was a classic case back in the 1990s, existing

reports, articles and journals focuses more on the overall project issues and descriptions. Therefore,

we will mainly rely on the anecdotal information and cases to summarize the potential problems

that led to the failure of the CONFIRM project. Problems are summarized below:

1) Unrealistic Goals and Unclear Functional and Technical Specifications:

The project was too ambitious which involves several industrial partners while the requirements and

of each partner on the new system were not fully understood and communicated between the

management and development team.

2) Cost overruns and schedule delays:

The management set unrealistic expectations on the project and underestimate the costs, time and

resources that were required to complete the project.

3) Over-confidence and Halo effect:

The AMR was overconfident in the CONFIRM project encouraged by the success of their own

SABRE reservation system. The management easily assumed that new system will also be

successful and achievable since both systems have similar functionality.

4) Lack of the Competent Staff:

The technical staff lacked skills to develop the system and accomplish the demanding task of

constructing the interface between several systems and the integration of customer information

databases

5) Violation of Professional codes and ethics:

The AMR management unethically and dishonestly concealed technical and performance problems

in the system and forced their employees to artificially change the dates on the timetable to cheat

their partners.

Side 17 af 39

6) Poor project Management and Quality Control:

Apart from concealing information, the management did not have a monitoring system to track the

progress of the CONFIRM project and assure the quality of the project, especially deliverables are

not available for partners.

7) Staff Changes:

The resignation of AMRIS president led to a series of problems and effect. Twenty staff in the

CONFIRM project left subsequently and project was delayed due to the training the new staff as

well as sorting out system legacy and not well-documented files.

8) Problematic Technology Base/infrastructure:

Two major problems which are fatal to the CONFIRM project occurred during the development

process. One problem related to technical issue is the incompatibility of the interfaces within

CONFIRM reservation system as well as incompatibility between other partners. The other serious

issue occurred when AMRIS admitted the fact that the CONFIRM system is unrecoverable when

the system was crashed due to the fact that they have implemented the wrong software engineering

tool.

5 Categorization of CONFIRM problems

To analyze the information system development problems in the CONFIRM project, an analytical

framework will help to identify and classify the IS development problems in a more structured way.

Empirical studies have listed many difficulties and challenges that are common for companies when

developing information system. Very often these problems are recurrent which means that most of

the IS development project share similarities in terms of the reasons for failure. Unrealistic user

expectations are one of the common problems that proposed in both articles by Doll & Ahmed

(1983) and Lederer & Mende (1990). Moreover, Lederer and Mende mentioned additional problems

in compatibility of the technology in terms of the software and hardware as well as other issues

related to technology such as too much focus on technology, which results in overlook of other

critical factors. Doll and Ahmed (1990) discussed more issues in relation to IS development ranging

from business level to technical level, including lacking an effective and credible system to tracking

Side 18 af 39

and monitoring the development process of the system, lacking qualified and experienced system

staff, etc.

Other researchers focus on some specific types of the IS development problems, particularly at a

strategic level. King (1989) identified the problems such as constraints in budget, lack of the

support and understanding of the Information Technology by the top-management. Vitale (1986)

also pointed out similar pitfalls regarding the lack of IT knowledge of the strategist and his or her

ability to cope with the dynamic environment change. Lyytinen (1987) proposed a comprehensive

summary of problems that are commonly involved information system development processes and

use process. In particular, the category of IS development problem is shown below:

Information System Development

Problem

Description

Goals Goals are ambiguous, too narrow, and conflicting

Technology Technology restrictions and risks in terms of choice and

change

Economy Poor budgetary calculations and planning

Process features Lack of quality control, ineffective or lack of communication,

analysts dominate

View of organization Neglect of behavioral and organizational issue

Self-image High rationalistic image

Table 2 - Reconstructed from Lyytinen (1987)

Ewusi-Mensah (2003) stated in the book Software Development Failures: Anatomy of Abandoned

projects that the factors that lead to the failure of the information system development are

multidimensional and complex. These factors can be divided into two broad groups in general: 1)

managerial and organizational behavioral issues and 2) technical and technological issues.

Unsurprisingly the factors concluded by Ewusi-Mensah (2003) are similar to the summary by

Lyytinen (1987), which include ill-conceived and/or ill-defined project goals and objectives,

inferior project-team composition, poor management and control of the development process, lack

of active user participation and senior management support and commitment, and inadequate

technical expertise and technological infrastructure. Ewusi-Mensah (2003) also pointed out that

very often these factors functioned together and causing serious problems to the project, which

Side 19 af 39

essentially lead to the final termination of the project. This indicates that some factors are

interrelated and the occurrence of one factor may followed by the occurrence of other factors.

Overall, the summary of the problem class is not exhaustive but it covers most and common

domains of problems in the IS development project. Therefore, we attempt to illustrate the issues in

the CONFIRM case and define them under each category. In case there are problems that cannot be

assigned to a category, new categories will be created.

Based on the problems identified in the CONFIRM project and using Lyytinen’s (1987) and Ewusi-

Mensah (2003) classifications as references, the following categorization further conclude the

problems occurred in the CONFIRM project with corresponding categories.

Information System Development

Problem

Problems

Goals 1) Unrealistic Goals and Unclear Functional and Technical

Specifications

Economics Issue 2) Cost overruns and schedule delays

Self-image 3) Over-confidence and Halo effect

Code and Ethics 5) Violation of Professional codes and ethics

Technical Issues 4) Lack of the Competent Staff

8) Problematic Technology Based/Infrastructure

Process Features 6) Poor project Management and Control

7) Staff changes

Table 3 - Categorized CONFIRM problems

5.1 Goals

1 - Unrealistic Goals and Unclear Functional and Technical Specifications

Side 20 af 39

AMR had a very clear vision and objective that they wanted to build the most advanced reservation

system that could align several industry giants and outpace competition in traveling, hotel and car-

rental industries. But the beginning of the project was not very smooth, it took one year for AMR to

negotiate with several partners and finalize the deal. The reason for long negotiation was due to

conflicting benefits and goals. According to Effy Oz (1994), “Marriot 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. “ So in order to persuade Marriot and other partners to join, the following

requirement should be fulfilled, “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.” (Oz 1994).

The requirement implicitly increases the difficulty of developing an overall system that could

operate perfectly among partners and meanwhile satisfying the needs of individual partners. As

later on, Even though AMRIS were busy designing and redesigning the system development, it is

not able to satisfy the specifications of their partners and (Oz 1994). The project became time and

resource consuming and the goals became more and more ambiguous as AMRIS failed to develop

clear requirements and failed to communicate clearly with partners. In 1988, Marriott claimed that

the base design presented by AMRIS is not adequate in terms of the functional specification (Oz,

1994).

During the period of lawsuit after the project was canceled, James Yoak, the chief information

officer of Marriot also claimed that AMR’s accusation on other three partners were irresponsible.

And in fact, before the start of the project, three partners provided AMRIS with a detail list of

specifications on system to show their requirements and needs (McPartlin, 1992). It is difficult to

judge who was telling the truth given the fact that the case was from 1990s. The result of the lawsuit

with the defeat of AMR as well as quotes from company’s internal staff can prove, if not all, that

there were conflicts and disagreements regarding the goals and objectives of CONFIRM project

between parties. In the article by Effy Oz (1994), an internal audit by AMR’s SABRE personnel

reveal 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.” All AMR

stressed and praised highly about was just a vague and broad ‘dream’ to create the first super

system of its kind that integrate several industries (Halper M. 1992).

Side 21 af 39

5.2 Economic issues

2 - Cost overruns and schedule delays

Like other big projects, economic issues of cost overruns and schedule delays are in many cases

inevitable problems. However, according to Ewusi-Mensah (2003) it should not always be

considered as the root causes of project failure, even though in some abandoned IS project

development, cost overruns and schedule delays may contribute to the termination of the project

eventually. In the CONFIRM project, the original cost was estimated to be 55.7 million dollars in

April 1988, but AMR revised the cost to 72.6 million by the end of September 1989. When the

project was finally abandoned, a conservative estimation that 125 million dollars were spend on the

project (Oz, 1994). Together with the increase of the cost, the project schedule was also delayed.

The CONFIRM project was divided into two phases: 7- month design phase and 45-month

development phase. However, the initial proposal of the ‘base design’ was rejected by Marriot in

December 1988, and circulated preliminary plan were again unacceptable to partners of consortium

later in March 1989. It was not until September 1989, the partner accepted the development plan

eventually, but with higher costs and extended schedule (Clark, 2013).

Similar situations happened in the later phase of system development, and there were growing

concerns among partners regarding whether or not AMRIS could complete the project on time.

According to Ewusi-Mensah (2003), economic issues related to cost overruns and schedule delays

may be a key decision support for management to cancel the project, but more importantly, it

reflect deeper problems that are uncovered in the project, which are the root causes that lead to the

project failure.

As mentioned before, many of the issues are interrelated and mutually influential. The occurrences

of cost overruns and schedule delays were closely related to the issue of unclear goals and

objectives as well as incompetent staff. As reported by one of the AMRIS executive:” You cannot

manage a development effort of this magnitude by getting together once a month.” (Oz, 1994).

5.3 Self-Image

3 - Over-confidence and Halo effect

Previous success on the SABRE system which was developed by AMR has led the managers to

believe that “it was a chance to combine running the SABRE business…. And expanding it into

Side 22 af 39

other businesses.” (Oz, 1994, p. 30). This was the cause of halo effect in the sense that AMR

management had a biased view and made inappropriate decisions without evaluation of the situation

in the company (Oz, 1994).

5.4 Code and Ethics

5 - Violation of professional codes and ethics

The violation of professional code and conducts by AMR was the aftermath of the economic issue

related to cost overruns and schedule delayed. According to the description by Oz (1994), AMR not

only concealed critical information but at the same, it also provided fake information and made

commitment that was not possible to achieve. In August 1991, Marriot found that the pro formal

financial statements provided by AMRIS two years ago were false. AMR understated the costs of

staff and other operating costs and meanwhile, it also overstated the total number of reservations

(Oz, 1994). Also, after the summer of 1990, when partners demanded AMR to present some

“deliverables”, AMR refused to show it and explained the project status (Oz, 1994). Each time

when AMR realized that they could not conceal the information anymore, they first admitted the

situation to the partners but at the same time in order to continue running the project, they made

unrealistic promises to partners saying that they would be able to catch up the original plan. When

AMRIS again realized that they could not meet the deadline, they forced employees to artificially

modify and change the date and those who refused to do that were either fired or resigned (Oz,

1994).

5.5 Technical issues

4 - Lack of the Competent Staff

On April 29, 1992, in the statement made by AMRIS chairperson towards the three partners, two

reasons were specified for the project delay of 15 to 18 months. Specifically: (1) The individuals

whom we gave responsibility for managing CONFIRM have proven to be inept. (2) The technical

staff, while skilled, has failed in the construction for the very demanding interfaces between the

systems, and the extensive database (Oz, 1994).

Side 23 af 39

In the later lawsuit charged by AMRIS, the company accused three partners of providing poor

skilled staff that lack the adequate knowledge of the industry, which impeded the progress of the

project and violated the contractual agreement (Halper M., 1992). This charge was refuted later by

three partners. They stated that: “at the original project meeting in 1987, AMR gave the impression

to its would-be partners that it was going to use its experienced systems development experts

responsible for SABRE’S success on CONFIRM.” Ewusi-Mensah (2003) Furthermore, former head

of IS department of Marriot revealed that the project was doomed to failure from the beginning, as

AMR was not using staff from the company but rather hiring people from street and proceeded

without the right project manager running it. (Ewusi-Mensah, 2003).

8 - Problematic Technology Based/Infrastructure

The structure of the CONFIRM system was depicted by Flower 1997. The transaction Management

Function (TMF) software system in the middle was deployed as an interface for different users

(three partners and other stakeholders). It was based on the two IBM mainframe computers. The

MVS operating system was used to store data about price and customer information as well as

decision support system information. The other mainframe computer adopted the IBM’s

Transaction Processing Facility operating system to receive and process reservations of cars, hotels

etc. from external customers.

However, two major problems prevented the success of the system. One problem was related to

interfaces among various stakeholders as well as the two mainframe computers. The capacity and

capability of the TMF software supported by two mainframe computers to deal with the

reservations had not been fully tested and simulated during the design phase. This sometimes led to

a crash of system in the case when there was data overload. Also the communication between the

two mainframe computers was not smooth. The other major problem occurred when AMRIS

realized that the system was not recoverable during the event of the crash. As stated by the vice

president of AMRIS,” the company has mistakenly implemented Texas Instruments’ Information

Engineering Facility (IEF) computer-aided software engineering tool in which IEF generates its

own database structure.” (Halper M., Aug 10th, 1992,)The vice president also stated, “ he had

suggested that for system large like CONFIRM, a version of IEF in which the structure is dictated

Side 24 af 39

instead of self-generated should be implemented so that it would better for the team to manage and

recover the system in the event of the crash”.(Halper M. ,Aug 10th, 1992,)

Figure 1 - Source: Flowers (1997) Structure of CONFIRM project

The technology infrastructure provides the foundation for the company in carrying out system

development project and further support the essential physical structure of the system. The

incapability of the databases to recover in the event of a crash compounded with the failure of

system integration due to interface problems are fatal technical issues to the CONFIRM project.

5.6 Process Features

6 - Poor project management and control

In the CONFIRM project, even after it was canceled finally, a critical issue which created disputes

among AMR and other CONFIRM partners was about how the CONFIRM project should be

managed. The involvement of multiple parties in the project increased the complexity of creating an

environment where each partner will be satisfied and being actively involved. In the article by Oz

(1994), partners have repeatedly shown concerns and unsatisfaction regarding the ineffective

management of the CONFIRM project. During the development process, management concealed a

Side 25 af 39

number of critical technical problems from their partners. When these technical issues were

uncovered and they realized they could not meet the original schedule, the management unethically

asked the employees to artificially revise the plan to satisfy partners. According to IBM’s review

commissioned by AMRIS, concealment of the project information and problems is a serious

management problem, but more seriously was that AMRIS did not take critical review and

immediate corrective action to solve the problems. The management instead neglects the problems

and kept the project running which resulted in more serious problems in the later stage (Ewusi-

Mensah 2003). In addition, AMRIS refused to show their partners ‘deliverables’ during the

development process reveal the fact that management failed to create an effective monitoring

system to track and control the progress of the work in the project (Oz, 1994).

7 - Staff changes

The changes in the staff are another serious problem, which contributed to the failure of the project.

In October 1991, the AMRIS president resigned. Following with the resignation, 20 additional

employees resigned. The change and resignation of the staff could lead to the delay of the project,

as looking for new employees and providing training would take time (Clark, 2013). Furthermore,

the resignation of the staff affected the morale of the team. This was indicated in the article by Oz

(1994) that half of the CONFIRM project employees were looking for new positions by the summer

of 1991. Many employees were dissatisfied with the way management handle the project. They

realized that even they spent the more hours every day and worked during the weekend, they still

could not finish the project according to the schedule set by the manager. In search of moving to

other projects, members would not be as hardworking as before they started the project (Clark,

2013).

6 The Confirm problems with an agile perspective

In the previous section we categorized different problems within the CONFIRM project to better

understand how the problems influenced the project. In the following section the problems will be

presented and discussed with another perspective in mind. The 8 categorized problems will be

Side 26 af 39

evaluated based on the core principles of the agile manifesto and the core definition of agile

presented by Cockburn (2009). Not all of the mentioned 8 problems will be further elaborated in

this section due to fact that they are more general problems and not direct solvable with the agile

principles. Some of them may be indirectly solvable but that will be further discussed in the

following section, Suitable changes for the CONFIRM project

Principle 1 and 3 in the agile manifesto, presented earlier in the paper describing that delivery of

working software has high priority is in clear contrast with the described problem 6, poor

management and project control. As mentioned earlier the management refused to deliver any

working software along the way and they neglected serious problems and just kept the project

running even though it should have been cancelled or at least revised with all partners in the project.

Principle 4 and principle 6 in the agile manifesto regarding lack of daily corporation between

people in a project and that people should meet and work together face to face in order to prevent

misunderstandings or different expectations to the information system in development. These

principle are in clear conflict with problem 1 categorized earlier because as mentioned the involved

people in the CONFIRM project only meet once a month and otherwise no other communication

between AMRIS and Intrico where planned. According to agile principles this is a big problem

because it conflicts with the core thoughts that people should work close together through daily face

to face meetings or work sessions

Principle 7 that describes that working software is the primary measure of progress is violated in

problem 2. Schedules are constantly delayed due to different problems emerging but still there are

no way of measuring progress within the CONFIRM project and thereby it is impossible to adjust

their processes. This of course results in cost overruns which are extreme and constant. A way to

measure progress would have been preferred to avoid constant delay.

Principle 9 in the agile manifesto concerning continues attention to technical excellence is

conflicted in problem 8. They fail to evaluate the technical aspects of the project and thereby

indentify problems earlier. The project faced great problems with the integration and

Side 27 af 39

communication of the two databases, these problems maybe could have been avoided if they

performed continues evaluation of the technical aspects.

The remaining 4 problems not related to any specific principles in the agile manifesto will be,

alongside with the other problems, used in the following section. These 4 problems are more

general problems and are not direct solvable or in direct conflict with any of the 12 agile principles.

These 4 problems are understood as more general problems that any development project could face

and different agile principles or values will be assed that might would could have been useful. This

wouldn’t have guaranteed all the problems from occurring, but it might have helped some of the

problems.

6.1 Suitable changes for the CONFIRM project

A lot of the problems discussed in the previous section can be related to poor management and

basically problems to control a development project. These problems are not a direct result of the

traditional development method that the CONFIRM project was developed in, because some of the

aspects from the traditional methodology has great relevance when developing such big and

complex information systems (Stoica et al. 2013). Suggestions for change to solve the problems

presented earlier will be discussed in the same order as they were categorized to keep the structure

of the paper in tact. In addition, a successful case story of IBM in combining agile development

principles and elements with a waterfall project will partially form the foundation of suggestions for

suitable changes in CONFIRM project.

Problem 1 unrealistic goals and unclear functional and technical specifications where categorized as

a goal problem and was in clear conflict with principle 4 and principle 6 in the agile manifesto. This

classical problem with different expectations is further elaborated by Orlikowski et al. (1994) where

she describes the concept of frames and it importance when implementing a new information

system. Even though this study was done on a working system the concept of frames could be used

in this case. Every individual have their own frame and thereby expectations to a given system

depending on different factors such as working department, geographical position and working

order (Orlikowski et al. 1994). Problems with a system will occur when people do not share frames

and thereby do not have the same expectation to the system which was the unfortunate case in the

Side 28 af 39

CONFIRM project. Achieving shared frames could have been succeeded by introducing agile

principle 4 and principle 6 in the CONFIRM project. Based on that, closer collaboration and

communication between AMRIS and Intrico could have helped avoid different expectations and

thereby avoid constant change in requirements, which are not preferred when developing with a

traditional development methodology (Stoica et al. 2013). A practical case of IBM application

development team proved that introducing agile ideas and elements to the traditional development

project could succeed, the project adopted a traditional development method at the beginning, and

they realized that they needed a better development process to control the external influences in the

project such as change requirements and late requirements. The company adopted the agile

approach by borrowing some of the agile concepts. For example, the team spent significant amount

of the time on concept phase and planning phase (even more than development phase) to constantly

engage with customer business requirements, system requirements. A list of requirements and

release items were constantly updated and reprioritized and changes were even possible in the

development phase. The project manager noticed the challenges in transitioning waterfall process to

an agile process in terms of languages use when communicating with customers. Therefore, he

carefully translated the terms and language in agile world to clients and bridge the gap between

agile and waterfall world. The adoption of agile approach helps the IBM application development

team to have a clear understanding of the project requirements and priorities from their customers

(Hines, Baldwin, Giles, & Peralta, 2009). Closer collaboration and frequent communication as part

of the agile principles brought benefits to IBM as the development team was better and able to

handling changes in concept phase and even later development phase. In addition, the success of

introducing agile concepts in the concept phase encourages the team to further adopt agile approach

(SCRUM) in the development phase (Hines, Baldwin, Giles, & Peralta, 2009).

Problem 2 cost overruns and schedule delays is maybe one of the most well documented problems

in the CONFIRM project. They start up with at budget on 55 million dollar and end up spending

125 million dollar with no working software. Constant schedule delays and problems with

measuring progress resulted in a problem categorized as an economic issue and that it conflicts with

principle 7. This could be argued that this problem was a more general problem not direct solvable

by introducing different agile aspects but still these agile aspect could have given them the visibility

they needed. By introducing a burn down chart mentioned by Deemer et al. (2012) as a part of the

SCRUM development method they could have visualized their progress (Deemer et al. 2012).

Side 29 af 39

There is no way of saying how they actually measured progress within the project and due to

delimitation of data it is impossible to say how they did it. The only way of measuring progress

mentioned in our data was the completion of the design phase and development phase. These phases

could by adapting Scrum be divided into minor phases and tasks where the burn down chart would

have been an excellent tool to visualize the remaining tasks (Deemer et al. 2012). It would still be

hard to integrate principle 7 because of the overall traditional methodology in the project but it

might have helped AMRIS in their daily work.

Problem 6 Poor project management and control was categorized as a process feature problem and

in violation with the agile principle 1 and principle 3. This could again be argued as are more

general problem due to the fact that poor management is a overall theme of the problems that were

faced in the CONFIRM project. Nevertheless there were a clear lack of control over the project and

the fact that AMRIS management neglected serious problems along the way and the refusal of

showing any progress to the different partners in the project. Such problems can be hard to

overcome when the development phase first has something to show for in the end and to state that

they should have delivered working software continuously is not really relevant. A solution to this

problem relates to above mentioned suggestion is to divide the project into minor milestones or task

and thereby visualize the project and find ways to measure progress in the daily work for example

with the burn down chart. This problem could be seen as a general problem and by using different

agile principle this might not have been sufficient but it would have given AMRIS a better overview

of the daily work which could have helped the management. One practical example by adopting

agile elements and processes to solve problems related to project management and control is the

case of IBM. The application development team adopts the full scrum processes within the waterfall

project so that they can better control the chaos from external influences (late and changing

requirements) and from their own poor procedures (low quality codes, insufficient work output). By

implementing scrum, the team breaks down the large features into smaller items and develops these

features incrementally. Even though their clients are used to the traditional development processes,

they succeeded in convincing their clients adopting scrum processes. Sprint reviews were held to

review the small pieces of functionality of each sprint with the clients and making changes and

updates based on their requirements and feedbacks. In this way, it saved the development team

much more time compared with the case in the traditional method when the working software can

be seen only at the end of the project and one change in the requirement may involve reworking the

Side 30 af 39

various levels of requirements in each parts. With scrum processed being adopted, quality control is

assured in each sprint enabled by the incorporation of the automated testing. The test ensured the

code was not broken and fewer defects were found in the qualify phase later. In addition to the

adoption of the scrum processes (sprint review, retrospectives, daily standup) in the IBM project,

relevant tools were also applied to track the progress of the project. The team not only used the

typical burn down chart together with a bug/issue tracking system to monitor the development work

items and track down sprints, but also they used the Microsoft project to schedule plans and assign

work for the team. There are mainly two reasons to use the Microsoft project tool. First, the tool is

more effective at presenting and communicating status with clients on the amount of the work

delivered as well as the resources allocated to in project. Second, the tool is more recognizable and

often used in a waterfall project. As the team does not fully abandon the traditional approach, this

tool will still be useful in making transition from the traditional approach towards an integration of

both methods (Hines et al. 2009). These approaches stated in the IBM case could have been very

useful for the CONFIRM project due to the fact that the background and problems within the two

cases are somewhat alike.

Problem 8 problematic technology base/infrastructure was categorized as a technical issue and it

conflicted with principle 9 in the agile manifesto. By adapting principle 9 in the agile manifesto as

an overall approach to developing the technical aspects of the CONFIRM project many problems

might could have been avoided. It is hard to say how the technical design aspect was done due to

the delimitation in data regarding this process, but is clear that there were no continuous attention to

technical excellence when the two systems should communicate together. By keeping principle 9 as

an overall approach to the technical work they maybe could have avoided problems earlier in the

process and saved lots of resources.

Problems 3, 4, 5, 7 are all argued as more general problems and therefore not related to a direct

principle from the agile manifesto they were in conflict with because these problems are more or

less a combination of different problems and cannot be solved only by using agile principles but

they could have been minor problems with the mix of agile principles in the CONFIRM projects

traditional development process.

Problem 3 and problem 5 were categorized as self-image problems and code and ethics problems.

These are general in that way that over-confidence and violation of professional codes and ethics

Side 31 af 39

are bad in all kinds of projects no matter if the project is agile or traditional based. But that does not

mean that these problems couldn’t have been helped in the CONFIRM project with different agile

approaches. By introducing some scrum based development tools to the whole projects, would

some of these problems might not even be possible. Working in smaller teams and daily standup

meetings could have kept the developers at AMRIS in constant remind of the challenges that this

project faced. Even though it would have been hard to eliminate such a human error as over-

confidence in these projects especially when previous projects had been a success. Violation of

professional codes and ethics is morally just wrong and is hard to prevent from happening but by

introducing agile principles as principle 4 and principle 6 it would have been near impossible to lie

and cover failures within the project. If AMRIS and Intrico where working together on a daily basis

and with more face-to-face meetings more than once a month much of the ethical problems might

have been avoided.

Problem 4 and problem 7 was categorized as technical issues and process feature problems.

Problem 4 lack of competent staff can be a problem in all projects and does not relate specifically to

a project with a traditional development approach. Different accusations was made during the

lawsuit that AMRIS was hiring insufficient staff and hiring people of the street. Problems of this

nature can be hard to come by, by using agile principles but fact is that AMRIS believed they had

skilled developers they just failed in the construction of the interfaces between the systems and the

databases. It is easy to say that the developers failed but it is clear after the analysis that the

management did not provide a great environment for the developers and thereby made the job near

impossible to perform. This further causes the occurrence of problem 7 staff changes where

developers and management staff either resigned or were fired due to the hostile environment and

ethical reasons. These two problems cannot be fixed directly by implementing agile principle in the

development approach when the management creates a hostile environment that does not motivate

employs.

Side 32 af 39

Figure 2 - Ramasubba et al. 2011 - Nested cycles of software process ambidexterity

Even though a lot of the problems can be traced back to poor management, some of these principles

and agile tools could have helped the CONFIRM project to succeed. According to Stoica et al.

(2013) large complex IT-projects should be developed with a traditional approach and this belief is

in some way shared with Ramasubbu et al. (2011) which is illustrated in his figure; nested cycles of

software process ambidexterity (Figure 2). It is clear that projects with large teams and low ends

user participation should be more traditional. However, the quantitative and qualitative study by

Ramasubbu (2011) shows that when the project involves larger and complex code-bases, new

technologies, higher levels of end-user engagements and inexperienced development teams, the

ambidextrous software process design and development is more preferred than the traditional

approach(Ramasubbu et al.2011). This is also proved by the positive contribution made by adoption

of ambidextrous process design, in which productivity and profitability increase while defects

decrease. From figure 1 it shows that more variation and uncertainty in the environment creates

more need for an agile method emphasis. From the previous discussion, the CONFIRM project had

a clear emphasis on the traditional methodology and can be placed in the bottom of the model, but

our belief is that the CONFIRM project should have had greater emphasis on agile principles and

methodologies which would place them more towards the middle of the model. This is based on the

Side 33 af 39

fact that constant changes in the requirements and the lack high user participation were involved in

the CONFIRM project as argued in previous sections.

The traditional approach to the CONFIRM project is not necessarily wrong but it could have been

optimized with the use and incorporation of different agile principles and figure 1 in appendix could

be a way of predicting how much emphasis there should be on either agile methods and traditional

methods.

7 Conclusion

The meaning of this paper is to come up with a discussion of suggestions for change and thereby

derive a more suitable approach for the CONFIRM project that was marked as an IT-scandal from

the late 1980’s and early 1990’s. The CONFIRM project and its problems was first derived from an

exhaustive data collection that would secure a specific and detailed understanding of the project as

possible given the clear delimitation in data regarding this project.

A timeline was presented to give a sufficient knowledge of the CONFIRM project and to help

highlight certain problems within the project. Then the problems was narrowed down to eight

specific problems and categorized with an analytical framework to help better analyze the different

problems. The problems were further assessed with an agile perspective and the described theory

was put into use to show how the project failed and how it could have avoided some of the

problems with agile perspectives. This leads to a discussion of the different suggestions for change

within the different problems of the CONFIRM project.

The CONFIRM project was afflicted with poor management and that is why many of the different

problems could be related to this specific problem. But this poor management could in many ways

be helped by introducing different agile principles to an otherwise traditional development method.

It is not possible to establish a perfect approach for the CONFIRM project but through the paper it

is clear that our findings point towards mixing the two methodologies and emphasize the need for a

more agile approach that we believe would have been more suitable approach for the CONFIRM

project.

Side 34 af 39

8 References

Avison, D., & Fitzgerald, G. (2006). Information systems development methodologies, techniques &

tools (4 ed.). McGraw-Hill Education (UK) Limited.

Avison, David & Fitzgerald, Guy (2006). Methodologies for Developing Information Systems: A

Historical Perspective

Awad, M. (2005). A Comparison between Agile and Traditional Software Development

Methodologies. University of Western Australia.

Clark, A. (2013, February 28). Software Failure: A Look at the CONFIRM project. Retrieved from

SAPM: Informatics at Edinburgh Class Blog.

Conboy, Kieran (2009). Agility from First Principles: Reconstructing the concept of Agility in

Information Systems Development, Information Systems Research vol. 20, No. 3, pp. 329-354

Deemer, Pete & Benefield, Gabrielle & Larman, Craig & Odde, Bas Vodde. 2012. The Scrum

Primer.

Dorsey, P. (2005, April 26). Top 10 Reasons Why Systems projects Fail. Retrieved from

http://www.hks.harvard.edu/m-

rcbg/ethiopia/Publications/Top%2010%20Reasons%20Why%20Systems%20projects%20Fail.pdf

Ewusi-Mensah, K. (1997). Critical issues in abandoned information systems development projects.

Communication of the ACM, 40(9), 74-80.

Ewusi-Mensah, K. (2003). Software Development Failures: Anatomy of Abandoned projects. MIT

Press.

Fowler, Martin & Highsmith, Jim (2001). The Agile Manifesto.

Side 35 af 39

Gheorghiu, F. (2006). Why Companies fail on the way to implementing project management

methodology. Project Management Today, 8 (10).

Goh, Jenson Chong-Leng & Pan, Shan L. & Zuo, Meiyun (2013). Developing the Agile IS

Development Practices in Large-Scale IT projects: The Trust-Mediated Organizational Controls

and IT project Team Capabilities Perspectives. Journal of the Association for Information Systems,

vol. 14, issue 12, pp. 722-756.

Halper, M. (1992, August 3). Outsourcer CONFIRMs Demise of Reservation Coalition Plan.

Computerworld, 1.

Halper, M. (1992, August 10). IS Cover-Up Changed in System Kill. Computerworld, 1.

Halper, M. (1992, October 12). Marriott suit Damns AMR Role in CONFIRM. Computerworld, 8.

Heeks R. 2008. Success and failure rates of e-Government in developing/transitional countries:

Overview. Available at, www.egov4dev.org [Accessed 19 April 2011].

Highsmith, Jim & Cockburn, Alistar (2001). Agile Software Development: The Business of

Innovation. Software Management.

Hines, L., Baldwin, S., Giles, M., & Peralta, J. (2009, July 22). Implementing agile development in

a waterfall project. Retrieved from IBM developerWorks:

http://www.ibm.com/developerworks/websphere/techjournal/0907_hines/0907_hines.html

Iivari, J., & Maansaari, J. (1998). The usage of systems development methods: are we stuck to old

practices? Information and Software Technology, 501±510.

Leau, Y. B., Loo, W. K., Tham, W. Y., & Tan, S. F. (2012). Software Development Life Cycle

AGILE vs Traditional Approaches. International Proceedings of Computer Science & Information,

37, p. 162.

Side 36 af 39

Lu, W. (n.d.). Retrieved from http://fisher.osu.edu/~muhanna.1/old/831s95/sart/lu.htm

Lyytinen, K. (1987). Different Perspectives on Information Systems: Problems and Solutions. ACM

Computing Surveys.

Markgraf, B. (u.d.). Importance of Information Systems in an Organization. Collected from Small

Business:http://smallbusiness.chron.com/importance-information-systems-organization-69529.html

McPartlin, J. (1992, October 19). The Collapse of CONFIRM. Information week, 12.

Moniruzzaman, A., & Hossain, S. A. (2013). Comparative Study on Agile software development

methodologies. Global Journal of Computer Science and Technology, 13(7)

Naresh K. Malhotra; David F. Birks; Joseph F. Hair, Jr; William C. Black; Barry Jr. Babin; Rolph

E. Anderson. (2011). Selected chapters from; Marketing Research: An Applied Approach” 3 udg.,

”Multivariate Data Analysis: A Global Perspective. 7 udg., Pearson Custom Publishing.

Orlikowski, Wanda J. & Gash, Debra C. 1994. Technological frames: Making sense of information

technology in organization. ACM Transactions on information systems, Vo.l 12, No., p. 174-207.

Oz, E. (1994). When professional standards are lax: The CONFIRM failure and its Lessons.

Communications of the ACM, 37(10), 29-43 . doi:10.1145/194313.194319

Stoica, M., Mircea, M., & Ghilic-mivu, B (2013). Software Development: Agile vs. Traditional.

Informatica Economică, 17. doi:10.12948

Ramasubbu, Narayan & Bharadwaj, Anandhi & Tayi, Giri. 2011. Does Software Process

Ambidexterity lead to better software project performance.

Riis, Ole, 2003. Sociologiske metoder i praksis. Aalborg Universitetsforlag

Side 37 af 39

Stoica, Marian & Mircea, Marinela & Ghilic-Micu, Bogdan (2013). Software Developmen: Agile

vs. Traditional. Informatica Economica vol. 17, no 4

Tumbas, P., & Matkovic, P. (2006, January). Agile vs Traditional Methodologies in Developing

Informatin Systems. Management Information Systems.

Verner, J. (2009). Outsourced Strategic IT Systems Development Risk. The University of New

South Wales.

Zellner, W. (1994, January 16). Portrait Of A project As A Total Disaster. Retrieved from

BloombergBusinessweek: http://www.businessweek.com/stories/1994-01-16/portrait-of-a-project-

as-a-total-disaster

Side 38 af 39

9 Appendix

1 Table - Triangularization of CONFIRM project problems

(Verner,

2009)

(Oz,

1994)

(Lu) (Clark,

2013)

(Ewusi-

Mensah,

1997)

(Ewusi-

Mensah,

2003)

1) Unrealistic Goals and

Unclear Functional and

Technical Specifications

X X X X X X

2) Cost overruns and

schedule delays

X X X X X X

3) Over-confidence and Halo

effect:

X X X

4) Lack of the Competent

Staff:

X X X X X X

5) Violation of Professional

codes and ethics

X X X X X X

6) Poor project Management

and Control

X X X X X

7) Staff Changes: X X X X

Side 39 af 39

2 Table - Triangularization of Agile vs. Traditional development

(Leau, Loo,

Tham, & Tan,

2012)

(Awad,

2005)

(STOICA, Mircea, &

GHILIC-MICU,

2013)

(Moniruzzaman &

Hossain, 2013)

Development model X X X

Requirement X X X X

Customer

involvement

X X X

Management Style X X

Organization

structure and culture

X X

Development

style/approach

X X X

Quality Control X X

Cost X X X

Size X X X X

Developers X X X

Architecture X

Documentation X X

Testing X X