The current issue and full text archive of this journal is available at www.emeraldinsight.com/1753-8378.

htm

IJMPB 4,4

Learning from a failed ERP implementation: a case study research

C. Venugopal and K. Suryaprakasa Rao
Anna University, Chennai, India
Abstract
Purpose Enterprise resource planning (ERP) projects failing to meet user expectations is a cause for concern as it often leads to considerable time and money losses. The purpose of this paper is to understand the causal factors for such failures in the Indian context. Design/methodology/approach A scientic case study research methodology was followed. The unit of analysis: a failed ERP project followed by a successful one in the same organization. Data were collected through interviews, observation and study of archival documents. Analysis was methodical and validated through a triangulation approach. Findings The results suggest that it is the manner in which key critical success factors (CSFs) such as top management support are operationalized; good project management; a smaller scope and a hybrid approach of integrating the legacy system with the ERP that facilitates adoption and leads to a succesful implementation. Research limitations/implications The study extends the work of earlier researchers in a new market India. It identies important constructs, composites of existing CSFs, which future research could measure as ex ante predictors of ERP project success. Practical implications The authors offer several guidelines related to the role of top management, the importance of simplicity of scope, change management steps all of which would help implementation teams better manage projects. Originality/value The two case methodology of a failed implementation followed by a successful one in the same organization is unique, in the Indian context. This is the closest to a controlled experiment one can have in case study research. The ndings pave the way for the development of predictive instruments of ERP project outcomes. Keywords India, Enterprise resource planning, Critical success factors, Project management Paper type Research paper

596

International Journal of Managing Projects in Business Vol. 4 No. 4, 2011 pp. 596-615 q Emerald Group Publishing Limited 1753-8378 DOI 10.1108/17538371111164038

Introduction Effective implementation of IT projects, of which enterprise resource planning (ERP) systems is a subset has become important for modern businesses. Although project management methods have evolved over time, the track record of IT project implementations remains poor and project success rates may have actually regressed (Standish Group Chaos report, 2009). Although the reference is to all IT projects, the situation related to ERP implementations is no better. In this paper we ask the question: Why do ERP projects fail? A body of literature attempts to addresses this issue by identifying critical success factors (CSFs) which are dened as those critical areas where things must go right for the project to succeed (Rockhart, 1979). These CSFs are a descriptive list of conditions that lead to implementation success or failure (Bussen and Myers, 1997). But an examination of such literature spanning the last three decades reveals that there are several hundred

CSFs identied; different researchers have dened the same CSF differently; there are internal contradictions on what constitutes a particular CSF (Chua and Lim, 2009). So much so that the large list of CSF has become unwieldy and is even criticised as being just a laundry list (Richmond, 1993 quoted in Akkermans and Helden, 2002). If CSFs have to be useful there is a need to understand them better especially the way in which they operate and inuence outcome. We use a case study research approach to examine this problem. Case study research has been used in information systems research for the last three decades (Markus, 1983; Benbasat et al., 1987; Lee, 1989; Yin, 1993; Keil, 1995; Parr and Shanks, 2000; Chua and Lim, 2009). ERP by its nature is dynamically recongurable and therefore emerges in an organisation through repeated use and interpretation by its users (Orlikowski, 2000). ERP is, therefore, best studied in the context of its implementation and use hence the case study approach. In this paper, we report on two case studies relating to different ERP implementations in ABC Corporation, a midsized, multi location process industry in India with over 2000 employees, over a 100 customers and a supply chain extending across the country as well as overseas. The cases were selected because the rst was, in terms of user acceptance and other measures, a failure and the second a success. The lessons learnt from the rst failed implementation led to a change in implementation strategy for the second which nally led to success. We believe there are lessons to be learnt both from the failure and from the later success both for research and practice. Being from the same organization with no major changes in either the ERP or the management and user teams, a comparative study gives an opportunity to zero in on those causal variables that seem to make a difference. In this paper, we rst review extant literature on CSFs for ERP success and conclude that there is a need to understand the causal mechanisms through which they operate. We then look at theories from the social sciences that have in the past been used to understand the adoption of new technologies to see if they would throw light of the mechanisms through which CSF operate. We then present the cases, listing the chronology of events highlighting the similarities and differences and analyse the effect of the differences on the outcome of the ERP implementation. We conclude the paper with a detailed discussion on the ndings, limitations of the study and suggest guidelines for practice and areas for continuing research. CSFs for ERP project outcomes Researchers have looked at the possible causal factors that could inuence ERP project outcomes. Davenport (1998) identies six factors, mostly relating to the directional or strategic aspects of an ERP project. This includes factors related to top management support, use of a cross functional steering committee, communication, cross functional implementation teams, etc. An often cited and comprehensive list of CSFs is that of Somers and Nelson (2001) who identies a set of 22 CSFs. Their study examined existing literature and this was followed by an empirical study covering 86 medium to large organizations who had implemented ERPs. They used the Cooper and Zmuds (1990) six-stage model of IT implementation to track the importance of different factors across the six stages of: initiation, adoption, adaptation, acceptance, routinization and infusion.

Learning from a failed ERP implementation 597

IJMPB 4,4

598

Hong and Kim (2002) stress on the organization preparedness aspects of the implementation namely organizational t, system adaptation levels, resistance to change, etc. Wixom and Watson (2001), study implementation issues related to data warehousing project success. They categorize the CSFs as belonging to into three groups, viz., organizational, project and technical. A data warehousing project has many similarities with an ERP project it is complex, it has pan-organization linkages, and change management issues are involved. CSF literature is also not without its critics. Robey et al. (2002) criticize the CSF research as being based on variance models (rather than process models) without the rigour of a supporting theoretical base that could throw light on reasons for the outcomes. Chua and Lim (2009) analyse CSF literature and point out to the contradictions and fragmented nature of the studies. The CSFs listed vary across studies, the operational denitions are different, several important causal factors like change management are missing from some lists, etc. The researchers believe because CSF research has:
[. . .] emphasized identifying CSFs linked to project success at the expense of a more thorough exploration of the causal mechanisms connecting organizational actions and processes to project success. In other words, CSF research has focused on what CSFs look like, but overlooked how and why they become critical (p. 2).

Parr and Shanks (2000), studying ERP implementation propose a project phase model (PPM) consisting of three distinct phases: planning, project and enhancement. The PPM model synthesises earlier ERP implementation models: Bancroft et al. (1998), Ross (1998) and nally the Markus and Tanis (2000) model which primarily focuses on pre and post implementation steps bundling the implementation phase into one category. While recognising the importance of the planning phase and post-project phases, PPM focuses on the project phase which they subdivide into set up, reengineering, design, conguration/testing and installation. They then identify the relative importance of different CSFs in the different phases and sub phases. They use a two case methodology of a failed ERP implementation in one organization and a successful one in another to establish their model. They also emphasise: further case studies of ERP systems implementation are required in order to validate and extend the particular CSFs that are important in each PPM phase (p. 302). This then is the motivation for this research. We attempt to understand the CSFs in greater detail beyond mere words and articulation to how they are interpreted by the users whom they impact. We follow the Parr and Shanks (2000) two case methodology with the difference that both the failed and successful implementations are in the same organization. We also focus on the rst two phases of the PPM model, viz., planning and project. Framing of the research question In this case study we address the following questions supplementary to the Meta question Why do ERP projects fail? What are the factors that lead to a troubled ERP project resulting in poor acceptance by users? What changes in these factors would alter the course of the ERP project in gaining greater user acceptance? An area of dissonance and dissatisfaction in ERP projects comes from a gap between expected and actual benets from the implementation. Expectations-Conrmation

theory posits that expectations, coupled with perceived performance, lead to postpurchase satisfaction. If a product outperforms expectations (positive disconrmation) post-purchase satisfaction will result. If a product falls short of expectations (negative disconrmation) the consumer is likely to be dissatised (Oliver, 1977). If during the goal setting and scoping stage, high expectations are raised, the likelihood of the product falling short of expectations is high: If the gap is large, theory tells us that this would lead to negative disconrmation and therefore dissatisfaction. Our rst hypothesis we would test therefore is: H1. High expectations negatively impact ERP success. An ERP project is [. . .] perhaps the worlds largest experiment in business change (Davenport, 1998). Lewins model of change posits that change management in organizations moves through three stages Unfreezing, Change and Refreezing. Internal resistance to the new way of working happens during critical phases of Unfreezing and Change. During this phase top managements visible advocacy of the project, a shared vision of change, role of internal change agents (champions) become important and determines the future acceptance or otherwise of the proposed change. ERP being a change project if the support and direction from top management is weak, then theory tells us that the Unfreezing and Change phases could face problems leading to the ERP not being accepted by users. Top management support is evidenced by: . senior management leading by example; . allocation of resources as needed on time; . repeated communications on the importance of project; . inter-departmental/process conict resolution; and . continual monitoring and redirecting through an effective steering committee process. The users see these as evidence that top management is strongly backing the ERP project. In line with this our next hypothesis is: H2. Top management support would be seen as real only if it is manifest in specic actions and sustained throughout the project. Structuration theory provides us with an overarching view of the interaction of the technology (ERP artefact) with the existing social structure of an organisation. Originally proposed by Giddens (1979) and developed as adaptive structuration theory (Poole and De Sanctis, 1990), these models explore how people (in organisations), interact with a technology in their ongoing practices, (and) enact structures (rules, practices, etc.) which shape their emergent and situated use of that technology [. . .] (Orlikowski, 2000, p. 404). This theory relates to the existing social structures in the company: Structure here is understood as the set of rules and resources instantiated in recurrent social practice (Orlikowski, 2000, p. 406). These would include the roles, reporting relationships, the power and authority of the various role holders in an organization. These are embodied in the legacy systems of the company which encapsulate the existing business processes, organization structure, culture [. . .] (Holland, Light and Gibson, 1999, p. 31).

Learning from a failed ERP implementation 599

IJMPB 4,4

600

An ERP with its revised work ows could alter the existing business processes and therefore would encounter resistance as per Interaction theory: [. . .] resistance generating conditions (are dened) as mismatch between patterns of interaction prescribed by the system and the patterns that already exist (Markus, 1983, p. 438). So structuration theory seen along with interaction theory would suggest that the existing structures embodied in the well entrenched legacy system will offer greater resistance to the work ows dictated by the ERP system. We therefore frame the hypothesis: H3. A strong and well entrenched legacy system negatively inuences the adoption of an ERP system. Methodology This paper follows the scientic methodology suggested for case study research (Pare, 2001; Yin, 1993). The four important issues in a case study research are: (1) framing of the research question; (2) a priori specication of constructs/theory/hypothesis; (3) denition of unit of analysis; and (4) selection of the cases for study (Pare, 2001). We discuss each of these. Dening the unit of analysis The units of analysis chosen for this study are the ERP projects 1 and 2 of ABC Corporation. ERP1 refers to the rst implementation project of Oracle Applications[1] 10.4 in a division of ABC Corporation. ERP2 refers to a fresh implementation of Oracle Applications 11i in the same division. To understand the context of the implementation, a prequel, representing the two years prior to the start of ERP1 is also included. Although this prequel period is outside the boundary of the unit of analysis, during this period a strong legacy system was built and internalised at ABC Corporations division. We have included this as our hypothesis states that this legacy system has an inuence in the success or otherwise of the ERP project to follow. Cases for study need to be: . revelatory (when an investigator has an opportunity to observe and analyse a phenomena previously inaccessible to scientic investigation) (Pare, 2001, p. 13). . unique; or . critical to testing the theory. Furthermore, case study choices should provide opportunities to replicate and generalise the study. The cases chosen by us are revelatory as the researcher was personally involved in ERP1 as a project manager and in ERP2 as an observer. [. . .] participant observation makes the researcher into an active participant in the events being studied.

This provides some unusual opportunities for collecting data but could also be problematic [. . .] as the researcher could well alter the course of events [. . .] Pare (2001, p. 16). This drawback is addressed as the researcher is looking at the events that unfolded years back in retrospect and has the advantage of seeing the events in perspective. Detailed notes of the events made by the researcher also helped in this process. In addition, we had access to a detailed post-completion audit done of ERP1 before the start of ERP2 by a separate team. This provides an excellent third-party perspective of the events prevailing, the problems encountered, and the results achieved with a causal analysis. This proved invaluable in revalidating the impressions recorded in the notes of the researcher. The choice of case studies also satises the condition of criticality-meeting the necessary conditions for testing our hypothesis. The organisation remains the same, top management and management team is largely the same; the ERP under implementation is an enhanced version of the same ERP; the changes are related to the differences in top management support, change management initiatives, expectations management all of which are the hypothesis under test. Hence the choice of cases affords an opportunity to test replicability of ndings. Data collection and analysis methods The data for the case was gathered over a six-month period as follows: (1) Study of personal notes made by the researcher who was a project manager during the implementation of ERP1. (2) Detailed discussions with the erstwhile project manager of the ERP2 project-specically focussing on the differences in ERP1 and ERP2 (the concerned project manager was a team lead in the ERP1 project and therefore could make the comparisons). (3) Face-to-face semi-structured interviews with users representing different user groups: . president and business head; . CFO, materials manager, marketing manager; . sales coordination executive; . production manager and production executive representing manufacturing; and . IT implementation staff. (4) 10 users representing three different user cohorts: strategic users (business head/senior management); operational users (materials, sales, nance staff); and technical (IT staff, database administrators) responded to a structured questionnaire which captured impressions of the respondents on the strength and presence of various factors during the implementation on a seven-point Likert scale with end values: 7 completely agree and 1 completely disagree. It also checked the overall satisfaction level with the ERP on a seven-point Likert scale with similar end values. (5) We studied a post-completion audit report of ERP1 that was prepared by a cross-functional team. This audit report was prepared prior to the start of ERP2. This report was exhaustive and made a very good causal analysis of the issues resulting in a failed implementation.

Learning from a failed ERP implementation 601

IJMPB 4,4

602

The case studies: ERP implementation at ABC corporation The case studies relate to ABC Corporation, a technology driven process industry based in India with over 2,000 employees, over a 100 industrial customers, and a supplier base spread all over the country as well as overseas. Computerized accounting systems were introduced at ABC Corporation in early part of the 1980s. In the early 1990s, a FOXPRO-based accounting system was developed by, a company IT team. Data were captured in a batch mode, from the various departments of the company and updated daily into the standalone accounting system. Modules for stores/inventory, sales, purchase and payroll were added each stand-alone, feeding into the accounting system through batch updating. To overcome the problem disparate databases, the FOXPRO system was replaced with an relational data base management system (RDBMS) using INGRES[2]. The various modules were linked, creating the rst semblance of a future enterprise wide system. In the years 1993-1995, the legacy system grew in functionality and was used for all transaction processing. The internal EDP department maintained the same, often going out of the way to accommodate requests from the users for newer and newer reports and functionality. The demands from the users often exceeded the capacity of the internal EDP department to meet. With the opening of the Indian economy in the early 1990s ABC Corporation had the vision of becoming a world class player in its business domain. The company appointed an international consultant to carry out a gap analysis to study if the existing IT system was ready to meet the information needs of the future. They wanted the consultant to answer the following questions: . What were the weaknesses of the current IT system of the company? . What changes should be made to align the information system to the business vision of ABC to become a world-class company? The consultant team after a detailed study recommended that the company go for an ERP system. A detailed exercise was carried out to select the ERP. The choices were between SAP, JD Edwards, Oracle Applications and Ramco Marshal[3]. Oracle Applications Version 10.4 was chosen as it had a local support ofce, met the required functionality, had another reference site and was competitively priced. The implementation was planned at the largest division of the company. It was felt that that after successfully implementating ERP at one location, roll out to the other locations would be much easier. The chronology of the ERP projects at ABC Corporation is given in Table I. Case 1: roll out of Oracle applications 10.4 at ABC Corporation-(ERP1) The same international consultant was engaged for the implementation. A project team headed by the IT head was constituted for the ERP project. The in house team consisted of three full time IT resources, ve user members (part time as the departments could not spare resources full time). The consultant team consisted of a project manager and ve full time resources (two technical consultants and three functional consultants). A senior manager was appointed as the project champion. The project was initiated with a formal kick off with the CEO and top management team emphasising the importance of the project. The project then followed the standard ERP implementation methodology involving:

1993-1995 (background phase) Events FOXPRO-based accounting system developed by internal team-replaced with INGRESS based integrated (sales/inventory, purchase, accounting) system Legacy system gets well entrenched through repeated use allows maverick practices ERP1 project commenced

1996-1998 (ERP1) ERP implementation continues legacy system still in use in pockets

Learning from a failed ERP implementation 603

Consequences Information needs grows/ delays in nancial closure of books ABC has the vision of becoming world class not sure if the information system is geared up for future needs

Top management not fully No reduction in staff- in aware of the complexity of fact increase in some areas due to increased data entry ERP project load No dedicated user teams Only very limited drill down available due to different systems legacy and ERP Steering committee formed but meets infrequently Top management visible support wanes High expectations from ERP as projected by consultant oversells ERP benets (Table II) At the end of eight months: Additional work load as ERP project delays project both systems work concurrently cost escalates Many system difculties Reconciliation problems encountered continue

Management action/ decisions

International consultant asked to study ABCs IT strategy

Severe resistance to ERP best practices reluctance to change entrenched practices User dissatisfaction manifest Decision to continue with implementation efforts (Note: classic case of project escalation Keil (1995)). Decision to revert back to legacy system for manufacturing

Very low level of user acceptance

Consultant recommends migration to an ERP

Conclusion: ERP project is a failure : decision to take stock and re-look at total project. A third part project audit carried out using TQM problem solving methods Findings: re-implement ERP (newer version 11i) with a new methodology/ new implementation partner (continued )

Table I. ABC Corporation ERP Project chronology

IJMPB 4,4
Events

1993-1995 (background phase) 2000 ERP2 Migration to Oracle 11i ERP2 project charter: simple goal of reimplementing Oracle 11i President takes ERP as personal KRA. Steering committee meets at least once a month Multi functional team withdedicated team- project led by CFO. core users identied; project champion designated Training just in time; very limited customisation Consequences Visible signs of change in attitudes Greater acceptance levels

1996-1998 (ERP1) 2001 and beyond Oracle 11i takes root ERP Oracle 11i extended to other divisions of the company Very limited expectations The team that implemented the ERP system seen as from ERP (due to earlier experts and extend services bad experience) to other implementations in the company Users start to see value in an integrated system Owing to user teams having being full time much greater understanding of ERP screen navigation/work around, etc. Complete shift from legacy system; much greater acceptance by users MIS quality improves Users acceptance of the new ways of working almost complete Visible benets of ERPreduction in staff (15-20 percent of transaction processing staff reduced) Quicker turn round of inventory due to faster order to delivery cycles

604

Oracle goes live in six months Management action/ decisions

Greater usage of systems for decision making Conclusion: ERP2 Project is a success: management plans for the next level of systems extension to the extended supply chain. Also decides to roll out the ERP to all divisions of the company

Table I.

denition (requirement analysis, scoping, creating work plan); operational analysis (Gap analysis, As is and To be process design); solutioning (detailed design, work-around plans); building (parameterizing, coding, data migration, testing); transitioning; and go live.

. . . .

A steering committee consisting of the IT head as chair and departmental heads as members was constituted. This committee was mandated to meet once a month to review the project. Being themselves new to ERP and perhaps as a means of securing the contract the consultant had raised the expectations of management on what the ERP would do for the business. The scope of the project, therefore, was ambitious (Table II). From the start ERP1 had problems. Top management showed great interest at the start of the project but soon this interest started to wane with competing pressures on everybodys time. After the kick off meeting there was no formal review of the project. The steering committee met for the rst two months from the third meeting onwards the attendance for the meetings started dwindling and altogether stopped after the fourth meeting. User team members, not being full time, got busy with their day-to-day work and saw the ERP project as an additional burden. In key areas, the participation of user members was poor-the most dispensable junior was often the choice for serving on the ERP team. This person neither had the knowledge nor the authority to make process change decisions that were required in conguring the ERP. There was a lot of resistance from users who constantly compared the ERP with the existing system. A comment often heard was:
why are we spending so much for this (say an accounts payable report) our old system already gives it at the click of a button- in the ERP we need to go through three screens to get the report and that too without all the details [. . .]
Goal scope Cost Time Functionality ERP1 US $ X Nine months from start Seamless integration of Marketing, sales, manufacturing, procurement, inventory and nancial
a

Learning from a failed ERP implementation 605

ERP2

US $ Y Six months To move from Oracle 10.4 to Oracle 11i Compliance with ABCs accounting policy Creation of transactions and reports in line with statutory requirements Accuracy 100 percent accuracy and timeliness of Nothing specied business MIS Nothing specied Drill down capability Drill down capabilities up to transaction level what if analysis capabilities Information quality Real-time information on inventories, Meeting basic functional product availability, pending orders, requirements sales, costs, etc. Simple screen navigation as close to Ease of use Simple screen navigation; quick that of current legacy system as screen refresh (, 3 secs.); userpossible friendly reports. All approvals of Enable workow as per revised vouchers, purchase orders onlinework ow to be created to match the business processes delegation of authority within the company Manpower reduction As a result of ERP reduction in staff No manpower reduction goal of at least 15 percent Note: aAmount disguised to ensure condentiality of commercially sensitive information

Table II. Differences in project goals ERP1 and ERP2

IJMPB 4,4

606

Problems also started with localization this refers to the ability of the ERP to handle the country/region specic requirements of taxes/ levies, etc. The legacy system handled all of this perfectly but ERP always seemed a step behind in addressing these. This necessitated work rounds which were cumbersome. Another source of resistance to the ERP came from: . prevention of maverick behaviour; and . perceived loss of power. These are explained below: . Maverick behaviour. In many operational areas, there were informal (not ofcially authorised) practices. For example: in purchasing, very often suppliers were asked to send material without formal purchase orders. These were then regularised post-facto at the time of bill passing; similarly the sales department had a practice of extending despatches beyond the close of a period (say quarter or month) with predated invoices to meet month end targets. These practices were tacitly allowed by the departmental managers but were frowned upon by top management. As the ERP would not allow such practices, users who had been doing this for years resisted the change terming the ERP as not being user-friendly. . Perceived loss of power. ERP best practices brought about some work ow changes that resulted in power shift between departments. For example, in the legacy system bill passing was done by the accounts department. As a best practice it was decided that the complete accounts payable process from Indent to Payment would have the procurement department as the process owner. As the ERP provided a robust three way match (between invoice, goods receipt and purchase order) and also provided good audit trails, it was felt that the bill-passing function could completely move to the procurement department by passing the accounts department. This change was resisted by the accounts department team. They felt that they had lost the power they had earlier exercised over vendors and the procurement team by controlling the payment process. The procurement department happily accepted the changed workow as they saw the power (to control payment to vendors) shift to them. This caused conict between departments that manifested in other areas also. At the end-nine months the ERP project was nowhere near completion. Costs had already exceeded the original budget of $X Million as hardware had to be upgraded, additional licences had to be procured to take care of the revised workows, users had asked for several additional non-standard reports/customisations (to match legacy system functionalities) that required additional 12 man months of work. New estimates of cost were twice the original estimate which top management had no choice but to approve. The go live happened after 14 months of start. During the rst two weeks there was total chaos. The legacy system had been switched off and the ERP processes still had glitches. Despatches were getting delayed as inventory data were inaccurate. Manufacturing systems were completely unusable. Improperly trained users could not handle the screens on their own. IT persons and consultants staff was running from

one user to the other to trouble shoot/train/help. Customers started complaining of wrong /delayed deliveries. With no other alternative it was decided to switch back the legacy at least for key show stopper processes and continue working on the ERP. The consultant was asked to extend their contract by another six months. After 24 months the conclusion was that the ERP project was a failure. The consultant had left the project. ERP was running but in many of the business processes the legacy system was still continuing in parallel. There was total dissatisfaction at all levels in the company. Commenting on the state of affairs, a senior manager from accounts put it best. To quote him:
We had a good reasonably good legacy system [. . .] we were told that the ERP would solve all problems and take us take to the next level [. . .] now after more than a year and a half we nd the ERP is way below our legacy system, and we are putting efforts to bring it up to our legacy level If only we had spent half the amount of time and money and upgraded the legacy system we would have been much better [. . .]

Learning from a failed ERP implementation 607

The conclusion: ABC should consider abandoning the ERP project and focus on improving the legacy system to bridge gaps. This feeling was shared by quite a few other managers. The company continued with this hybrid solution for another year or so before deciding to take a complete relook at the whole ERP implementation. By now Oracle had come out with an upgraded version 11i and this was a good opportunity to do a reimplementation. Case 2: reimplementation of Oracle Applications 11i at ABC Corporation (ERP2) ABC Corporation approached ERP2 very differently from the way they carried out ERP1. A post-completion audit was conducted to analyse the causes of ERP1 failure. A causal analysis identied the key causal factors that led to the problem: lack of visible management advocacy, inadequate process monitoring and control and resistance to change from the current way of working came out as the key reasons. In addition it was felt that the goals of the ERP were unrealistic and that the implementation consultants had unnecessarily raised expectations among the users. Following this analysis the management took up ERP2 with the following differences in approach: (1) The project goal was simple and realistic (Table II). The key goal was moving from Oracle 10.4 to Oracle 11i smoothly. (2) Top management decided to demonstrate commitment through visible actions: . The President took the ERP implementation as his personal key result area (KRA). . The CFO was made as the ERP project manager with the IT department playing a supportive role. . The steering committee, with the CFO as the chair met every month without fail. During the initial and nal phases the meeting frequency was increased to once a fortnight. (3) A full-time user team, relieved of all other duties, was created (unlike in ERP1 where the user team worked on the project part-time). A set of core users per module were identied and given intensive training. Other users were trained just in time just before they were expected to use a module. (Note: In ERP1, training

IJMPB 4,4

608

was given well ahead of use. When the module was ready (about four to six months down the line) to be used most users had forgotten all that they had learnt). (4) A systematic BPR exercise, led by an expert consultant involving all, preceded the new implementation. Special care was taken to address the change management issues. In each department opinion leaders were identied and tasked with championing the revised work methods and ows. The issues of power loss that were felt earlier in ERP1 were much less as new work ows had been in place for a year and users had got used to the new power structures. Moreover, through change management interventions, these issues were tackled as and when they arose. (5) Wherever possible, attempts were made to integrate legacy data entry screens into the ERP using application program interfaces (APIs). This gave the users the comfort of familiar legacy interfaces while at the same time not diluting the integrity of the ERP. Results. Within six months the ERP2 went on stream. The go live was relatively smooth and trouble free. As the users were trained just in time, they were fresh and very little hand holding was needed. The core users team became very valuable resources and were able to solve most of the operational issues. The quality of the MIS improved Drill down up to transaction levels was possible in most functional areas facilitating greater management control. As the expectations were quite low to begin with, the results exceeded expectations. The ERP stabilised soon and within the next 12 months the same was well entrenched in the company. ERP2 was a success. Following this success the company decided to roll out the ERP to other divisions of the company. Discussion, analysis and results The cases were chosen primarily to illustrate how a change in operationalizing certain CSFs brought about a change in the outcome of the ERP project from failure to success. As the organization remains the same, the ERP is the same and the user group largely remains the same, it is the different operationalization of the CSFs that has made the difference. We now discuss the similarities and differences in the two cases and draw inferences for research and practice. Case study ndings similarities Both projects followed the same standard methodology used by implementation consultants. The ERP package, Oracle Applications, in both cases is the same the only difference being the versions 10.4 in the rst case and 11i in the second case. Both cases followed the standard ERP implementation methodology which involves: . denition (scoping, creating work plan); . operational analysis (gap analysis, As is and To be process design); . solutioning (detailed design, work-around plans); . build (parameterizing, coding, data migration, testing); . transitioning and go live.

There is no signicant change in top management, users, technical team between the two projects. Top management in the two cases remains largely the same. The user community also is largely the same. The technical team for the implementation from the companys side was the same. The implementation partner was different but both being internationally known rms with established systems, templates and practices we do not see this as a major differentiating factor. Top management support, project champion, a priori BPR (considered as important CSFs) were present in both the projects (at least on paper at the surface level). Top management support was understood to be important in both cases. Both projects started out with a letter from the CEO on the importance of the project. Steering committees were constituted in both cases. A project champion was appointed; user teams were constituted and trained. A BPR exercise was carried out and revised work ows mapped. It must be noted that at the surface level all the key CSFs appear to have been complied with. We show in the next section that it is the differences in the manner in which these are operationalized that seemed to have made the difference in the outcome. Case study ndings differences ERP2 had a much smaller scope and realistic goal when compared to ERP1. A key difference is in the scope of the project. While ERP1 had very ambitious goals ERP2 had a much smaller scope, the key goal being the smooth transition from version 10.4-11i (Table II for the differences in scope between the two projects). This goal was understood by all and accepted as the only benet to be expected from the ERP. Top management support was visible, overt and continued throughout the course of the project. Although in both cases top management support was available, there was also a critical difference. In ERP1 after the initial letter from CEO and the kickoff meeting top managements attention appeared to have waned. In ERP2 however, the president himself took ERP implementation as his personal KRA. At every occasion, the senior management would reemphasise the importance of ERP. In business review meetings, the status of ERP implementation was the rst agenda point. Resources in terms of personnel (releasing best people from each functional area as full-time team members), additional computer hardware (new terminals, additional RAM memory, etc.), additional training, and visits to other successful sites were sanctioned by top management. Unlike in ERP1 where the IT head was the ERP project manager, in ERP2 a senior line manager (the CFO) was made the ERP project head. This person was very senior in the company, had the authority to sanction business process changes and had a personal stake in a successful implementation as his functional area would be the biggest user of the ERP system. Importance of the change management and BPR activities. In ERP2 great care was taken to ensure that the reengineering efforts had the buy in of large sections of the users. This was done through several rounds of discussions involving all levels of employees, addressing genuine concerns, allaying fears of loss of power, and above all constant reinforcing communication. The opinion leaders played a crucial role throughout the process. A process-based structure (as against a function based structure) with appropriate changes in goals (process goals against department goals), appropriate changes in compensation structures (rewards on achievement of group goals), etc. were incorporated.

Learning from a failed ERP implementation 609

IJMPB 4,4

610

The ERP with the revised work ows was rolled out only after a reasonable comfort level on the new ways of working was achieved. In several instances, legacy screens were integrated into the ERP to give the users the comfort of familiar screens. Project monitoring and control. In ERP2 the steering actively monitored the project without let up till the completion of two months after go live. As the CFO was the project head (and also the steering committee chair) he was able to ensure full participation of all the other steering committee members unlike in ERP1 where the steering committee chair was the IT head who was not as senior in the organization as the CFO. A fully functioning steering committee was able to take crucial decisions on funds allocation, changing work ows as needed and could limit the extent of customisations in ERP2 unlike in ERP1 where there was very little control on customizations. A disincentive for customization was introduced by creating a notional debit (to a departments budget) based on customization man days. Creative use of legacy system. In ERP1 on go live the legacy system was switched off. This created havoc and affected despatches to customers forcing the company to run the legacy in parallel. In ERP2 a different strategy was adopted. A hybrid strategy of introducing the ERP while retaining some crucial legacy screens was adopted. The APIs available in the ERP were used to ensure that legacy system data were sent to the appropriate ERP tables. As users got familiar with the ERP slowly these legacy systems were phased out. The resistance from users was thus creatively addressed. Testing the hypothesis against the facts of the case We had hypothesised: H1. High expectations negatively impact ERP success. Analysis of the cases shows that there were clearly different expectations from ERP1 and ERP2 among the users. In the rst implementation, being new to ERP practice, the consultant inadvertently raised expectations to a very high degree. For example, detailed drill down capability, reduction in manpower of 20 percent, 3 second screen response, best practices introduction were promised (Table II). The actual results for ERP fell far short. Result. A large gap between expectations and actual delivery leading to expectations-disconrmation and thereby dissatisfaction. In contrast in ERP2 everybody including the consultant was wiser. Coming after a disastrous implementation, the organisation went into ERP2 project with little or no expectations. The ERP2 scope was simple- the key goal being migration to the latest version Oracle 11i. Furthermore, the users had zero expectations from ERP due to their bad experiences in the past. As one user succinctly put it:
[. . .] anyway the new ERP cant be worse than the earlier one, nothing can be worse [. . .] as long as it makes my work a little easier I am satised.

It is to be claried that zero expectations did not mean that users had no functional or non-functional requirements. What is being said is that unlike in ERP1,this time round, users were under no illusion that the ERP would be a panacea for all ills. There was a great deal of realism of what to expect and what not to expect. In fact, users approached the ERP project with a mindset that nothing really would be different after ERP.

When nally the ERP was delivered, users were pleasantly surprised to see that the ERP had indeed made work easier. Result. ERP2 was perceived as a successful implementation by most users compared to the failed implementation of ERP1. We conducted a small empirical study, using a Likert scale with anchor values of 7 completely agree and 1 completely disagree among a sample of ten users drawn from diverse areas: strategic users, operational users and technical users. The results show a marked improvement (Table III) in satisfaction levels with ERP2 compared to ERP1 conrming our hypothesis that high expectations negatively impact user satisfaction and conversely low expectations positively impacts user satisfaction. The next hypothesis: H2. Top management support would be seen as real only if it is manifest in specic actions and sustained throughout the project. We next analyse the differences in the nature of top management support in the two projects. The key difference between the two implementations with reference to top management support is in actual actions of management. Although both the projects appear to have the support of top management in ERP1 the support was in form only while in ERP such support was actually manifest in afrmative actions (see discussions on the differences between implementations). This fact is sensed by the users and the nature of resistance to the ERP therefore varies in the two projects. The empirical study

Learning from a failed ERP implementation 611

User cohort (Nos.)

ERP1

ERP2

Remarks

Overall i am satised with the ERP that has been implemented in our organisation Strategic users (2) 4, 4a 6, 5 Marked shift in satisfaction levels especially Operational users (4) 3, 2, 3, 3 5, 6, 6, 5 among operational users Technical users (4) 2, 1, 2, 2 6, 7, 6, 6 The top management was actively involved and supported the ERP project from start to nish Strategic users (2) 5, 5 6, 6 Major change in perception about top management Operational users (4) 2, 1, 1, 1 7, 6, 6, 7 in ERP2 Technical users (4) 2, 2, 2, 2 6, 7, 7, 7 A steering committee was formed which met at least once a month, monitored progress and initiated corrective in the case of any Strategic users (2) 3, 2 6, 6 Steering committee was seen to be functioning very Operational users (4) 1, 1, 1, 1 7, 7, 7, 7 well in ERP2 Technical users (4) 2, 2, 2, 2 6, 7, 6, 7 There was a project champion who led the project throughout by providing guidance building concessus solving issues Strategic users (2) 5, 5 6, 6 Project champion was appointed but not empowered Operational users (4) 2, 1, 1, 1 7, 6, 6, 7 in ERP1 Technical users (4) 2, 2, 2, 2 6, 7, 7, 7 The ERP helps me do my job better when compared to the old (legacy) system Strategic users (2) 2, 3 6, 6 Legacy system inuence reduced by the time of Operational users (4) 1, 1, 1, 1 6, 6, 6, 7 ERP2 Technical users (4) 3, 232, 2 6, 5, 4, 6 Note: aresponses measured on a Likert Scale: completely agree 7 to completely disagree 1

Table III. Results of empirical study ten respondents (diverse stakeholder group)

IJMPB 4,4

also shows that the users perceptions of top management involvement in ERP2 is substantially higher (Table III). Conclusion. Top management support is perceived to be real only if accompanied by actions. Some typical actions that seem to make the difference are: the president declaring the ERP project as his personal KRA, visible use of systems by top management, ensuring that the steering committee functions, allocation of full time resources, empowering the project champion, etc. The evidence of the cases supports the hypothesis. The next hypothesis: H3. A strong and well-entrenched legacy system negatively inuences the adoption of an ERP system. The company had a well-entrenched legacy system. The legacy system incorporated the current practices in the company and conversely the legacy system practices became the company preferred practices the ERP best practices therefore encountered resistance. The legacy system allowed some amount of bending of system for example the predating of invoices which the ERP did not allow. By the time ERP2 was in place, the legacy system inuence was reduced as in many areas ERP1 practices had taken root (Table III). Moreover, the change management exercise addressed many of the issues of power balancing and revised roles and responsibilities. Conclusion. The facts of the case support the hypothesis that a well-entrenched legacy system negatively inuences ERP adoption only when legacy system inuences are reduced do the ERP best practices gain acceptance. Implications for practice In the practice area, management is advised to take a lot of care in the scoping and goal setting process of an ERP implementation. Simple achievable goals facilitate the process of acceptance. The overall feel-good factor that follows from the achievement of expected goals will allow the management to push its larger agenda for more fundamental process changes. It is better to undersell ERP than oversell it. It gets accepted better. Top management has the pivotal role in ERP success. This role is both symbolic as well as substantive. Symbolically top management should be seen to own the projectas in the case of ERP2 where the president of the company takes ERP implementation as his personal KRA. Substantively, top management has to ensure that the best resources are made available to the project this means dedicated user teams for the duration of the project, quality time for reviews, funds as needed for the up gradation of computer infrastructure, etc. The role of good project management cannot be reemphasised. A senior line manager as the ERP project head is most desirable. A functioning steering committee that steers the project throughout its course is vital for success. The steering committee has the key role in addressing issues that are bound to come up quickly and decisively. An important decision is how much customization to allow. At ABC Corporation, a disincentive for customization was a notional cost debit (based on estimated man days) to a department for every customization request. This worked in curbing customizations.

612

Implications for research Our study extends the work of Parr and Shanks (2000). It follows a similar two case methodology of an unsuccessful implementation followed by a successful one in a new and important ERP market India. It establishes the value of scientic case studies in drawing important lessons for research and practice. It differs from the work of Parr and Shanks in that the two implementations are in the same organization separated in time. Thus, it is closer to a controlled experiment when compared to the earlier work. Further it explores the effect of one of the key CSFs at the planning stage, the scoping process. This was not covered in depth in the earlier research which primarily focussed on the implementation stage. Our research has identied some key constructs that seem to impact ERP implementation outcomes. For example, we have shown that top management support is actually a composite of several other CSFs like full-time user teams allocation, personal example, empowering a champion, etc. All these together constitute a latent construct which could be called Leadership the dimensions of which exceed what is generally understood as top management support. Similarly all the other issues of managing the implementation process like scope management, change management, etc. would map to another latent construct process. These constructs represent better ways of classifying the CSFs and future research could develop measurement scales for these which could be used as predictive ex ante indicators for ERP outcomes. Our research had some limitations. The events of the case happened at a time when ERP and computerisation were in its infancy in India. Perhaps with time and greater familiarity some of the issues that impacted the project may not be as relevant today as it was then. But, even today ERP projects suffer and the lessons learnt from an analysis of the past failures may, we believe have important lessons for our present times.
Notes 1. Oracle Applications was called Oracle Financials during early 1990s. 2. INGRES was one of the earliest RDBMS systems available in the early nineties from Ingres Corporation. 3. An Indian ERP that was gaining in popularity.

Learning from a failed ERP implementation 613

References Akkermans, H. and Helden, K. (2002), Vicious and virtuous cycles in ERP implementation: a case study of interrelations between critical success factors, European Journal of Information Systems, Vol. 11 No. 1, pp. 35-46. Bancroft, N., Seip, H. and Sprengel, A. (1998), Implementing SAP R/3, 2nd ed., Manning Publications, Greenwich. Benbasat, I., Goldstein, D.K. and Mead, M. (1987), The case research strategy in studies of information systems, MIS Quarterly, Vol. 11 No. 3, pp. 369-85. Bussen, W. and Myers, M.D. (1997), Executive information system failure: a New Zealand case study, Journal of Information Technology, Vol. 12 No. 2, pp. 145-53.

IJMPB 4,4

614

Chua, C. and Lim, W. (2009), The roles of is project critical success factors: a revelatory case, ICIS 2009 Proceedings, Vol. 196, Paper 196, available at: http://aisel.aisnet.org/ icis2009/196 Cooper, R.B. and Zmud, R.W. (1990), Implementation technology implementation research: a technological diffusion approach, Management Science, Vol. 36 No. 2, pp. 123-39. Davenport, T.H. (1998), Putting the enterprise into the enterprise system, Harvard Business Review, Vol. 76 No. 4, pp. 121-31. Giddens, A. (1979), Central problems in social theory: action, structure, and contradiction in social analysis, University of California Press, Berkeley, CA. Holland, P., Light, B. and Gibson, N. (1999), Critical success factors model for enterprise resource planning implementation, Proceedings of the 7th European Conference on Information Systems, Vol. 1, pp. 273-97. Hong, K.K. and Kim, Y.G. (2002), The critical success factors for ERP implementations: an organizational t perspective, Information & Management, Vol. 40 No. 1, pp. 25-40. Keil, M. (1995), Pulling the plug: software project management and the problem of project escalation, MIS Quarterly, Vol. 19, pp. 421-47. Lee, A.S. (1989), A scientic methodology for MIS case studies, MIS Quarterly, Vol. 13 No. 1, pp. 33-52. Markus, M.L. (1983), Power, politics, and MIS implementation, Communications of the ACM, Vol. 26 No. 6, pp. 430-44. Markus, M.L. and Tanis, C. (2000), The Enterprise System Experience from Adoption to Success. Framing the Domains of IT Management: Projecting the Future through the Past, Chapter 10, Pinnaex Educational Resources Inc., Cincinnati, OH, pp. 173-207. Oliver, R.L. (1977), Effect of expectation and disconrmation on post exposure product evaluations-an alternative interpretation, Journal of Applied Psychology, Vol. 62 No. 4, pp. 480-6. Orlikowski, W.J. (2000), Using technology and constituting structures: a practice lens for studying technology in organisations, Organization Science, Vol. 11 No. 4, pp. 404-28. , G. (2001), Using a Positivist Case Study Methodology to Build and Test Theories in Pare Information Systems: Illustrations from Four Exemplary Studies, School of Business Studies, Montreal. Parr, A. and Shanks, G.A. (2000), Model of ERP project implementation, Journal of Information Technology, Vol. 15 No. 4, pp. 289-303. Poole, M.S. and De Sanctis, G. (1990), Understanding the use of group decision support systems: the theory of adaptive structuration, in Fulk, J. and Steineld, C.W. (Eds), Organizations and Communication Technology, Sage, Newbury Park, CA, pp. 173-93. Robey, D., Ross, J. and Boudreau, M. (2002), Learning to implement enterprise systems: an exploratory study of the dialectics of change, Journal of Management Information Systems, Vol. 19 No. 1, pp. 17-46. Rockhart, J.F. (1979), Critical success factors, Harvard Business Review, March/April, pp. 81-91. Ross, J.W. (1998), The ERP Revolution: Surviving Versus Thriving, Centre for Information Systems Research, Sloan School of Management, Cambridge, CA. Somers, T.M. and Nelson, K. (2001), The impact of critical success factors across the stages of enterprise resource planning implementations, Proceedings of the 34th Annual Hawaii International Conference on System Sciences, Washington, DC, USA. Standish Group Chaos report (2009), available at: www.standishgroup.com

Wixom, B.H. and Watson, H.J. (2001), An empirical investigation of the factors affecting data warehousing success, MIS Quarterly, Vol. 25 No. 1, pp. 16-41. Yin, R.K. (1993), Applications of Case Study Research, Sage, Beverly Hills, CA. About the authors C. Venugopal is currently pursuing a doctoral program in the Faculty of Management Studies, Anna University, Chennai. He is a B.Tech (Hons.) graduate in Engineering from IIT, Kharagpur with a post graduate degree in Management from JBIMS, Bombay University. He has over 30 years of industry experience spread over a wide variety of business functions including as a general manager systems, in which capacity he led one of the earliest ERP implementations in India. Since then he has been a regular speaker and trainer in the areas of enterprise systems implementation and is currently a business consultant advising organizations on strategic aspects relating to among others, information technology and change management. C. Venugopal is the corresponding author and can be contacted at: [email protected] K. Suryaprakasa Rao has a PhD in Industrial Engineering from The Indian Institute of Sciences, Bangalore and is a Senior Professor in the Department of Industrial Engineering, Anna University, Chennai. He had done post doctoral work at GSM-UCI, USA and is a faculty fellow at SUNY Binghamton, USA. He has over 17 years of teaching and academic experience after having served for over 16 years in industry. His areas of specialization include operations research, discrete event simulation, systems engineering and supply chain networks. He has a wide list of publications in leading international journals. He is also the recipient of The President of India Award during the Indian Engineering Congress 1999.

Learning from a failed ERP implementation 615

To purchase reprints of this article please e-mail: [email protected] Or visit our web site for further details: www.emeraldinsight.com/reprints

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.