8/12/2019 Larsen Case1
1/23
When success turns into failure: a package-drivenbusiness process re-engineering project in the
financial services industry
M.A. Larsena, M.D. Myersb,*
aKPMG, 8 Salisbury Square, London, EC4Y 8BB, UKbDepartment of Management Science and Information Systems, University of Auckland, Private Bag 92019,
Auckland, New Zealand
Accepted 6 March 2000
Abstract
This article discusses a Business Process Re-engineering project that involved the implementation
of an enterprise resource planning software package. Although the project was deemed to be a
success when the system was first delivered, this initial success soon turned to failure. While the
short-term financial results were spectacular, the long-term implications of the changes were more
worrying. This paper raises many questions about the meaning of success. In particular, it shows
how a successful implementation can, within a relatively short space of time, turn into failure.
1999 Elsevier Science B.V. All rights reserved.
Keywords: Business process re-engineering; Enterprise resource planning; Case study; Interpretivist perspective;
Information systems success; Implementation of information systems; Financial sector
1. Introduction
A substantial body of research in information systems has been concerned with IS
implementation and IS success. Some researchers have focused on success within
specific domains, such as Decision Support Systems (Alavi and Joachimsthaler, 1992),
Executive Information Systems (Bussen and Myers, 1997), or Business Process Re-engi-
neering (BPR) (Carr and Johansson, 1995; Teng et al., 1998), while others have focused on
the success of information systems projects more generally (Lucas, 1975; Ginzberg, 1981;
Journal of Strategic Information Systems 8 (1999) 395417
0963-8687/99/$ - see front matter 1999 Elsevier Science B.V. All rights reserved.
PII: S0963-8687(00)00025-1
www.elsevier.com/locate/jsis
* Corresponding author. Tel.: 64-9-3737-599, ext. 7468; fax: 64-9-3737-430.
E-mail addresses:[email protected] (M.D. Myers), [email protected] (M.A. Larsen).
8/12/2019 Larsen Case1
2/23
Lucas, 1981; Ives and Olson, 1984; Swanson, 1988; DeLone and McLean, 1992; Robey et
al., 1993; Seddon, 1997).
This paper concerns the implementation of a package-driven BPR project. In package-
driven re-engineering, the idea is to redesign the business processesbeforeimplementingan enterprise resource planning (ERP) system, but to limit the process changes to those are
supported by the best practices built into current ERP packages. The BPR project in
question involved the implementation of an ERP software package, namely, SAP. While
the specific focus of this paper is on the success of BPR projects, the findings will also be
of interest to those concerned with the implementation of ERP systems and the imple-
mentation of information systems more generally.
The primary contribution of this paper is to suggest that success is a moving target.
The attribution of success can vary considerably depending upon the time at which the
evaluation is done. While the BPR project discussed here was regarded as a success at the
time of implementation, it was not regarded as such a few months later. The short-termfinancial results may have been spectacular, but the long-term implications of the changes
were more worrying. We also question the ease with which commentators attribute
success or failure to particular projects. We believe that the extent to which a project
is successful or not is not easy to determine, particularly if the viewpoints of various
stakeholders are taken into account.
A secondary contribution of this paper is to provide an in-depth case study of package-
driven BPR. A number of researchers have drawn attention to the lack of in-depth case
studies of BPR projects (Glasson, 1994; Grover et al., 1995; Hamilton and Atchison, 1996;
Willmott and Wray-Bliss, 1996). This paper can be seen as one response to the call for
more empirical in-depth case studies concerning the implementation of BPR in practice.The BPR project discussed here was one which involved the introduction of new work
processes, a new organisational structure, and the implementation of a new financial
information system within one organisation in the New Zealand financial services indus-
try. One of the purposes of the research was to understand the development and imple-
mentation of a BPR project over time.
The paper proceeds as follows: the following section discusses BPR, focusing specifi-
cally on BPR success. Section 3 describes the interpretive case study research method
that was used. In Section 4, the empirical evidence from the BPR case study is discussed.
Section 5 presents an analysis of the case, while Section 6 is a discussion of the findings.
Section 7 presents the conclusions.
2. BPR success
One of the difficulties in conducting research on BPR is that various terms are used,
such as Business Process Re-engineering, Business Process Redesign, or Business Process
Improvement. Not only are there disagreements about the scale of change or scope of
the processes being redesigned (Jones, 1994), but different definitions of the same term
are used in different studies. This makes it difficult to compare studies (Childe et al.,1994).
Rather than quibble about the definition of BPR, we prefer to take the pragmatic step of
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417396
8/12/2019 Larsen Case1
3/23
simply using Hammer and Champys definition, which has been one of the most cited in
the literature. Their definition is as follows:
The fundamental rethinking and radical design of business processes to achieve
dramatic improvement in critical, contemporary measures of performance such ascost, quality, service and speed (Hammer and Champy, 1993, p. 2).
The underlying principles of the definition above are that re-engineering involves a
focus on business processes, should question the fundamentals, the change should be
radical, and the benefits proposed substantial. Other authors add that BPR is a deliberate
and planned phenomenon (Grover et al., 1995), and that it is usually enabled through
information technology (Benjamin and Levinson, 1993; Fielder et al., 1995). Various
approaches to doing BPR are presented in the literature (e.g. Davenport and Short,
1990; Carr and Johansson, 1995; Grover et al., 1995; Kettinger et al., 1997) and many
lessons have now been learnt (e.g. see Hall et al., 1993; Caron et al., 1994; Davenportand Beers, 1995; Stoddard and Jarvenpaa, 1995; Teng et al., 1998).
BPR is not without its critics. BPR has been criticised for increasing unemployment, for
disempowering staff (Willmott, 1994; Grey and Mitev, 1995; Willmott and Wray-Bliss,
1996), and for attacking structures that provide organisational identity (Bailie, 1995; Grint
et al., 1996). Furthermore, many BPR projects have failed (Willcocks and Smith, 1995).
Our aim in this paper is not to critique BPR per se, however; rather, our research has the
more limited goal of simply evaluating BPR success and the success factor approach
which has been associated with it.
As was mentioned earlier, a substantial body of research in information systems has
been concerned with IS implementation and IS success. One of the major streams ofresearch in this area has been the factor research approach. The success factor approach in
information systems implementation research attempts to identify those factors (variables)
which have the greater influence on IS success. Quantitative data is collected from a
sample of implementation sites in order to determine the relative importance of these
variables on the outcomes of implementation (Kwon and Zmud, 1987). Most of the
research into IS success or failure has resulted in descriptive lists of factors that lead to
one or the other. The assumption seems to be that if the practitioner is aware of these
factors and addresses them during implementation, then the IS project is more likely to be
successful.
In a similar fashion, a number of researchers have attempted to identify those factors,
which are associated with BPR success. In the BPR literature, the following factors have
been suggested as increasing the likelihood of BPR success: senior management support
and vision (Hammer, 1990; Robb, 1995); a strong project leader who is well respected and
committed (Robb, 1995); staying focused (Hammer and Stanton, 1995); well estab-
lished objectives, with aggressive targets (Robb, 1995); a project team consisting of a
mix of staff and consultants; the very best staff in the organisation for various functional
areas; a well planned change management and communication strategy (Hammer and
Champy, 1993); an effective methodology (Hammer and Champy, 1993; Robb, 1995);
the breadth and depth of the project (Hall et al., 1993); and two way communicationregarding the re-engineering process (Evans, 1994).
Grover et al. (1995) identified a large number of problem or failure factors associated
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 397
8/12/2019 Larsen Case1
4/23
with BPR, which they classified into nine categories. These were, in order of severity
(from first to last): change management; technological competence; strategic planning;
time frame; management support; human resource; process delineation; project manage-
ment; and tactical planning.Although much BPR implementation research has used the factor research approach,
this approach has been criticised in the IS implementation literature. Firstly, the factor
approach tends to view implementation as a static process instead of a dynamic phenom-
enon, and ignores the potential for a factor to have varying levels of importance at different
stages of the implementation process. It also fails to explain the relationship among the
factors (Ginzberg, 1981; Lucas, 1981). Secondly, there has been a lack of consistency in
the IS research and very few factors have been shown to be important across multiple
studies (Kwon and Zmud, 1987). Thirdly, the factor research approach is based on an
underlying mechanistic view of information systems implementation (Myers, 1994). The
attempt to identify variables associated with some measure of implementation successassumes that each factor is an independent variable and overlooks the interaction between
them and other elements in the social and organisational context (Nandhakumar, 1996).
The factor approach can be contrasted with many other approaches to understanding IS
success and failure. The process research stream, for example, has focused on the devel-
opment of a project; these studies have focused on issues such as the relationship between
designers and users and the impact of a system on the organisation (e.g. see Kwon and
Zmud, 1987; Newman and Robey, 1992). We believe that an awareness of this and other
research approaches to IS implementation could be helpful to BPR implementation
researchers, who until now seem to have focused almost exclusively on the factor research
approach.The factor approach can also be contrasted with interpretive approaches, which assume
that people are active makers of their physical and social reality (Orlikowski and Baroudi,
1991), that people are actors not factors. Mouritsen and Bjorn-Andersen (1991) argue that
agents actively construct everyday interaction in accordance with their wants. Humans
are not, as seems to be suggested by the idea of human factor, merely an inactive
although problematic part of a system, something that can be optimised through selection,
education, and training (Mouritsen and Bjorn-Andersen, 1991; p. 312). Bussen and
Myers (1997) found that the broader contextual issues surrounding a particular IS imple-
mentation had a greater influence than previously identified narrowly focused factors.
The two concepts of success and failure warrant further discussion. In the BPR litera-
ture, success and failure are often taken for granted; since the BPR literature emphasises
short term financial criteria, it tends to be assumed that it is relatively easy to determine
whether a particular BPR project is successful or not. For example, Hammer cites a 75%
reduction in head count (Hammer, 1990), while other researchers cite order delivery time
reduced from 33 to 6 days (Davenport and Short, 1990), US$1 million per plan cost
reduction (McCloud, 1993) or reducing costs of errors in fulfilling orders by US$2 million
dollars (Bambarger, 1994).
We question the apparent ease with which BPR projects are labelled a success or failure
by outside observers. In the IS implementation literature, there continues to be consider-able disagreement concerning how these concepts should be defined (Lucas, 1975;
DeLone and McLean, 1992; Sauer, 1993; Myers, 1995; Seddon, 1997). Following
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417398
8/12/2019 Larsen Case1
5/23
Sauer (1993) and Myers (1995), we suggest that success or failure of a project can only be
determined by considering the opinions of the various stakeholders. It is also possible that
the opinion of stakeholders may change over time. A focus of this research, therefore, was
participants evaluations of the success or failure of the project and the way in which theirassessment of the project changed over the life of the project.
3. Research method
As was stated earlier, one of the main purposes of this research was to attempt to
understand the development and implementation of one BPR project over time. We
wanted to study one BPR project in depth, focusing on the process of BPR, the internal
and external factors or issues which influenced the process, the outcomes of the process,
and participants evaluations of the project. It was determined that the most appropriateresearch method for doing this was the interpretive case study.
Interpretive research focuses on the complexity of human sense making as the situation
emerges (Kaplan and Maxwell, 1994); it attempts to understand phenomena through the
meanings that people assign to them (Boland, 1985; Orlikowski and Baroudi, 1991).
Interpretive methods of research in IS are aimed at producing an understanding of the
contextof the information system, and theprocesswhereby the information system influ-
ences and is influenced by the context (Walsham, 1993).
The main value of the interpretive case study lies in itsdepth: as others have pointed out,
it allows the researcher to generalise from the case to theory, and to obtain deep insights
about IS phenomena (Walsham, 1995b). Conversely, one of its weaknesses is that it doesnot have much breadth (only one or a few organisations are studied). More extensive
discussions of the contributions which interpretive research can make to information
systems research can be found elsewhere (Walsham, 1995a; Walsham, 1995b; Myers,
1997a; Klein and Myers, 1999).
Data were obtained from formal interviews, numerous documentary sources, and many
informal discussions with some of the participants. Ten semi-structured interviews were
conducted with all the key players in the BPR project, including the project sponsor (who
reported directly to the CEO), process owner, members of the core BPR team, consultants
who supported the various phases of the process, and key users. The interviews lasted from
one to three hours. All interviews were tape recorded except one (the latter at the request of
the informant). The documents obtained included project deliverables, proposals, minutes
of meetings, internal newsletters and memoranda, annual reports, and articles from news-
papers and business magazines. The research was conducted by one of the authors over a
six-month period, from September 1996 to February 1997.
The focus of our analysis was one specific case of BPR, where we wanted to understand
the context and process of the project, and participants views concerning its success. The
data were used to construct an historical narrative of a BPR project in a financial services
company in New Zealand, from inception to final implementation. We paid attention to the
broader social and organisational context within which the project took place, andexplored the multiple interpretations of various participants over time. The primary criter-
ion we used for assessing the validity of our interpretations was the hermeneutic one of
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 399
8/12/2019 Larsen Case1
6/23
seeing if they made sense (Myers, 1997b) and were believable both to ourselves and to
all the key people involved with the BPR project. Walsham suggests that the validity of
interpretive case study research depends on the plausibility and cogency of the logical
reasoning used in describing the results from the cases, and in drawing conclusions fromthem (Walsham, 1993, p. 15). We believe that this paper, while narrow in scope, offers
broad insights into the context and process of BPR.
4. The BPR case study
Alpha NZ Limited (a pseudonym) is a member of the New Zealand financial services
industry. Alpha was incorporated as a private company in 1986, comprised of nine sepa-
rate regional subsidiary financial service companies, all offering the same core financial
services. Each of the nine regional companies had their own regional head office whichserved as a regional processing centre for various functions for the company, and a number
of branches in various locations in that particular region. Each regional company had its
own accounting department, which performed tasks such as asset management, accounts
payable processing, management accounting, financial accounting, and reporting.
Management determined that the objectives of the BPR project in question were to
improve customer service, reduce costs, and improve the quality of the work performed.
The need for this was driven by deregulation of the financial services industry in New
Zealand in the late 1980s; increased competition, and the inefficiencies inherent in the
company due to the earlier merger of the nine separate regional companies. The project
used the standard BPR methodology of Gamma Consulting (a pseudonym for a large,multinational consulting firm).
4.1. The PQI movement
In order to understand how and why the BPR project was launched, we believe it would
be helpful to briefly review some of the key events and initiatives which led up to it. In
1993 (one year before the BPR project began) one of the regions of Alpha NZ Ltd
developed a quality program called PQIshort for Process Quality Improvement..
The objectives of this program were to improve the service to the customer, both internally
and externally. This program with its focus on the customer was welcomed by seniormanagement since this focus was not prevalent in the organisation at the time.
In view of the perceived success of PQI (at least in the eyes of senior management) and
the profitability of this one region, the leader of the PQI programme was invited to Alpha
NZ Ltd. Head Office in Wellington to help adopt this program for Alpha as a whole. As
part of this PQI initiative the management team appointed a consultant from a small
consulting firm, who took responsibility for this project. The consultant reported to the
Managing Director. Subsequently a new Alpha NZ Ltd vision and strategy was developed
called Service 2000. A travelling road show was created in which the Service 2000
initiative was presented to the regions and branches.
In the 1993 Half Yearly Report, the Managing Director commented on the PQI launch:
During the period, the Group took a significant step towards achieving the goals of
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417400
8/12/2019 Larsen Case1
7/23
its Service 2000 quality process with the launch of a PQI programme. PQI is
designed to bring together the Groups family of companies in an integrated way.
Using international benchmarks, the Group is reviewing all aspects of its operations
to establish the most efficient way of delivering services. The aim is to free staff so
they can more effectively meet the changing needs of customers.
With regard to this PQI initiative, one Alpha staff member commented:
It was really trying to bring about a focus on customer service and quality of every-
thing that was done in the organisationIt was really saying that in the competitiveenvironment(that we found ourselves in) we couldnt continue as we were. And it
was time to review the way that we were structured and our general direction and our
key strategic objectives.
Along with the PQI initiative, three main projects were launched at this time, concerned
with Distribution and Strategy, Organisation Review, and Effective Customer Service.
The Organisation Review was given the responsibility for investigating the various func-
tions of the Head Office and the nine regional head offices, and indicating areas for
improvement. These developments are summarised in Fig. 1 above. As can be seen, the
internal PQI initiative which began in July 1993 led to an organisation review which inturn resulted in four key areas of the organisation being selected for further review and
redesign.
4.2. Re-engineering the accounting processes
Following on from the overall organisation review, four key areas of the organisation
were selected for further review and redesign. These were accounting, marketing, lending
and credit, and other head office functions. In order to focus our research efforts, we
decided to concentrate on the accounting redesign project only.
A project team was formed in February 1994 to redesign and implement new accountingprocesses. Five people from Alpha were appointed to the project team, including senior
accounting people from both the head and regional offices.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 401
Fig. 1. The PQI initiative.
8/12/2019 Larsen Case1
8/23
The first task was to select a consulting partner to aid in the redesign project. Of the
three consultancies contacted, Gamma Consulting was selected. Since Gamma was part of
a large international consultancy firm, it was felt that they had the expertise and knowledge
required. Two Gamma consultants were assigned to the project team, one of whom was
considered by the team as a BPR guru. His previous experience involved redesigning a
global financial institution based in the UK, and he was also involved full-time in two
other enterprise-wide re-engineering projects in New Zealand.
The senior consultant from Gamma Consulting explains what happened next.
We went for a chat with some of the accountants. We took them for a coffee and a
drink and talked to them about the way that we would go about doing the job. This
was a piddly little (project) in their mind, a 30 K deal. Pay peanuts and you get
monkeys dont you? They wanted a 30 K deal to redesign the accounting
processBy the time wed finished, we had explained to them we were going to
try to find out what accountants did, and do it properly. You cant do better than that.
As can be seen, the senior consultant from Gamma believed that the project would be
much larger than the Alpha accountants envisaged. According to him, Alpha NZ Ltd. had
about six different approaches to re-engineering. He was concerned about their piecemealapproach, but he felt that he was able to convince the members of the project team that the
scope of the new BPR project should be established as including all the processes within
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417402
Fig. 2. The Gamma consulting re-engineering methodology.
8/12/2019 Larsen Case1
9/23
the accounting function. He also managed to convince the project team to use the standard
BPR methodology used by Gamma Consulting. It was from this point on, therefore, that
the project started to be labelled as BPR (the former term PQI now fell into disuse). The
BPR methodology as used by Gamma Consulting is illustrated in Fig. 2 above.In this methodology, the Data Gathering and Interview steps come first. These steps are
followed by various steps concerned with the analysis of activities, options and costs. For
example, the Responsibility Authority Expertise Work (RAEW) matrix helps to identify
key processes for improvement. The final report incorporates recommendations for the
redesign of management structures and processes.
In the first phase at Alpha, 60 people were interviewed from the nine regions over the
next four weeks. The interviewees included senior management, internal audit, and users
of the accounting information. Before the interviews were completed, the two Gamma
consultants approached two leading members of the project team and voiced their concern
that the project team as a whole would not support the recommendations that they believedwere needed. The consultants feared that the project team might be reluctant to support
any major redesign initiatives, particularly if this involved re-structuring the organisation
and a substantial number of people being made redundant. However, the two Alpha project
team leaders expressed confidence in the team members as whole. They raised a different
concern viz. that the senior Gamma consultant, the BPR guru, had left most of the work
to his more inexperienced colleague (the junior consultant did in fact possess considerable
business experience, especially with finance/banking audit clients, but lacked experience
in the BPR methodology). It was obvious to the Alpha NZ team members that the junior
consultant had not been through this process before, and due to his inexperience they felt
that they were lacking clear direction. Despite these reservations on both sides, GammaConsulting agreed to continue with the project.
A benchmarking study against Alphas seven major competitors indicated that Alpha
NZ Ltd. had the second highest staff levels compared to its main competitors, and the
second highest salary cost. However, the salary per employee was the lowest of the seven
competitors who responded to the questionnaire. This was interpreted as resulting from the
fact that Alpha had a large number of clerical accounting staff. Only 27% of the accounting
employees were accredited members of the Institute of Chartered Accountants of New
Zealandthis contrasted with one competitor where 80% of its employees were accre-
dited.
The benchmarking also revealed that six of the seven competitors were producing
monthly reports up to four days faster than Alpha after the month end close. Also, only
one of its competitors was using a custom written general ledger and subsidiary systems
such as accounts payable. The other six competitors were using commercially available
packages, with little or no customisation by in-house IT people. Additionally, the bench-
marking illustrated that none of the seven competitors managed a decentralised accounting
function, and only two of the seven had distributed some accounting functions into the
business units.
Subsequently a workshop was held on Gamma Consulting premises, in order to take the
project team away from the Alpha NZ Ltd. environment. The workshop was facilitated bythe BPR guru from Gamma Consulting. The project team agreed on the following
recommendations: (1) re-engineer the recording and reporting processput responsibility
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 403
8/12/2019 Larsen Case1
10/23
back to the manager for their business; (2) automate routine accounting functions
develop a new integrated ledgers system; and (3) provide fingertip access to financial
informationdevelop a new integrated financial reporting and information system. It was
proposed that the new information systems would be selected and implemented within 18
months.
As part of the re-engineered accounting processes, a new corporate accounting team
would be established. This team would be a highly skilled and motivated group of people,
service driven and customer focused. The team members would be highly paid and
supported by the Group Manager of Finance and Treasury. The central accounting team
was to be responsive to service requirements, and be comprised of members with specia-lised expertise. The team would have responsibility for accounts payable, accounts recei-
vable and fixed assets; statutory and prudential reporting; procedure and policy formation;
systems accountants; and treasury accounting.
In addition to the establishment of a new corporate accounting team, a new position was
to be created in each of the nine regional companies, called a Regional Financial Adviser
(RFA). The RFAs would be responsive to service requirements and would proactively
provide financial insights and direction to the management team of each regional
company. The idea was that the RFAs would think strategically and proactively rather
than transactionally and reactively, and would be seen as valued, equal members of the
local management team. A Financial Adviser would also be appointed at head office. The
proposed organisational structure is shown in Fig. 3 above.
A major change to the recording and reporting process was facilitated by the idea that
people who order goods and authorise payments should input the data into the system
directly. This affected the accounts payable sub-process, which originates with a business
manager or person purchasing an item, through to receipt of the item for service and
payment.
These recommendations, along with some others, were presented to the management
board in May 1994. With an 88% reduction in headcount proposed in some areas, and clear
cost savings identified, the recommendations were accepted.In July 1994 a communication pack was sent to the managers of all the regional
branches. In this pack it was indicated that all accounting positions within Alpha NZ Ltd.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417404
Fig. 3. The proposed organisational structure.
8/12/2019 Larsen Case1
11/23
would be disestablished, and existing staff would need to apply for a new position with
the company. The process of re-deployment was also outlined in the communication pack.
4.3. Implementation
The beginning of the implementation phase was preceded by selecting an implementa-
tion-consulting partner. Of four consulting firms invited to propose, Omega Consulting
was selected primarily because one of the leading consultants within Omega seemed to
have the necessary people skills that the Alpha project team were looking for. Omega
also agreed to risk 15% of their consultancy fees against the success of the project.
The consultant from Omega Consulting recommended using his firms methodology for
selecting a new financial information system. This methodology for the selection and
implementation of integrated packages can be broken into two clear sub-phases: (1)
Design, Requirements Definition and Selection; and (2) Implementation.The first sub-phase involved creating the design of the accounting procedures and
processes (to a more detailed level than the first design phase), building the detailed
requirements for the new systems, and selecting a new integrated financial information
systems. At the beginning of this phase (early September 1994), the success criteria for this
phase of the project were defined by the project team and approved by senior management.
These criteria were as follows:
selection of a financial systems solution by 31 March 1995;
implemented processes and systems in a test environment by 1 October 1995; and
live operations systems and fully implemented organisation infrastructure by 31 Janu-ary 1996.
In terms of implementation, some specific measurable elements were considered, such
as appropriateness of systems design, adequacy of user training and so on. Some key
assumptions were factored into the success criteria, such as availability of Alpha resources
with the necessary skills; deliverables from resources external to the core project team
being on time; sufficient authorisation to push through new procedures and practices; the
ability to obtain additional resources if required, subject to budgetary constraint; the scope
of the project being not significantly affected by other initiatives; and the required tech-
nology infrastructure being implemented by required time scales. The summary and
detailed management plans were completed by mid-September 1994.
One of the most urgent tasks was now seen as preparing new job descriptions and
recruiting for these positions, as the plan to disestablish all accounting positions was
known to all staff. Alpha NZ Ltd. needed to retain their best people for these positions and
so wanted to recruit them for the new positions as soon as possible. Therefore manage-
ment started to appoint people to these new positions even while they were still performing
their existing jobs. This overlapping was necessary in view of the 18 month implementa-
tion time of the new information system and accompanying organisational structure.
In October 1994 a Request for Information (RFI) was issued to a large number of
vendors. After analysing the responses, a vendor shortlist was created. A detailed Requestfor Proposal (RFP) was prepared in November and the short-listed vendors given three
weeks to respond. After various demonstrations, reference site checks, and an evaluation
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 405
8/12/2019 Larsen Case1
12/23
workshop attended by members of the project team, SAP emerged as the preferred vendor.
By February 1995 a contract was signed with SAP. The project team agreed that the
functionality of SAP best met the needs of Alpha NZ Ltd. The process of selecting a
vendor and specific software (the first sub-phase of Omegas implementation methodol-
ogy) is summarised in Fig. 4 above.
The second sub-phase of Omegas methodology for the selection and implementation of
integrated packages now began (i.e. implementation). In March the project team attendeda three-week in-depth training course in Sydney, Australia, while the hardware and soft-
ware was being installed at Alpha NZ Ltd. Over the next six months detailed software
development work was conducted until September 1995, at which point the acceptance
testing was completed. User training began in October and continued to the beginning of
December. Also in October, a parallel run was commenced, with the Wellington branch
chosen as the test site. After almost two months the parallel run confirmed that the
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417406
Fig. 4. The design, requirements definition and selection process.
Fig. 5. The SAP implementation process.
8/12/2019 Larsen Case1
13/23
interfaces were working correctly and the system was ready for use. The new information
system went live in all branches on 1 December 1995.
During December 1995 and January 1996 all the changes to the organisation structure,
business functions and staff which had been recommended earlier were put in place. On 31January 1996, those staffs who were not able to be re-deployed were made redundant. The
accounting staff full time equivalent (FTE) fell from 75 to 24, a headcount reduction of
68%.
Therefore, by the beginning of February 1996, the new systems were implemented, the
new processes in place, and the new head office accounting team were established. On 8th
March 1996 the project was signed off by Omega Consulting and passed to the project
sponsor, and a Project Sign Off Report was delivered to Alpha NZ Ltd. from the project
manager. Omega Consulting was paid its commission in full. The process of implementing
the SAP software (the second sub-phase of Omegas implementation methodology) is
summarised in Fig. 5.
4.4. Post implementation
The following months did not proceed so smoothly as the ones just gone. With some
members of the project team being made redundant, one member joining Omega Consult-
ing as an IT consultant, and others being moved sideways, none of the original project
team members were left in group accounting. All in-house expertise had disappeared from
the central accounting group.
Some report development was identified in the Project Sign Off Report as an uncom-
pleted task of the project, and some new report development was also suggested (theidentification of these reporting needs arose towards the end of the project implementation
phase). However, due to the low level of skill present at the accounting head office with
regard to the use of the new system, this task was not completed. Other new management
reports were identified likewise, but these too were not forthcoming.
In April 1996 the Regional Financial Advisers met to discuss their difficulties in the
post-implementation period. The main area of difficulty identified was the lack of report-
ing from the new system. The majority of the statutory reports had been developed and
they were considered to be superior to the statutory reporting previously available under
the old system, however the lack of management reporting was starting to cause difficul-
ties. One Regional Financial Adviser (RFA) commented There was a lack of leadership
and buy-in from Group Accountingit was evident to all the RFAs (at our meeting). In
response to these difficulties and to satisfy increased user expectations, Group Accounting
agreed to hire a consultant from Omega Consulting to write the new reports.
In April 1996, however, it was announced that Beta Limited (a pseudonym) had the
intention to purchase 100% ownership of Alpha NZ Ltd. shares, and a merger would be
taking place. As soon as the merger was announced, a moratorium was placed on hiring
new staff, and the development of management reports was placed on hold until the future
of the system and the requirements of the new company could be determined. New
reporting requirements for Beta Ltd. were given top priority and existing resourceswere diverted to develop these reports for the new owners.
A post implementation review was conducted in early April. This involved interviewing
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 407
8/12/2019 Larsen Case1
14/23
key staff and preparing a report for the executive committee overseeing the merger. One of
the findings of this report was that staff morale was low in the head office accounting team.
This was believed to be partly caused by poor management and poor leadership skills. The
staffs had undergone a major structural and process change, and were not being adequatelysupported by their manager. Further, the lack of skill and expertise in the system they were
now using was low, and affected their confidence in it. The recent announcement of the
merger had also de-stabilised their future with the company, and many were feeling
insecure about their positions. Staff morale had plummeted.
By September 1996 there were no longer any accounting staff in any of the regional
companies. The Regional Financial Advisers (who had been appointed as a result of the
project) were made redundant and their work re-centralised. Group Accounting Alpha NZ
Ltd. was merged with Group Accounting Beta Ltd. and there were a number of redun-
dancies here also. The newly merged company received a name change, and is now known
as Beta-Alpha Ltd. (a pseudonym).In October 1996 it was announced that Beta-Alpha Ltd. would be implementing Oracle
financials as their back office accounting system in place of the existing SAP system. Beta
Ltd. Australia (which owned the NZ organisation) mandated that the system they had
previously selected as their core financial MIS was to be implemented in their New
Zealand subsidiaries also. The devolvement of invoices to line managers was also re-
centralised to the new Group Accounting team. In effect, this meant that almost all of the
changes and systems that had been implemented as part of the BPR project at Alpha had
now been discarded.
5. Analysis of the case study
5.1. A summary of the case
We have seen that, although Alpha NZ Ltd. had developed its own approach to business
process improvement early on (called PQI), the consultants from Gamma Consulting
managed to convince the Alpha project team that the companys previous approach was
piecemeal. The consultants suggested that Alpha should use Gammas standard BPR
methodology, and that all of the accounting and management reporting processes should
be re-designed at once. Clearly, the consultants believed that their own professionalapproach to BPR was better than Alphas own in-house efforts, although it may well be the
case that the use of Gammas standard BPR methodology made it easier for them as well
as being in accordance with Gamma company policy (c.f. Orlikowski, 1991).2 The project
was thus redefined and renamed as BPR by this large international consulting firm.
It is somewhat debatable as to whether the project can be genuinely classified as BPR.
While the Gamma consulting methodology, as shown in Fig. 2, involved identifying and
documenting key processes for improvement, there was little business process mapping
and redesign as is usually associated with classical BPR methods. On the other hand, the
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417408
2 See also Orlikowski (1991), who discusses, amongst other things, the importance which one internationalsoftware consulting firm placed on the use of its standard information systems development methodology by its
clients.
8/12/2019 Larsen Case1
15/23
two consulting firms (both of which are amongst the Big Five) unequivocally described the
project as BPR from start to finish. Their recommended BPR approach was to select an
integrated package in what can be best described as package-driven re-engineering.
Our view is that the package-driven re-engineering approach of the two internationalconsulting firms can be classified as business process re-engineering, even if it is not
classical BPR. The key idea of this approach is to redesign the business processesbefore
implementing an ERP system, but to limit the process changes to those are supported by
the best practices built into current ERP packages. The business processes themselves
are thenimplementedby installing an ERP system. In other words, the implementation of
an ERP enables the implementation of the redesigned processes, and both these events
occur simultaneously.
The objectives of the BPR project within Alpha NZ Ltd. were to improve customer
service and quality, and reduce costs. The immediate outcome was the creation of a new
accounting organisational structure, new work processes, and a new financial informationsystem. A 64% reduction in FTE accounting staff from 67 to 24 was experienced, with
projected savings of approximately $2.1 million per annum.
Some three months after the go live date, however, news of a merger halted all further
post-implementation work. This included the development of important user reports.
Following the merger, the structures of Alpha NZ Ltd. were merged with those of the
new owner, and many of the new processes and structures were undone. A new infor-
mation system was to be implemented by the end of 1997 to replace the SAP solution
implemented as part of the BPR project.
5.2. A BPR success or failure?
We would now like to consider the question of whether the BPR project at Alpha NZ
Ltd. was a success or a failure.
If we were to end the story of the BPR project in February/early March 1996, an
assessment of the project would most likely be favourable (if one excludes those made
redundant, that is). Everyone involved with the project agreed that the short term financial
savings were considerable, with a 64% reduction in FTE accounting staff and projected
savings of approximately $2.1 million per annum.
Some two months later, however, the picture had changed considerably. An unintended
consequence of the BPR project was that none of the original project team members were
left in group accounting, and all in-house expertise had disappeared from the central
accounting group. Those now in the accounting head office had a low skill level, and
morale was low.
It could be argued that the BPR project contained the seeds of its own destruction. Its
financial success was only achieved by a dramatic reduction in headcount, but those who
left the company were arguably the most skilled and capable within the Alpha accounting
function. The dramatic reduction in headcount looked good on paper, but by losing some
of its best people, the capacity of the organisation to respond to future events was drama-
tically impaired. It appears that the problems which emerged (such as the lack of manage-ment reporting with the new system, the low skill levels of staff) were a logical
consequence of the BPR project itself.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 409
8/12/2019 Larsen Case1
16/23
In our view the loss of the most skilled and capable people from the central accounting
team at Alpha was a serious mistake. A few months after implementation, not one person
in-group accounting had the expertise or the skills to use SAP properly. When the re-
engineered Alpha company was taken over by Beta Ltd., the latter company had anexcellent excuse to undo all of the changes which had been made. Indeed, it would appear
that this step was almost inevitable, given the inability of the remaining Alpha staff to use
the new system profitably.
Approximately six months after the project was completed, some of the various stake-
holders were asked their opinion concerning the success or failure of the BPR project.
The BPR guru from Gamma Consulting believed that the BPR project was a resound-
ing success. He said:
It was a phenomenal integrationIt was a piece of good professional work, that
went far beyond what I think they had expected of it. And the opportunities it gave
themIm proud of it. I think we did a good jobWe came up with something at
Alpha Ltd., which was out of this world. Nobody else up to that point had anything
like it.
The project manager from Omega Consulting also believed that the project was a success.
The project achieved what it set out to do, and Omega was paid its commission in full. He
explained:
Yes, (it was a success) because Alpha NZ Ltd. was always going to be sold off.
Right? It was targeted from the day I joinedThe payback on SAP was already
there by the time Beta Ltd. in fact took over. People ask me this question, and I think,yes absolutely. I mean we were packaging Alpha for sale. The market always knew
that Alpha was going to be taken over.
All of those involved in the BPR project team also believed that the project was
successful, although they were not as positive as the consultants from the two consulting
firms. One Group Manager on the project team commented that the success was due to
strong CEO commitment, good effective project sponsorship, good communication, and
regular planning, review and control. With further questioning, however, this manager
admitted that the lack of ongoing ownership by the head office group accounting team after
implementation was a problem and that the users were dissatisfied. She said that the
majority of people appointed to the new positions in head office did not have sufficient
skill and experience for the roles they were appointed to, and the ability and commitment
of these people was questionable.
I think the main reason things didnt work out like they were supposed to was
something that I didnt really have control overthe staff appointments in Group
Accounting, the peopleWe identified key people within the organisation to
trainand we had specific people down for training, and some of them just wouldnt
turn up for it.
Another person on the project team was the Group Accounting System Accountant. Hebelieved that the project was successful overall and attributed success to the key factor of
management commitment. However, he too commented that ownership of the system by
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417410
8/12/2019 Larsen Case1
17/23
Group Accounting was a problem and said that the project could be seen as unsuccessful
in final delivery in terms of Group Accounting being the ultimate (end user) of the
system.
The reaction of the users was not nearly as positive as the consultants or those on theproject team. One of the newly appointed Regional Financial Advisers believed that the
project was a failure. While the new processes and structure had been put in place, the lack
of reporting was a serious problem. She commented:
The main advantage (of the project was supposed to be) the great computer system
with all reporting on the system, and therefore RFAs could analyse and interpret the
information and provide commentaryBut this never happened to the extent they
envisaged.
This person, along with all the other RFAs, was expecting a level of information to be
provided by the new system, which did not eventuate. The lack of management reports hadcaused considerable dissatisfaction.
The Manager of Retail Services said that the project was successful except that it failed
to deliver what was expected in terms of management reporting. He commented:
As users from the company, then, we did not get what we wanted out of the new
accounting system, and our requirements were actually quite clearly documented-
After he (a particular member of the project team) left, they seemed to be sidelined
on another task, and we then had to deal with X (another person) and say, look, we
need these, when are they going to be done?And the deadlines were not met, not
met, not met. And theyre still not met.Another user claimed that the project failed because of the lack of reporting. One Group
Accounting Manager commented that not retaining the in-house project team members
was a mistake.
It can be seen, therefore, that two main groups of stakeholders, the developers and the
users, did not agree on the success of the BPR project, neither did they agree on those
factors which led to success or failure. The one point on which almost everyone
agreed was that there was a lack of ownership from Group Accounting and the Group
Accounting Manager in the post-implementation phase. However, as we said earlier, the
low-skill level in-group accounting was a logical outcome of the BPR project itself.
It is also interesting to note the significant difference between what was proposed for
Group Accounting and the eventual outcome. According to the original project proposal
the new corporate accounting team was supposed to be a highly skilled and motivated
group of people, service driven and customer focused. The team members would be
highly paid, responsive to service requirements, and be comprised of members with
specialised expertise. But as all those involved with the project acknowledge, this vision
for Group Accounting did not eventuate. The majority of people appointed to the new
positions in head office did not have sufficient skill and experience for the roles they were
appointed to, and, according to some on the project team, the ability and commitment of
these people was questionable. Although most of those on the project team blamed thepeople themselves for their lack of commitment, it is hard to see why these people should
have been highly motivated and committed when all previous in-house expertise had
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 411
8/12/2019 Larsen Case1
18/23
disappeared (either through redundancy or people obtaining work elsewhere). When the
company announced in 1994 that all accounting positions at Alpha would become dises-
tablished and that existing staff would need to apply for new positions, many of the best
people left for positions elsewhere, and many of those that stayed with the company feltinsecure about their positions. We suggest that the lack of expertise and low morale were
thus a logical consequence of the dramatic reduction in headcount that was envisaged and
achieved.
It is interesting to note that all the participants did not perceive the take-over of Alpha
by Beta Ltd. to have affected the success of the project. They all recognised that the
strategic direction, mission, and culture of the new company were different to Alphas.
As a subsidiary company, Alpha NZ Ltd. had no choice but to merge with Beta Ltd.,
therefore this was not believed to indicate (or be a factor in) the failure of the BPR project
in any way.
6. Discussion
As was mentioned earlier, most BPR implementation researchers have focused almost
exclusively on the factor research approach. This approach attempts to identify those
factors associated with BPR success or failure. In our literature review, however, we
showed that the factor research approach has been criticised in the IS implementation
literature. We suggested that an awareness of the criticisms of the factor research approach
could be helpful to BPR implementation researchers.
Further to that discussion, we are now in a position to comment further on the factorresearch approach. First, the Alpha NZ case has shown that attention to success factors can
limit the focus on success to immediate implementation outcomes. The package-driven
BPR project was deemed to be successful by Alpha management when SAP went live, and
Omega Consulting was paid its commission in full. The staff reductions and the projected
cost savings made the project look good on day one. But as we have seen, a focus on
immediate success does not necessarily equate to success a few months down the track.
The focus on immediate success is thus too narrow.
Second, package-driven BPR by its nature focuses consultants and vendors on imple-
menting the package rather than continuing operation. This case draws attention to the
dangers of concentrating too hard on factors leading to successful package implementa-
tion and immediate BPR savings. While the system was implemented on time and within
budget, the long-term implications of the changes were more worrying. The dramatic
reduction in headcountand the corresponding loss of knowledgeactually impaired
the capacity of the organisation to respond to future events.
Third, the key dependent variable in the factor research approach (success) has been
shown to be rather difficult to define. Success is open to many different interpretations.
Indeed, if one considers the views of the various stakeholders, as is suggested by Myers
(1995) and Sauer (1993), then it appears that the labelling is more of a political declaration
made by interested parties than it is a statement of factsuccess depends upon who youtalk to. From this perspective it is understandable why the various stakeholders voted the
way they did: firstly, the consultants judged the project an unqualified success since they
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417412
8/12/2019 Larsen Case1
19/23
were the ones that promoted BPR in the first place and were paid to do it; those involved
with the project team unanimously viewed the project as a success since they were the
ones primarily responsible for the end result; the users, by contrast, were somewhat mixed
in their evaluation, since they seemed to have gained least from the new system. Also,those who were appointed to the new positions in Group Accounting were not the
highly paid, specialised experts that were promised.
It is rather difficult to definitively class the project as either a success or a failure.
The arguments in favour of the project being a success are as follows. First, most of the
factors (reviewed earlier) correlated with success were indeed present in this case (e.g.
senior management support and vision was present, as was a strong project leader).
Additionally, staff in the project team came from both the regions and the head office,
and could therefore understand the organisation structure, culture and processes from each
perspective. All members of the team indicated that the team environment and spirit was
one of the aspects they enjoyed most about the project.Second, it was suggested by some of our informants that the decision by Beta Ltd. to
merge the two companies, disregard the changes and replace the information system was
purely a political one (in fact one senior manager claimed that there was no review to
determine if SAP was the best product for the New Zealand operationsthe new owner
simply stated that Oracle was to be implemented). If this is the case, then those involved
with the BPR project at Alpha can hardly be blamed for failure.
Third, if one of the consultants from Omega Consulting is correctthat the whole point
of the BPR project was to prepare Alpha NZ Ltd. for salethen the project can be said to
have achieved its purpose. Taking all these things together, the project looks like a
resounding success.There are a number of reasons for regarding the BPR project as a failure, however. First,
the new system itself was discarded by Beta Ltd. Although Betas decision may have been
influenced by an overriding requirement to achieve integration between the two organisa-
tions, the user dissatisfaction with the new system and the lack of skill within Alpha group
accounting certainly gave Beta Ltd. an excellent reason to scrap the system. Second, the
claim that the BPR project was intended to prepare Alpha for sale was made by one of the
Omega consultants some six months after the project was completed. There was no hint of
a takeover earlier on in the project (for example, none of the consultants from Gamma
mentioned such a possibility). This leads us to believe that the claim of preparing Alpha
for sale was most likely one of post-hoc justification.
An assessment of the success or failure of the project also varies depending upon
the time at which the evaluation is done. In February/early March 1996, immedi-
ately after the new information system was implemented, the Project Sign Off
Report indicated that the success criteria as outlined earlier in the project plan
had been met. The projected financial savings were considerable. As a result
management agreed to pay Omega Consulting its 15% retainer for successful
completion of the project. Only a few months later, however, the post implementa-
tion review found that staff morale in the head office accounting team was low. The
newly appointed Regional Financial Advisers and the users in Group Accounting weredissatisfied with the lack of management reporting. Since the RFAs did not have the
necessary information to think strategically and proactively as was originally envisaged,
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 413
8/12/2019 Larsen Case1
20/23
it is perhaps not surprising that they themselves were made redundant following the
merger with Beta Ltd.
This leads us to suggest that narrow-focused, head-count cutting BPR is particularly
susceptible to time-dependence of evaluation outcomes. As Galliers (1997) points out,there is a significant risk of loss of knowledge in radical BPR. But the realisation that
valuable knowledge has been lost might only occur when it is too late. This particular case
study has illustrated how a BPR project, deemed to be a success when it was first
completed, can soon turn to failure. The overriding goal to achieve short-term financial
success can lead to serious organisational problems over the longer term.
7. Conclusion
In this paper we have discussed a BPR project that involved the implementation of anERP software package. The BPR project involved redesigning the accounting processes of
a financial services firm in New Zealand.
Although the project was deemed to be a success when the system was first delivered,
the project ended up as a failure. While the short term financial results were spectacular
(e.g. headcount reduction of 68%), the long-term implications of the changes were more
worrying. At the conclusion of the project Alpha NZ Ltd. had staff in the newly centralised
accounting group with low skill levels and low morale. The loss of all in-house expertise
from the central accounting team was disastrous.
This case study has shown that IS success is a moving target. The attribution of
success can vary dramatically depending upon the time at which the evaluation is done.While the BPR project discussed here was regarded as a success at the time of imple-
mentation, it was not regarded as such just a few months later.
Our findings also call into question some of the underlying assumptions of factor
research. One of these assumptions is that the success and failure of any particular
project is relatively easy to determine (as if these terms represent objective states). The
assessment of success or failure is often taken for granted, not only of one project, but of
several. But as we have seen, the extent to which a project is successful or not is not easy to
gauge. The extent to which the project was seen as a success varied considerably amongst
the various stakeholders and their views changed over time. In this instance, the labelling
of the project as a success or failure seems to have been more of a subjective judgement
made by interested parties than an objective fact. We believe that some caution is
therefore advisable when researchers assume that one or more BPR projects are successes
or failures.
Another underlying assumption of the factor research approach is that, if only practi-
tioners can be made aware of the factors that lead to success (or failure), then BPR
implementation is more likely to be successful. But as we have seen in this case, short-
term success may lead to failure further down the track. While the success criteria as
outlined in the project plan were achieved, it was only some months later that serious
problems became apparent (e.g. the low level of skill and morale at head office). We hopethat further research will shed more light on the long-term implications of BPR and on its
implementation and evaluation.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417414
8/12/2019 Larsen Case1
21/23
Acknowledgements
We are grateful to all those who agreed to be interviewed and who gave access to
company data. We would also like to thank the Management Consulting staff in theKPMG Auckland office and the University of Auckland Business School for some finan-
cial assistance. Additionally, we are grateful to the Associate Editor and the reviewers for
their critical and constructive comments on an earlier version of the paper. This manu-
script is a substantially revised version of a paper which was presented at the Eighteenth
International Conference on Information Systems in Atlanta, Georgia, from 1517
December 1997, and was published in its proceedings.
References
Alavi, M., Joachimsthaler, E.A., 1992. Revisiting DSS implementation research: a meta-analysis of the literature
and suggestions for researchers. MIS Quarterly 16, 95113.
Bailie, J., 1995. Should personnel managers be more critical of BPR?. Personnel Management, 55.
Bambarger, B., 1994. Corning Asahi Video Products Co. Eliminates Cost of Errors for $2 Million Savings.
Industrial Engineering July, 2829.
Benjamin, R.I., Levinson, E., 1993. A framework for managing IT-enabled change. Sloan Management Review
34 (4), 2333.
Boland, R., 1985. Phenomenology: a preferred approach to research in information systems. In: Mumford, E.,
Hirschheim, R.A., Fitzgerald, G., Wood-Harper, A.T. (Eds.). Research Methods in Information Systems,
North Holland, Amsterdam, pp. 193201.
Bussen, W., Myers, M.D., 1997. Executive information systems failure: a New Zealand case study. Journal of
Information Technology 12 (2), 145153.
Caron, J.R., Jarvenpaa, S.L., Stoddard, D.B., 1994. Business reengineering at CIGNA Corporation: experiences
and lessons learned from the first five years. MIS Quarterly 18 (3), 233250.
Carr, D.K., Johansson, H.J., 1995. Best Practices in Reengineering: What Works and What Doesnt in the
Reengineering Process, McGraw Hill, New York.
Childe, S.J., Maull, R.S., Bennett, J., 1994. Frameworks for understanding business process re-engineering.
International Journal of Operations and Production Management 14 (12), 2234.
Davenport, T.H., Beers, M.C., 1995. Managing information about processes. Journal of Management Information
Systems 12 (1), 5780.
Davenport, T.H., Short, T.E., 1990. The New Industrial Reengineering: Information Technology and Business
Process Redesign. Sloan Management Review Summer, 1127.
DeLone, W.H., McLean, E.R., 1992. Information systems success: the quest for the dependent variable. Informa-tion Systems Research 3 (1), 6095.
Evans, R., 1994. The human side of business process re-engineering. Management Development Review 7 (6),
1012.
Fielder, K.D., Grover, V., Teng, J.T.C., 1995. An empirical study of information technology enabled business
process redesign and corporate competitive strategy. European Journal of Information Systems 4, 1730.
Galliers, R.D., 1997. Against obliteration: reducing risk in business process change. In: Sauer, C., Yetton, P.W.
(Eds.). Steps to the Future: Fresh Thinking on the Management of IT-Based Organizational Transformation,
Jossey-Bass, San Francisco, pp. 169186.
Ginzberg, M.J., 1981. Key recurrent issues in the MIS implementation process. MIS Quarterly 5, 4759.
Glasson, B.C., 1994. Business process reengineering: information systems opportunity or challenge?. In: Glasson,
B.C., Hawryszkiewycz, I.T., Underwood, B.A., Weber, R.A. (Eds.). Business Process Re-Engineering:
Information Systems Opportunities and Challenges, North Holland, Amsterdam, pp. 16.Grey, C., Mitev, N., 1995. Re-engineering organisations: a critical appraisal. Personnel Review 24 (1), 618.
Grint, K., Case, P., Willcocks, L., 1996. Business process re-engineering reappraised: the politics and technology
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 415
8/12/2019 Larsen Case1
22/23
of forgetting. In: Orlikowski, W., Walsham, G., Jones, M.R., DeGross, J.I. (Eds.). Information Technology
and Changes in Organizational Work, Chapman and Hall, London, pp. 3961.
Grover, V., Jeong, S.R., Kettinger, W.J., Ten, J.T., 1995. The implementation of business process re-engineering.
Journal of Management Information Systems 12 (1), 109144.
Hall, G., Rosenthal, J., Wade, J., 1993. How to make reengineering really work. Harvard Business Review 71 (6),119131.
Hamilton, D., Atchison, M., 1996. The COMIS plan: IT mediated business reengineering in Telecom Australia
during the 1960s. In: Orlikowski, W., Walsham, G., Jones, M.R., DeGross, J.I. (Eds.). Information Technol-
ogy and Changes in Organizational Work, Chapman and Hall, London, pp. 89106.
Hammer, M., 1990. Reengineering work: dont automate, obliterate. Harvard Business Review JulyAugust,
104112.
Hammer, M., Champy, J., 1993. Reeingeering the Corporation: A Manifesto for Business Revolution, Nicholas
Brealey, London.
Hammer, M., Stanton, S.A., 1995. The Reengineering Revolution: a Handbook, Harper Collins.
Ives, B., Olson, M.H., 1984. User involvement and MIS success: a review of the research. Management Science
30 (5), 580603.
Jones, M.R., 1994. Dont emancipate, exaggerate: rhetoric, reality and reengineering. In: Baskerville, R., Smith-
son, S., Ngwenyama, O., Degross, J.I. (Eds.). Transforming Organizations with Information Technology,
North-Holland, Amsterdam, pp. 357394.
Kaplan, B., Maxwell, J.A., 1994. Qualitative research methods for evaluating computer information systems. In:
Anderson, J.G., Aydin, C.E., Jay, S.J. (Eds.). Evaluating Health Care Information Systems: Methods and
Applications, Sage, Thousands Oaks, pp. 4568.
Kettinger, W.J., Teng, J.T.C., Guha, S., 1997. Business process change: a studyof methodologies, techniques, and
tools. MIS Quarterly 21 (1), 5580.
Klein, H.K., Myers, M.D., 1999. A set of principles for conducting and evaluating interpretive field studies in
information systems. MIS Quarterly 23 (1), 6793.
Kwon, T.H., Zmud, R.W., 1987. Unifying the fragmented models of information systems implementation. In:
Boland, R.J., Hirschheim, R.A. (Eds.). Critical Issues in Information Systems Research, Wiley, New York,pp. 227251.
Lucas, H.C.J., 1975. Why Information Systems Fail, Columbia University Press, New York.
Lucas, H.C.J., 1981. Implementation: the key to successful information systems, Columbia University Press, New
York.
McCloud, J., 1993. McDonnell douglas Saves Over $1,000,000 per Plane With Reengineering Effort. Industrial
Engineering October, 2730.
Mouritsen, J., Bjorn-Andersen, N., 1991. Understanding third wave information systems. In: Dunlop, C., Kling,
R. (Eds.). Computerization and Controversy, Academic Press, San Diego, pp. 308320.
Myers, M.D., 1994. A disaster for everyone to see: an interpretive analysis of a failed IS project. Accounting,
Management and Information Technologies 4 (4), 185201.
Myers, M.D., 1995. Dialectical hermeneutics: a theoretical framework for the implementation of information
systems. Information Systems Journal 5 (1), 5170.
Myers, M.D., 1997. Qualitative research in information systems. MIS Quarterly 21 (2), 241242.
Nandhakumar, J., 1996. Design for Success?: critical success factors in executive information systems develop-
ment. European Journal of Information Systems 5, 6272.
Newman, M., Robey, D., 1992. A social process model of user-analyst relationships. MIS Quarterly 16, 249266.
Orlikowski, W.J., 1991. Integrated information environment or matrix of control? the contradictory implications
of information technology. Accounting, Management and Information Technologies 1 (1), 942.
Orlikowski, W.J., Baroudi, J.J., 1991. Studying information technology in organizations: research approaches and
assumptions. Information Systems Research 2 (1), 128.
Robb, D.J., 1995. Business Process innovation: re-engineering for operations renewal. Operations Management
Review 10 (3), 1215.
Robey, D., Smith, L.A., Vijayasarathy, L.R., 1993. Perceptions of conflict and success in information systemsdevelopment projects. Journal of Management Information Systems 10 (1), 123139.
Sauer, C., 1993. Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-on-Thames.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417416
8/12/2019 Larsen Case1
23/23
Seddon, P.B., 1997. A respecification and extension of the DeLone and McLean model of IS success. Information
Systems Research 8 (3), 240253.
Stoddard, D.B., Jarvenpaa, S.L., 1995. Business process redesign: tactics for managing radical change. Journal of
Management Information Systems 12 (1), 81107.
Swanson, E.B., 1988. Information System Implementation: Bridging the Gap between Design and Utilization,Richard D. Irwin, Homewood, IL.
Teng, J.T.C., Jeong, S.R., Grover, V., 1998. Profiling successful reengineering projects. Communications of the
ACM 41 (6), 96102.
Walsham, G., 1993. Interpreting Information Systems in Organizations, Wiley, Chichester.
Walsham, G., 1995a. The emergence of interpretivism in IS research. Information Systems Research 6 (4), 376
394.
Walsham, G., 1995b. Interpretive case studies in IS research: nature and method. European Journal of Informa-
tion Systems 4, 7481.
Willcocks, L., Smith, G., 1995. IT-enabled business process reengineering: organisational and human resource
dimensions. Journal of Strategic Information Systems 4 (3), 279301.
Willmott, H., 1994. Business process re-engineering and human resource management. Personnel Review 23 (3),
3446.
Willmott, H., Wray-Bliss, E., 1996. Process reengineering: information technology and the transformation of
accountability: the remaindering of the human resource?. In: Orlikowski, W., Walsham, G., Jones, M.R.,
DeGross, J.I. (Eds.). Information Technology and Changes in Organizational Work, pp. 6288.
M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417 417
Top Related