AARHUS UNIVERSITET

BUSINESS AND SOCIAL SCIENCES

INSTITUT FOR MARKETI NG OG ORGANISATION

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

Table of Content
1

Introduction ................................................................................................................................... 4
1.1

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

1.2

Delimitaion ........................................................................................................................................ 6

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

2.1

2.1.1

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

2.1.2

Books ......................................................................................................................................... 7

2.1.3

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

2.2
3

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

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

Theory ............................................................................................................................................ 9
3.1

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

3.2

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

3.3

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

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

4.1

Overview .......................................................................................................................................... 13

4.2

Timeline ........................................................................................................................................... 14

4.3

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

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

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

6.1

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

Conclusion .................................................................................................................................... 33

References ................................................................................................................................... 34

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

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 egovernment 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 21 st 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 nonstructured 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 4 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 5 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 6 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 7 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 8 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 9 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. Royces 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 10 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 customers 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 11 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 12 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 customers 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 ones 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 13 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) (EwusiMensah, 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
March 13, 1987
May - August
1987
October 1987
May 24 1988
September 1988

Event
AMRIS representatives made a presentation to Marriott executives about a new
reservation system
Marriott and other potential partners had a meeting with AMRIS representatives
to discuss the potential cooperation
A consortium named Intrico composed of Marriott, Hilton, and Budget Rent-aCar was formed.
AMRIS published a press release announcing the official commencement of the
CONFIRM design process.
A partnership agreement was reached among the consortium partners. The

Side 14 af 39

December 30,
1988
March 1989

September, 1989
August 8 and
August 15 of 1989
September 1989
January 1990
February 1990

May 1990
August 1990

October 1990
February 1991

October 1991
April 1992
July 1992

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.
A base design of the reservation system was presented by AMRIS. However,
Marriott claimed the functional specifications were not appropriate.
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.
AMRIS completed the design phase and circulated a revised development plan
for partners approval.
A review of pro forma financial statement between AMRIS representatives and
partners.
The partners accepted the development plan with the deadline revised from June
1992 to July 1992.
AMRIS missed the contractual deadline to complete the terminal-screen design.
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.
AMRIS revised the development plan and presented to the partners stating that
they could still meet the deadline.
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).
AMRIS again admitted to their partners that they were behind schedule for 1
year, but executives claimed that they could still meet the deadline.
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.

The AMRIS president resigned and later that year at the beginning of 1992, 20
additional employees resigned.
AMRIS admitted that the project was approximately two to six months late.
Eight executives of AMRIS were fired and another 15 employees were replaced.
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 15 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 16 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 17 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 18 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 Lyytinens (1987) and EwusiMensah (2003) classifications as references, the following categorization further conclude the
problems occurred in the CONFIRM project with corresponding categories.

Information System Development

Problem
Goals

Economics Issue
Self-image

Problems

1) Unrealistic Goals and Unclear Functional and Technical

Specifications
2) Cost overruns and schedule delays
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 19 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 carrental 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 AMRs 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 companys 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 AMRs 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 20 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 21 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 22 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 SABRES 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 IBMs
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 23 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 24 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 IBMs 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 (EwusiMensah 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 25 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 26 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
wouldnt 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 27 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 28 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 29 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 30 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 couldnt 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 overconfidence 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 31 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 32 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 1980s and early 1990s. 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 33 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/mrcbg/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 34 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, 501510.

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 35 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 36 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 37 af 39

9 Appendix
1 Table - Triangularization of CONFIRM project problems
(Verner,
2009)

(Oz,
1994)

(Lu)

(Clark,
2013)

(EwusiMensah,
1997)

(EwusiMensah,
2003)

1) Unrealistic Goals and

Unclear Functional and
Technical Specifications

2) Cost overruns and

schedule delays

3) Over-confidence and Halo

effect:

4) Lack of the Competent

Staff:

5) Violation of Professional
codes and ethics

6) Poor project Management

and Control

7) Staff Changes:

Side 38 af 39

2 Table - Triangularization of Agile vs. Traditional development

(Leau, Loo,
Tham, & Tan,
2012)
Development model
Requirement

Customer
involvement

(Awad,
2005)

(STOICA, Mircea, &

GHILIC-MICU,
2013)

(Moniruzzaman &
Hossain, 2013)

Management Style

Organization
structure and culture

Development
style/approach

Quality Control
Cost

Size

Developers

Architecture

X
X

Documentation
Testing

X
X

X
X

Side 39 af 39