Journal of Strategic Information Systems 8 (1999) 395417 www.elsevier.

com/locate/jsis

When success turns into failure: a package-driven business process re-engineering project in the nancial services industry
M.A. Larsen a, M.D. Myers b,*
b a KPMG, 8 Salisbury Square, London, EC4Y 8BB, UK Department 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 rst delivered, this initial success soon turned to failure. While the short-term nancial 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 specic domains, such as Decision Support Systems (Alavi and Joachimsthaler, 1992), Executive Information Systems (Bussen and Myers, 1997), or Business Process Re-engineering (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;
* Corresponding author. Tel.: 64-9-3737-599, ext. 7468; fax: 64-9-3737-430. E-mail addresses: m.myers@auckland.ac.nz (M.D. Myers), melissa.larsen@kpmg.co.uk (M.A. Larsen). 0963-8687/99/$ - see front matter 1999 Elsevier Science B.V. All rights reserved. PII: S0963-868 7(00)00025-1

396

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

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 packagedriven re-engineering, the idea is to redesign the business processes before implementing an 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 specic focus of this paper is on the success of BPR projects, the ndings will also be of interest to those concerned with the implementation of ERP systems and the implementation 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-term nancial 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 packagedriven 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 nancial information system within one organisation in the New Zealand nancial services industry. One of the purposes of the research was to understand the development and implementation of a BPR project over time. The paper proceeds as follows: the following section discusses BPR, focusing specically 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 ndings. Section 7 presents the conclusions.

2. BPR success One of the difculties 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 denitions of the same term are used in different studies. This makes it difcult to compare studies (Childe et al., 1994). Rather than quibble about the denition of BPR, we prefer to take the pragmatic step of

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

397

simply using Hammer and Champys denition, which has been one of the most cited in the literature. Their denition is as follows: The fundamental rethinking and radical design of business processes to achieve dramatic improvement in critical, contemporary measures of performance such as cost, quality, service and speed (Hammer and Champy, 1993, p. 2). The underlying principles of the denition above are that re-engineering involves a focus on business processes, should question the fundamentals, the change should be radical, and the benets 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; Davenport and 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 of research 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 inuence 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 established 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 communication regarding the re-engineering process (Evans, 1994). Grover et al. (1995) identied a large number of problem or failure factors associated

398

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

with BPR, which they classied into nine categories. These were, in order of severity (from rst to last): change management; technological competence; strategic planning; time frame; management support; human resource; process delineation; project management; 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 phenomenon, 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 success assumes 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 development 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 implementation had a greater inuence than previously identied narrowly focused factors. The two concepts of success and failure warrant further discussion. In the BPR literature, success and failure are often taken for granted; since the BPR literature emphasises short term nancial 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 fullling 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 considerable disagreement concerning how these concepts should be dened (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) 395417

399

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 their assessment 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 inuenced the process, the outcomes of the process, and participants evaluations of the project. It was determined that the most appropriate research 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 context of the information system, and the process whereby the information system inuences and is inuenced by the context (Walsham, 1993). The main value of the interpretive case study lies in its depth: 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 does not 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 newspapers 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 specic 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 nancial services company in New Zealand, from inception to nal implementation. We paid attention to the broader social and organisational context within which the project took place, and explored the multiple interpretations of various participants over time. The primary criterion we used for assessing the validity of our interpretations was the hermeneutic one of

400

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

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 from them (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 nancial services industry. Alpha was incorporated as a private company in 1986, comprised of nine separate regional subsidiary nancial service companies, all offering the same core nancial services. Each of the nine regional companies had their own regional head ofce which served 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, nancial 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 nancial services industry in New Zealand in the late 1980s; increased competition, and the inefciencies 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 rm). 4.1. The PQI movement In order to understand how and why the BPR project was launched, we believe it would be helpful to briey 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 senior management 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 protability of this one region, the leader of the PQI programme was invited to Alpha NZ Ltd. Head Ofce 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 rm, 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 signicant step towards achieving the goals of

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

401

Fig. 1. The PQI initiative.

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 efcient 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 everything that was done in the organisationIt was really saying that in the competitive environment(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 functions of the Head Ofce and the nine regional head ofces, 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 in turn 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 ofce 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 accounting processes. Five people from Alpha were appointed to the project team, including senior accounting people from both the head and regional ofces.

402

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

Fig. 2. The Gamma consulting re-engineering methodology.

The rst 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 rm, 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 nancial 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 nished, we had explained to them we were going to try to nd 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 piecemeal approach, 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) 395417

403

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 rst. 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 nal report incorporates recommendations for the redesign of management structures and processes. In the rst 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 believed were 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 condence 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 nance/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, Gamma Consulting 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 accredited. 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 benchmarking 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 by the BPR guru from Gamma Consulting. The project team agreed on the following recommendations: (1) re-engineer the recording and reporting processput responsibility

404

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

Fig. 3. The proposed organisational structure.

back to the manager for their business; (2) automate routine accounting functions develop a new integrated ledgers system; and (3) provide ngertip access to nancial informationdevelop a new integrated nancial 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 specialised expertise. The team would have responsibility for accounts payable, accounts receivable and xed 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 nancial 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 ofce. 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 identied, 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) 395417

405

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 implementation-consulting partner. Of four consulting rms 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 rms methodology for selecting a new nancial information system. This methodology for the selection and implementation of integrated packages can be broken into two clear sub-phases: (1) Design, Requirements Denition and Selection; and (2) Implementation. The rst sub-phase involved creating the design of the accounting procedures and processes (to a more detailed level than the rst design phase), building the detailed requirements for the new systems, and selecting a new integrated nancial information systems. At the beginning of this phase (early September 1994), the success criteria for this phase of the project were dened by the project team and approved by senior management. These criteria were as follows: selection of a nancial 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 January 1996. In terms of implementation, some specic 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; sufcient 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 signicantly affected by other initiatives; and the required technology 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 management 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 implementation 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 Request for 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

406

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

Fig. 4. The design, requirements denition and selection process.

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 specic software (the rst sub-phase of Omegas implementation methodology) 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 attended a three-week in-depth training course in Sydney, Australia, while the hardware and software 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 conrmed that the

Fig. 5. The SAP implementation process.

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

407

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 31 January 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 ofce 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 Consulting 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 identied in the Project Sign Off Report as an uncompleted task of the project, and some new report development was also suggested (the identication 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 ofce with regard to the use of the new system, this task was not completed. Other new management reports were identied likewise, but these too were not forthcoming. In April 1996 the Regional Financial Advisers met to discuss their difculties in the post-implementation period. The main area of difculty identied was the lack of reporting 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 difculties. 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 difculties 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 resources were diverted to develop these reports for the new owners. A post implementation review was conducted in early April. This involved interviewing

408

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

key staff and preparing a report for the executive committee overseeing the merger. One of the ndings of this report was that staff morale was low in the head ofce 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 adequately supported by their manager. Further, the lack of skill and expertise in the system they were now using was low, and affected their condence 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 redundancies 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 nancials as their back ofce 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 nancial MIS was to be implemented in their New Zealand subsidiaries also. The devolvement of invoices to line managers was also recentralised 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 professional approach 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 redened and renamed as BPR by this large international consulting rm. It is somewhat debatable as to whether the project can be genuinely classied 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
2 See also Orlikowski (1991), who discusses, amongst other things, the importance which one international software consulting rm placed on the use of its standard information systems development methodology by its clients.

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

409

two consulting rms (both of which are amongst the Big Five) unequivocally described the project as BPR from start to nish. 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 international consulting rms can be classied as business process re-engineering, even if it is not classical BPR. The key idea of this approach is to redesign the business processes before 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 then implemented by 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 nancial information system. 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 information 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 nancial 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 ofce 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 nancial 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 dramatically impaired. It appears that the problems which emerged (such as the lack of management reporting with the new system, the low skill levels of staff) were a logical consequence of the BPR project itself.

410

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

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 reengineered Alpha company was taken over by Beta Ltd., the latter company had an excellent 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 protably. Approximately six months after the project was completed, some of the various stakeholders 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 resounding 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 rms. 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 ofce group accounting team after implementation was a problem and that the users were dissatised. She said that the majority of people appointed to the new positions in head ofce did not have sufcient 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 identied key people within the organisation to trainand we had specic 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. He believed 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) 395417

411

Group Accounting was a problem and said that the project could be seen as unsuccessful in nal 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 the project 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 had caused 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 documentedAfter 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 signicant 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 ofce did not have sufcient 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 the people 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

412

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

disappeared (either through redundancy or people obtaining work elsewhere). When the company announced in 1994 that all accounting positions at Alpha would become disestablished 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 felt insecure 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 factor research 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 implementing the package rather than continuing operation. This case draws attention to the dangers of concentrating too hard on factors leading to successful package implementation 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 difcult to dene. 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 you talk to. From this perspective it is understandable why the various stakeholders voted the way they did: rstly, the consultants judged the project an unqualied success since they

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

413

were the ones that promoted BPR in the rst 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 difcult to denitively 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 ofce, 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 inuenced by an overriding requirement to achieve integration between the two organisations, 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 justication. 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, immediately 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 nancial 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 implementation review found that staff morale in the head ofce accounting team was low. The newly appointed Regional Financial Advisers and the users in Group Accounting were dissatised with the lack of management reporting. Since the RFAs did not have the necessary information to think strategically and proactively as was originally envisaged,

414

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

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 signicant 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 rst completed, can soon turn to failure. The overriding goal to achieve short-term nancial 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 an ERP software package. The BPR project involved redesigning the accounting processes of a nancial services rm in New Zealand. Although the project was deemed to be a success when the system was rst delivered, the project ended up as a failure. While the short term nancial 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 implementation, it was not regarded as such just a few months later. Our ndings 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 practitioners 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, shortterm 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 ofce). We hope that 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) 395417

415

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 the KPMG Auckland ofce and the University of Auckland Business School for some nancial 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 manuscript 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 rst ve 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. Information 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

416

M.A. Larsen, M.D. Myers / Journal of Strategic Information Systems 8 (1999) 395417

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 Technology 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., Smithson, 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 study of 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 eld 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 development. 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 conict and success in information systems development 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) 395417

417

Seddon, P.B., 1997. A respecication 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. Proling 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 Information 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.