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

htm

BPMJ 14,2

204

Exploring the impact of top management support of enterprise systems implementations outcomes
Two cases
Linying Dong
School of ITM, Ryerson University, Toronto, Canada
Abstract
Purpose Despite the general consensus regarding the critical role of top management in the information systems (IS) implementation process, the literature reveals a lack of understanding of top managers supportive actions. There are also conicting ndings, which, based on the review, are the result of unexamined perspectives (deterministic, contingent, and dynamic perspective) of the impact of top management support (TMS). The purpose of the study is to compare the applicability of the three perspectives to enrich the understanding of TMS under the context of enterprise systems (ES) implementation. Design/methodology/approach Case studies were conducted in two Canadian universities which have implemented a large-scale ES to examine the applicability of the three perspectives. About 19 interviews were conducted with top managers, department managers, project managers, users and trainer. Findings Results reveal that the deterministic and contingent perspective may be a simplied version of a complex picture and may not reect how top management actions affect implementation outcomes. The case study indicates that top managers followed the dynamics of the IS implementation process. Practical implications The case studies offer several important ndings to practitioners. For example, top managers need to constantly obtain feedback from users and adjust their supportive actions and the level of these supportive actions accordingly. Originality/value Despite the consensus on the importance of TMS, TMS studies hold different perspectives of the impact of top managers supportive actions on IS implementation outcomes. By comparing the three perspectives, the study makes important contributions to both academic researchers and practitioners. Keywords Information systems, Canada, Senior management Paper type Case study

Business Process Management Journal Vol. 14 No. 2, 2008 pp. 204-218 q Emerald Group Publishing Limited 1463-7154 DOI 10.1108/14637150810864934

Introduction Information systems (IS) implementation is a process where managers diffuse an IS into a user community (Kwon and Zmud, 1987). Top management support (TMS) is believed to be essential for IS implementation success (Delone, 1988; Doll, 1985; Dong, 2001; Lucas et al., 1990; Wixom and Watson, 2001; Zmud, 1984). A plethora of studies have examined the impact of TMS on IS implementation outcomes. It has been found that TMS signicantly affects user technology beliefs (e.g. perceived ease of use, perceived usefulness) (Lewis et al., 2003), organizational implementation success (Wixom and Watson, 2001), progressive use of IT ( Jarvenpaa and Ives, 1991), and organizational IT adoption (Bruque-Camara et al., 2004).

These studies, however, differ in their perspectives pertaining to the effect of TMS, and as a result, conicting ndings have been generated. For example, some studies assume a direct and linear relationship between TMS and implementation outcomes (Guimaraes and Igbaria, 1997; Igbaria et al., 1997; Wixom and Watson, 2001), some argue that the relationship is mediated by other factors (Sharma and Yetton, 2003), and some other assume that a more complicate relationship exists (Keil, 1995a; Newman and Sabherwal, 1996; Sauer, 1993b, a). Although a few studies have conrmed the importance of TMS (Guimaraes and Igbaria, 1997; Igbaria et al., 1997), it has been found that top management continued support cannot save a doomed project (Keil, 1995b) and too much TMS may actually incapacitate project managers and users (Mahring, 2002). Without understanding the applicability of these perspectives, the impact of TMS on IS implementation outcomes remains unknown. To shed light on the impact of TMS, the study is to compare these three perspectives pertaining to the impact of TMS on IS implementation outcomes. To achieve the goal, we conduct case studies on two large-scale enterprise system (ES) implementations a context in which top management interventions are most critical (Sharma and Yetton, 2003). This paper is structured as follows. First, we rst delineate the three perspectives on the impact of TMS. Second, we describe the case contexts and top management behaviors during each system implementation, and analyze these perspectives based on case study results. Lastly, we discuss the ndings and conclude the paper with suggestions for future research. Perspectives on the impact of top management support Top management includes CEO and its direct subordinates responsible for corporate policy (Green, 1995, p. 223). Under an IS implementation context, top management is a collection of senior managers appointed to oversee the progress of the implementation (Lucas et al., 1990; Ramamurthy and Premkumar, 1995; Sanders and Courtney, 1985; Thong et al., 1996). Deterministic perspective The deterministic perspective assumes that the presence of TMS leads to positive implementation outcomes including system implementation success, increased user acceptance, and enhanced organization performance (Guimaraes and Igbaria, 1997; Igbaria et al., 1997; Thong et al., 1996; Wixom and Watson, 2001). As a result, TMS is treated as a direct predictor of implementation success, and the relationship is often described and tested in linear models. Two important supportive actions of top managers have been mentioned. First, top managers are essential for securing the required nancial and personnel resources (Guimaraes and Igbaria, 1997; Thong et al., 1996). Insufcient resources can quickly result in user indifference or implementation abandonment (Ewusi-Mensah and Trzasnyski, 1991; Guimaraes and Igbaria, 1997), and a system implementation without the support of necessary resources often leads to system abandonment (Ewusi-Mensah and Trzasnyski, 1991). Second, top managers are critical to the promotion of changes. Lack of change management may result in a failure to commit to new values (Hall et al., 1993; Hammer and Champy, 1993), an inability of entrenched management systems to cultivate and disseminate the new values (Fox and Amichai-Hamburger, 2001;

Exploring the impact of TMS

205

BPMJ 14,2

206

Hammer and Champy, 1993), or a failure to anticipate organizational resistance to change (Champy, 1995; Davis, 1993). The deterministic perspective is straightforward and intuitive, and, not surprisingly, it is widely adopted by IS researchers, and has received empirical support (Bruque-Camara et al., 2004; Sultan and Chan, 2000; Delone, 1988; Guimaraes and Igbaria, 1997; Wixom and Watson, 2001; Jarvenpaa and Ives, 1991; Ramamurthy and Premkumar, 1995; Bardi et al., 1994; Leonard-Barton and Deschamps, 1988; Teo and Pian, 2003; Thong et al., 1996). Contingent perspective The contingent perspective proposes that the effect of TMS is contingent upon task interdependence (the degree of interdependence among multiple employees in exchanging information and materials that are essential to perform organizational tasks) (Sharma and Yetton, 2003, p. 537). As argued by Sharma and Yetton (2003), implementation of an IS with high-task interdependence requires signicant changes to the existing institutional context (Sharma and Yetton, 2003, p. 538). Therefore, management support is necessary to institute, support, and legitimize the required new institutional contexts (Sharma and Yetton, 2003, p. 538). Based on a meta-analysis of 22 studies, Sharma and Yetton discover that the effect of management support is weak when task interdependence is low, but strong when task interdependence is high. The contingent perspective helps enlighten some mixed ndings uncovered by the deterministic perspective. For example, in their study on EDI diffusion, Ramamurthy and Premkumar (1995) nd that TMS signicantly and positively affects external EDI diffusion (degree to which the rm has integrated its partners and its transactions with them through EDI), but does not affect the internal EDI diffusion (degree to which an innovation interoperates and is integrated with other key internal IS applications). According to the contingent perspective, since EDI requires high-transaction integration (i.e. task interdependence) mainly externally (with partners), not internally (with internal IS applications), TMS becomes more inuential externally than internally. As a result, it seems that the contingent perspective goes one step beyond the deterministic perspective, and helps unveil the complexity of the effect of TMS. Like the deterministic perspective, the relationship between TMS and success, though mediated by task interdependence, is still assumed to be linear and positive. Dynamic perspective The dynamic perspective of TMS focuses on the changing level of support in the course of an IS implementation. For example, top managers may continue providing resources if necessary, but should reduce the amount of resources and seek other measures if the project becomes disarrayed. The dynamic perspective is implied in studies on escalation (the tendency for decision makers to persist with failing courses of action) (Brockner, 1992, p. 39). These studies uncover that top managers can contribute to project failures by continuing to provide resources to doomed projects (Keil, 1995b), but can also make a troubled project successful by adjusting resource provision and changing project leadership (Keil and Robey, 1999). The dynamic perspective highlights several important notions. First, the linear and positive relationship between TMS and implementation success does not necessarily exist (Sauer, 1993b, a); rather, too much support may negatively affect implementation

outcomes (Mahring, 2002). Second, top managers can learn over time, and based on their learning experience, change their attitudes, and content and level of support accordingly (Akkermans and van Helden, 2002). Therefore, the effect of TMS may vary depending on how well top managers adjust the content and level of their supportive actions during an IS implementation process. In summary, the review indicates that researchers hold implicit and divided perspectives when they examine TMS. Each of these perspectives has some empirical evidence to support; however, without comparing the three perspectives in one single study, it remains unknown whether these perspectives are valid. Examining these perspectives is important as questionable conclusions could be drawn if underlying assumptions do not hold, and the intellectual development on TMS could be seriously affected as a result. Consequently, we undertook two case studies to explore the applicability of the three perspectives. Two cases Methodology A comparative case study was conducted to examine the proposed model. The case study methodology has been deemed as an effective way to probe insider perspectives and capture rich information on the subject studied (Benbasat et al., 1987; Lee, 1989; Straub, 1989; Yin, 1994). To get valid insights from the study, we followed the criteria and tactics recommended in designing and analyzing cases (Yin, 1994). Semi-structured interview questions were developed to explore TMS actions and reviewed by four experienced case researchers (Table I). Since our focus was on top management inuence on implementation outcomes, we searched for relatively homogeneous case sites. This would enable theoretical replication while allowing us to examine cross-case similarities and differences (Grover et al., 1995). Four primary case selection criteria were used when searching for implementation sites: (1) the project must have had a long-term strategic implication for the organization; (2) the project must have been materially completed within the past 18 months; (3) the project must have entailed substantial change within the organization; and (4) the IS adopted must have entailed a high level of task interdependence. Specically, we targeted ES implementations because we felt that the broad scope of disruptive changes typically accompanying large-scale system implementations would allow us to more easily observe the role of top management (Davenport, 1998; Markus et al., 2000). ES implementations also usually demand a high level of task interdependence (Markus et al., 2000). Based on the above criteria, two universities implementing an ES were chosen (the information of each university is listed in Table II). About 19 interviews were conducted with top managers (two from each university), department managers (two from each university), project managers (one from each university), users (four from each university), and one trainer (from university A). The case results are reported in the following. University A: SAP payroll implementation University A, with 13 faculties, 6,375 staff and faculty, and 55,000 full- and part-time students spread over three campuses, is one of the largest universities in Canada.

Exploring the impact of TMS

207

BPMJ 14,2

Question 1 Users: What role did your direct manager (or project champion) play in your adoption of the IS? Senior managers or department managers: What did you perceive your role in the implementation? Users/managers: Do you know why your organization adopted the IS? Senior managers: Why did you decide to adopt the system? Users/managers: What types of support were provided? Senior managers: How did you support the implementation? Users/managers: What types of training were provided? Users/managers: Did you feel that the implementation of the system was supported by the organization? Why? Users/managers: What changes has the system brought to your tasks? Senior managers: How did the system change the existing business processes? How did you prepare the users for the change? All subjects: What are the differences between the old system and the new system? Users: What do you think about your use of the system? Managers: What do you think the users use of the system? Users: Do you nd the system difcult to use? Users: What were the challenges you have faced in your use of the system? Managers: What were the challenges users faced in their use of the system? Senior managers: What were the challenges you faced in implementing the system? How did you overcome the challenges? Users: What are the reasons that you use the system? Managers: What are the reasons that users adopted the system? Users: What were your reactions towards using the system? Senior managers: What were the users reactions towards using the system? How did you deal with these reactions? All: What do you think about the adoption of the system by your organization? Users/managers: What do you use the system for? All subjects: Do you feel the implementation was successful? Why?

208

2 3 4 5 6 7 8 9 10

11 12 Table I. Summary of interview questions 13 14 15

University A Organizational context Size Annual budget Age of institution (years) Ownership, language Ranking (2005 national survey) Current administrations tenure Unionized Project context Project budget Number of affected users Prior user experience with large-scale IS projects Project manager experience External support 10,000 staff, 68,000 students $480 million 200 Public, English No. 2 in Canada Three years No $17 million 350 None 16 years Vendor (SAP) Third-party consultants

University B 3,000 staff, 29,000 students $206 million 130 Public, English No. 1 in Canada Two years No $2 million 300 None 10 years Vendor (PeopleSoft) Third-party consultants

Table II. Research context

Before the adoption of the SAP system, university A was employing an in-house-developed system that was neither integrated nor Y2K compatible. In the early 1990s, the university organized a long-term project named Rethinking Administration: Business Process Reengineering to create a business infrastructure to enable: . dissemination of information; . coordination of decisions; and . management of actions to and among people and systems internally and externally. Adopting an enterprise-level IS was part of the project. Several ES software vendors were considered, including Oracle, PeopleSoft, and SAP. The SAP nancial information systems (FIS) and human resources information systems (HRIS) were selected. FIS was composed of four modules: logistics, funds management, nancial accounting, and controlling. HRIS included personnel administration, time management, payroll, benets, planning, and seminar and convention management modules. A phase-in implementation approach was adopted to allow the team to concentrate primarily on one module at a time, with implementation of previous and subsequent modules overlapping slightly. Each module went through system development, conguration, prototyping, and then nal cutover. This case study focused on the payroll system implementation (see Table III for project timetable). Vice-provost of human resources (HR) who served as champion, the vice-provost of planning and budget, and the provost were the co-champions of the project.

Exploring the impact of TMS

209

University A Year Activities 1996 Bought the SAP HR system, including payroll, benets, and administration Implementation 1996 Formed business process managemenzt committee 1997 Formed HRIS steering committee Set up project committee 1998 SAP conguration System testing May Formal review sessions on SAP HR July Just-in-time training for departmental administrators and primary users System went live Training for secondary users and non-appointed staff Process training to department administrators Adoption

Year 1995

University B Activities

Bought the PeopleSoft HR system including payroll, benets, and administration 1996 Started training for HR team members, middle managers, and super users Formed HR steering committee 1997 Set up a training lab System conguration HR modules testing HR user training 1998 January PeopleSoft HR went live February Ad hoc training based on individual needs

Table III. Summary of project time table

BPMJ 14,2

210

Challenges The key challenge of the SAP payroll implementation was mainly concerned with the top managers decision to decentralize the central HR department. In the former centralized, largely manual payroll system, business ofcers were responsible for completing and submitting simple request forms for all of the staff in their department. These requests were then processed by a staff of 20 employees in the HR department. Deans in large faculties complained about the system, and wanted autonomy and responsiveness in dealing with HR-related matters. Responding to these complains, top managers held a clear vision of where the university should go with the SAP system: replacing the legacy system and reengineer existing business processes. They believed that by transferring the responsibilities to local faculties and department, HR personnel could focus on higher order processing functions (e.g. recording legislative changes). The decentralization, however, required business ofcers to process hiring, calculating employees gross and net pay, recording deductions and benets contributions, and producing tax statements and management reports. Many of these activities demanded expert familiarity with organizational policies, tax regulations, and various tax and management reports, which none of these business ofcers possessed. To make things worse, many business ofcers knew little about computers, and some of them did not know how to open a window. Consequently, the decentralization posed a big challenge to business ofcers. Some business ofcers, overwhelmed by the changes, quit and some resigned. The remaining ofcers were left frustrated. Top managers behaviors Facing these issues, top managers saw themselves mainly in providing resources (nancial and personnel) and offering training. Regarding users frustration and confusions, top managers had their own interpretations. As commented by the VP:
People abound to complain and resist. This is human nature! Training will help them.

Employee training, however, did not prepare users for the changes. Users indicated that they were taught step-by-step instructions on how to key in data, but they were not taught about organizational policies and tax regulations. Users recalled that during the training sessions, they were constantly called to come back to their posts to nish their jobs. As a result, the planned ve-day training program was effectively reduced to approximately three days. Users were confused about what types of behaviors the top managers expected How could they expect us to use the system without letting us learn it rst? Firmly believing that the decentralization was inherent in the SAP system and therefore the re-structuring was necessary, top managers ignored users reactions. Under the time pressure and with the assumption that users would soon discover the benets of the system soon enough, they decided to push through on the implementation. They [top managers] believed that as long as we kept pushing, people would eventually use the system, pointed out a project manager. Implementation outcomes On the day that the new SAP payroll system replaced the centralized manual system, users expressed overwhelming dissatisfaction. Business ofcers were shocked by the extent of change to their jobs, and disappointed that expected functionalities were

not delivered. They felt that the university unfairly loaded a lot of work on their shoulders. They were very angry:
After the system went live, we two senior people and I held a rst town hall meeting. So we went out to meet business ofcers. The rst time we went was with forty business ofcers. We met all at once in a big room. The rst meeting at the Actuarial Science building was very interesting. They were yelling, all kinds of that stuff.

Exploring the impact of TMS

Furthermore, the use of the newly implemented system was problematic because the business ofcers were not prepared well for their new tasks. As the project manager recalled:
If someone goes on maternity leave, the business ofcers do not really understand a lot of the policies we have made for that issue. However, we asked them to enter the information into the system. Quite often, I would say 90 percent of the time, they would make mistakes. So somebody here at HR has to correct them. But you only know the mistakes after the payment has been made.

211

Facing complaints from all over the university, the project team had to stamp out res, moving from one crisis to another. Although the payroll module was technically nished on time, a lot of clean-up had to be done following the deadline users were re-trained and town hall meetings were set up with departmental users in order to solve their problems. The proposed upgrade in the spring of 1999 was postponed to give more time for users to catch up and become more familiar and comfortable with the software. University B: PeopleSoft implementation University B consists of 12 faculties and schools, with 3,114 faculty members and approximately 23,000 undergraduate and graduate students. Its legacy systems were housed on a costly, antiquated, and terminal-based IBM mainframe system (punch cards were still being used for some applications in the late 1990s). Staff members frequently worked late nights generating reports, even though the data were already stored in the system. University B decided to move from a mainframe platform to a client/server system, and packaged PeopleSoft administration modules (including HR, student administrative systems, and nancial systems) were chosen. The implementation of the HR module took place over a three-year period, and went live in 1998. As in university A, a phase-in approach was used: the HR module was rolled out rst, with the other modules following at a later date. This case focuses on the HR module implementation. Two vice-provosts, of academic administration and external relationships, were appointed as co-champions for the implementation (see Table III for timetable). Challenges The legacy system had been used for over 20 years, and users had become comfortable with their old ways of doing things. The old procedures were second nature to the staff. To enter data to the system, for instance, they used to prepare a punch card and submit it for processing with the next batch run (and to change a piece of data simply meant preparing a new punch card). With the level of real-time integration and information sharing desired for the new system, however, it was crucial that users

BPMJ 14,2

212

catch and eliminate errors before they entered the system, since the information was accessible (with appropriate security clearance) throughout the entire university and could have immediate ripple effects on other departments. Therefore, the new system required that users reform their old ways of doing things, and this resulted in fear and frustration for many users. As indicated by one project member and trainer, the system implementation caused a lot of growing pains and a lot of battling because they [users] still think back to what the old world used to be. To make matters worse, the system was initially unstable and unreliable, in part because it was not designed for the Canadian educational context. Despite many tests and modications, the system still crashed repeatedly often in the middle of training sessions. Users were overwhelmed by the extent of change in their daily tasks and felt uncertain due to their lack of computer knowledge and skills. One user recalled that she complained to her departmental manager, I hate computers. I hate the system. Another user who had been serving the university for over 20 years commented, It was a hazardous project. I sometime thought, Will it survive? Top managers behaviors The top managers saw themselves important in securing nancial resources but also essential in constantly supporting users to meet their needs. As commented by one of the VPs:
I really believe in the use of internal resources, which means you have to train them and really have to develop them in a way that they feel happy, theyre comfortable. You cant just say, Go do this. You have to keep supporting them.

Facing users confusion and resistance, the top managers set up a special training laboratory to let employees experiment with the interface by adding, editing and deleting dummy data, without having to worry about the consequences. Users appreciated the value of this facility; I learned the system by playing with it at the training centre. Furthermore, top managers relied on informal communications through which they paid regular visits to departments to understand what support users needed. As the project manager remarked, he got real support, not just support on paper. One team member said during the interview:
We got the support. The vice-provost occasionally stopped by our ofces and asked how we were doing [. . .] The president had a party for us at Christmas-time because we worked over Christmas. Several VPs were at the party, and they were just very supportive. They came down to take good care of us. Occasionally we all got chocolates from them. Chocolate made us work!

The effort of top managers in change management eased users anxiety over the incoming system, addressed their concerns, recognised the challenges they faced, and allowed them time to grasp the new system. Feeling supported by top managers in pushing the implementation towards the ultimate goal, the middle managers tried to inspire their subordinates to adopt the system. An HR staff supervisor was so involved in the implementation that she kept paper and a pen beside her bed in case she awoke in the middle of the night with an idea. The bedside notepad idea inspired other employees to follow her example everybody was wearing two hats doing his/her daily job while learning the system in their project room. The sense was that everyone

was trying their best to learn the system, and that no one wanted to let the others down. As one user put it, We did it [the system implementation] for us! Implementation outcomes University B nished the HR system on time, and users were happy with the new system. Based on this previous experience, seven months after the implementation of the HR module, university B successfully completed a system upgrade to a new version in approximately half the time most PeopleSoft customers normally take. University B thus earned its reputation as one of PeopleSofts premier client organisations, particularly among educational institutions. Case analysis In both cases, top managers exhibited supportive actions in resource provision and change management. We evaluate the two types of supportive action and implementation outcomes based on overall interviewee responses (Table IV). Resource provision for both implementations was classied as high because all interviewees did not indicate any problems with resources provided. Change management for university A was rated low for the following reasons: . there was no well-dened mechanism to assistant the alignment between the system and end-users; and . users effort in learning and mastering the system was not rewarded or appreciated. Change management for university B was rated high because top managers took actions on all two fronts. By differentiating types and levels of TMS actions, we are able to examine the three perspectives on TMS actions. Deterministic perspective The two cases suggest the applicability of the deterministic perspective to some extent. For example, resource provision seems to positively relate to project completion, as both implementations were nished on time. However, a further analysis suggests that these actions appear to interlink with each other. Change management without resource provision does not necessarily lead to expected implementation outcomes, as both implementations cost millions of dollars, and stretched over more than one year. As the result, the interplays with the two supportive actions suggest that the impact of TMS actions on implementation outcome is not as straightforward as what the deterministic perspective assumes.
University A Top management support Resources provision Change management Implementation outcomes User satisfaction User skills Project completion Strong Weak Low Low Completed University B Strong Strong High Moderate to high Completed

Exploring the impact of TMS

213

Table IV. Types and level of TMS

BPMJ 14,2

214

Contingent perspective The contingent perspective proposes that the task interdependence mediates the relationship between management support and implementation outcomes. In examining the perspective, we rst analyze the change of task interdependence caused by the adoption of the technology. Before the SAP implementation in university A, there was little interdependence between business ofcers in one department and business ofcers in another department, and between business ofcers and central HR people. After the implementation, business ofcers and central HR staff became highly interdependent because the system brought business ofcers and central HR people onto the same platform. The information keyed in by the business ofcers would affect the entire system. University B had a situation similar to university A; that is, administrative ofcers were responsible for completing front-end paperwork (e.g. for local appointments), then staff in the central HR processed the paperwork and entered the data in the legacy system. The PeopleSoft system, by tightly knitting the previously scattered HR business processes, increased the interdependence between the administrative ofcers and the central HR department. Top managers in university A reacted to the increased task interdependence by securing required resources. The increased level of resource provision led to the completion of the project, but did not result in user satisfaction, skills, and organizational impact, suggesting a partial support for the contingent perspective. In contrast, top managers in university B responded with an increased level of resource provision and change management. The positive implementation outcomes imply the support of the contingent perspective. In analyzing the cases, we identify other factors that could have intertwined together to draw top managers supportive actions: . the inexperience with the new system; . the looming Y2K deadline; and . the importance of the system to the organization. Neither university had experience in the implementation of a large-scale system like SAP or PeopleSoft but both universities used the implementation as an opportunity to comply with the Y2K deadline or to reengineer their business processes. As stated by one of the VPs, The implementation was very important to us because of the Y2K, and also because it was a complex system. After the year 2000, both universities went through a number of system upgrades, which transpired much more smoothly than the rst implementation. People sort of knew what was going to happen. They knew the system, and there were few surprises to them, commented the project manager of the university A. By distinguishing management supportive actions, we uncover that while our case in university B seems to support the contingent perspective, university As case implies that a strong resource provision does not necessarily lead to positive implementation outcomes. In addition, we discover that task interdependence may not be the sole factor that draws TMS actions the inexperience with the new system, intertwined with a strict deadline and the importance of the system to the organisation, necessitated TMS.

Dynamic perspective The dynamic perspective implies a uctuating level of TMS and its complex effect on implementation outcomes. Our analysis of the deterministic and contingent perspectives reveals an intricate picture of the effect of TMS on IS implementation outcomes. How the level of TMS changed/unchanged is analyzed below. In university A, the level of resource provision remained stable throughout the implementation process to meet the need for training, allocate technical resources to set up the infrastructure, and prepare users for the new system. The level of change management showed little uctuation as top managers relied only on resource provision to assist business ofcers during the transition period. In university B, the level of resource provision remained strong to meet the demand for human and technical resources. The content and level of change management, however, uctuated. For example, at the beginning of the implementation, top managers showed a strong support in offering training and technical assistance, but exhibited a little support in addressing user specic needs. Our above analysis conrms the dynamic perspective that top managers adjust their content and level of support based on conditions that result from the implementation process. The two cases suggest an adaptation process where top managers adjust their supportive actions to lead the implementation process towards the pre-dened goals. The adaptation process is reasonable for several reasons. First, IS implementations, especially large-scale implementations like the two studied in this research, are rarely predictable issues and challenges related to the quality of system, training, resources, users, middle managers, and consultants emerge from time to time. This requires top managers to adjust their behaviors to deal with these issues and challenges. Second, the top managers at the two universities were inexperienced with large-scale system implementations; as a result, their initial actions might not have been effective in the context of an IS implementation. The top managers needed to adjust their support content and level to achieve the expected outcomes. As shown by the two cases, positive implementation outcomes seem to follow if the adjusted support meets the dynamics of the implementation process (as was the case for university B), and fall if the adjust support falls short or there is no adjustment (university A). Discussion and conclusion An abundance of research has been conducted on TMS and IS implementation outcomes. However, the existing studies are divided with respect to the effect of TMS. We are the rst study examining the three perspectives on the impact of TMS. Our research contributes to the current MS literature by identifying the three perspectives regarding the impact of TMS, and comparing their applicability under two large-scale ES implementations. The results of our case analyses suggest that the deterministic and contingent perspective may be a simplied version of a complex picture and may not reect how top management actions affect implementation outcomes. Our case analysis shows that top managers followed the dynamics of the IS implementation process, and reacted through the changes in their support content and level to guide the implementation. What is the appropriate level of support and what should be supported, however, may vary across organizational contexts. As Mahring (2002) identies, too much

Exploring the impact of TMS

215

BPMJ 14,2

216

support interferes with normal operations of project managers. Future studies can explore how contextual factors (e.g. technologies, scale of implementations, roles of project managers and consultants) contribute to the dynamics of TMS, and consequently implementation outcomes. Second, our case study illustrates that different types of actions should not be treated as exercising similar effects on implementation outcomes. Future studies should further explore the different effect of resource provision and change management on implementation outcomes, and uncover other types of important actions under different organizational and implementation contexts. This study offers several ndings that are useful to practitioners. Our case results indicate that top managers need to constantly obtain feedback from users, and adjust their supportive actions and the level of these supportive actions accordingly. Since large-scale system implementations tend to necessitate foreseeable and unforeseeable organizational changes (Davenport, 1998; Markus and Tanis, 2000), rather than rely solely on training and technical assistance, top managers need to adapt their level and content of support to t what is needed. In addition, our study reveals the importance of top manager visibility across the entire IS implementation process. Top managers should not assume that employees will be aware of their support. Senior managers must actively demonstrate their determination and appreciation not only through abstract rationalizations, but also through a steady execution of concrete actions (Fox and Amichai-Hamburger, 2001). Lastly, our case ndings emphasize that top managers need to go beyond resource provision in promoting an IS. Resources provision might lead to project completion, but in order to gain expected benets from an IS, top managers also need to pay attention to change management to obtain user satisfaction. TMS has been believed to be essential for IS implementation success. The impact of TMS, however, remains unknown, as the current TMS studies are holding divided perspectives. We compare the three perspectives by conducting case studies on two ES implementations. Our results depict a complicate picture of the effect of TMS. In particular, our study reveals that the impact of TMS depends on how well top managers adjust their level and content of support throughout an IS implementation outcomes. Our research has important implications to academic researchers and practitioners.
References Akkermans, H. and van 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, pp. 35-46. Bardi, E., Raghunathan, T.S. and Bagchi, P.K. (1994), Logistics information systems: the strategic role of top management, Journal of Business Logistics, Vol. 15, pp. 71-85. Benbasat, I., Goldstein, D.K. and Mead, M. (1987), The case research strategy in studies of information systems, MIS Quarterly, Vol. 11, pp. 369-86. Brockner, J. (1992), The escalation of commitment to a falling course of action: toward theoretical progress, Academy of Management Review, Vol. 17, pp. 39-61. Bruque-Camara, S., Vargas-Sanchez, A. and Hernandez-Ortiz, M.J. (2004), Organizational determinants of IT adoption in the pharmaceutical distribution sector, European Journal of Information Systems, Vol. 13, pp. 133-46.

Champy, J.A. (1995), Reengineering Management: The Mandate for New Leadership, Harper Business, New York, NY. Davenport, T.H. (1998), Putting the enterprise into the enterprise systems, Harvard Business Review, Vol. 76, pp. 121-31. Davis, F.D. (1993), User acceptance of information technology: system characteristics, user perceptions and behavioral impacts, International Journal of Man-machine Studies, Vol. 38, pp. 475-87. Delone, W.H. (1988), Determinants of success for computer usage in small business, MIS Quarterly, Vol. 12, pp. 51-61. Doll, W.J. (1985), Avenues for top management involvement in successful MIS development, MIS Quarterly, Vol. 9, pp. 17-35. Dong, L. (2001), Modeling top management inuence on ES implementation, Business Process Management Journal, Vol. 7, pp. 243-50. Ewusi-Mensah, K. and Trzasnyski, Z.H. (1991), Information systems project abandonment: an exploratory study of organizational practices, MIS Quarterly, Vol. 15, pp. 67-88. Fox, S. and Amichai-Hamburger, Y. (2001), The power of emotional appeals in promoting organizational change programs, Academy of Management Executive, Vol. 15, pp. 84-95. Green, S.G. (1995), Top management support of R&D projects: a strategic leadership perspective, IEEE Transaction on Engineering Management, Vol. 42, pp. 223-32. Grover, V., Kettinger, W.J. and Teng, J.T.C. (1995), The implementation of business process reengineering, Journal of Management Information Systems, Vol. 12, pp. 109-44. Guimaraes, T. and Igbaria, M. (1997), Client/server system success: exploring the human side, Decision Sciences, Vol. 28, pp. 851-76. Hall, G., Rosenthal, J. and Wade, J. (1993), How to make reengineering really work, Harvard Business Review, Vol. 71, pp. 119-31. Hammer, M. and Champy, J.A. (1993), Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business, New York, NY. Igbaria, M., Zinatelli, N., Cragg, P. and Cavaye, A.L.M. (1997), Personal computing acceptance factors in small rms: a structural equation model, MIS Quarterly, Vol. 21, pp. 279-305. Jarvenpaa, S.L. and Ives, B. (1991), Executive involvement and participation in the management of information technology, MIS Quarterly, Vol. 15, pp. 205-28. Keil, M. (1995a), Escalation of commitment in information systems development: a comparison of three theories, Academy of Management Journal, Vol. 38, pp. 348-52. Keil, M. (1995b), Pulling the plug: software project management and the problem of project escalation, MIS Quarterly, Vol. 19, pp. 421-47. Keil, M. and Robey, D. (1999), Turning around the troubled software project: an exploratory study of the deescalation of commitment to failing courses of action, Journal of Management Information Systems, Vol. 15, pp. 63-87. Kwon, T.H. and Zmud, R.W. (1987), Unifying the fragmented models of information systems implementation, Critical Issues in Information Systems Research, Wiley, New York, NY. Lee, A.S. (1989), A scientic methodology for MIS case studies, MIS Quarterly, Vol. 13, pp. 33-52. Leonard-Barton, D. and Deschamps, I. (1988), Managerial inuence in the implementation of new technology, Management Science, Vol. 34, pp. 1252-65.

Exploring the impact of TMS

217

BPMJ 14,2

218

Lewis, W., Agarwal, R. and Sambamurthy, V. (2003), Sources of inuence on beliefs about information technology use: an empirical study of knowledge workers, MIS Quarterly, Vol. 27, pp. 657-78. Lucas, H.C. Jr, Ginzberg, M.J. and Schultz, R.L. (1990), Information Systems Implementation: Testing a Structural Model, Ablex Publishing Corporation, Norwood, NJ. Mahring, M. (2002), IT Project Governance: A Process-oriented Study of Organizational Control and Executive Involvement, Stockholm School of Ecnomics, Stockholm. Markus, L.M. and Tanis, C. (2000), The enterprise systems experience from adoption to success, in Zmud, R.W. and Price, M.F. (Eds), Framing the Domains of IT Management: Projecting the Future Through the Past, Pinnaex Educational Resources Inc., Cincinnati, OH. Markus, L.M., Axline, S., Petrie, D. and Tanis, C. (2000), Learning from adopters experiences with ERP: problems encountered and success achieved, Journal of Information Technology, Vol. 15, pp. 245-65. Newman, M. and Sabherwal, R. (1996), Determinants of commitment to information systems development: a longitudinal investigation, MIS Quarterly, Vol. 20, pp. 23-54. Ramamurthy, K. and Premkumar, G. (1995), Determinants and outcomes of electronic data interchange diffusion, IEEE Transactions on Engineering Management, Vol. 42, pp. 332-51. Sanders, G.L. and Courtney, J.F. (1985), A eld study of organizational factors inuencing DSS success, MIS Quarterly, Vol. 9, pp. 77-93. Sauer, C. (1993a), Why Information Systems Fail: A Case Study Approach, Alfred Waller Ltd/ Fawley, Henley-on-Thames/Orchards. Sauer, C. (1993b), Understanding support-lessons from a case study, Australian Journal of Information Systems, Vol. 1, pp. 63-74. Sharma, R. and Yetton, P. (2003), The contingent effects of management support and task independence on successful information systems implementation, MIS Quarterly, Vol. 27, pp. 533-55. Straub, D.W. (1989), Validating instruments in MIS research, MIS Quarterly, Vol. 13, pp. 147-69. Sultan, F. and Chan, L. (2000), The adoption of new technology: the case of object-oriented computing in software companies, IEEE Transaction on Engineering Management, Vol. 47, pp. 106-26. Teo, T.S.H. and Pian, Y. (2003), A contingency perspective on internet adoption and competitive advantage, European Journal of Information Systems, Vol. 12, pp. 78-92. Thong, J.Y.L., Yap, C.S. and Raman, K.S. (1996), Top management support, external expertise and information systems implementation in small business, Information Systems Research, Vol. 7, pp. 248-67. Wixom, B.H. and Watson, H. (2001), An empirical investigation of the factors affecting data warehousing success, MIS Quarterly, Vol. 25, pp. 17-41. Yin, R.K. (1994), Case Study Research, Design and Methods, Sage, Newbury Park, CA. Zmud, R.W. (1984), An examination of push-pull theory applied to process innovation in knowledge work, Management Science, Vol. 30, pp. 727-38. Corresponding author Linying Dong can be contacted at: ldong@ryerson.ca To purchase reprints of this article please e-mail: reprints@emeraldinsight.com Or visit our web site for further details: www.emeraldinsight.com/reprints