Journal of Change Management Dispersed Change ...

This article was downloaded by: [Dawson, Patrick] On: 25 May 2011 Access details: Access Details: [subscription number 937993155] Publisher Routledge Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 3741 Mortimer Street, London W1T 3JH, UK

Journal of Change Management

Publication details, including instructions for authors and subscription information: http://www.informaworld.com/smpp/title~content=t713703618

Dispersed Change Agency and the Improvisation of Strategies During Processes of Change

Kathryn Charlesa; Patrick Dawsonbc a Health Service Research Unit, Aberdeen University, UK b University of Aberdeen Business School, UK c University of Wollongong, Australia First published on: 25 May 2011

To cite this Article Charles, Kathryn and Dawson, Patrick(2011) 'Dispersed Change Agency and the Improvisation of

Strategies During Processes of Change', Journal of Change Management,, First published on: 25 May 2011 (iFirst) To link to this Article: DOI: 10.1080/14697017.2011.576653 URL: http://dx.doi.org/10.1080/14697017.2011.576653

PLEASE SCROLL DOWN FOR ARTICLE Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf This article may be used for research, teaching and private study purposes. Any substantial or systematic reproduction, re-distribution, re-selling, loan or sub-licensing, systematic supply or distribution in any form to anyone is expressly forbidden. The publisher does not give any warranty express or implied or make any representation that the contents will be complete or accurate or up to date. The accuracy of any instructions, formulae and drug doses should be independently verified with primary sources. The publisher shall not be liable for any loss, actions, claims, proceedings, demand or costs or damages whatsoever or howsoever caused arising directly or indirectly in connection with or arising out of the use of this material.

Journal of Change Management iFirst article, 1 – 23, 2011

Dispersed Change Agency and the Improvisation of Strategies During Processes of Change Downloaded By: [Dawson, Patrick] At: 15:07 25 May 2011

KATHRYN CHARLES∗ & PATRICK DAWSON∗∗ ,† ∗ †

Health Service Research Unit, Aberdeen University, UK, ∗∗ University of Aberdeen Business School, UK, University of Wollongong, Australia

ABSTRACT This article explores the implementation of enterprise resource planning (ERP) in a multinational corporation (MNC). It examines the notion of dispersed change agency and investigates the part played by different types of change teams, focusing on their roles, interactions and competencies. A processual research methodology was used in the collection of data through non-participant observation, face-to-face interviews (68), telephone interviews (3) and documentary evidence. Data collection occurred at four different geographical locations in Norway, Russia, Paris (MNC headquarters) and the UK. This article draws on data collected as part of the Paris case study. This was the location from where the ERP global implementation was coordinated by a specially created project team. A key finding centres on questioning conventional notions of leadership in highlighting the importance of dispersed change agency, clusters of competencies and development of best practices to facilitate the improvisation of strategy during processes of ERP change. KEY WORDS : change agency, strategy, competency, improvisation, ERP

Introduction

Much of the change management literature highlights the difficulties of managing large-scale change (Andriopoulos and Dawson, 2009). Beer and Nohria (1998) point out how approximately 70% of all major change initiatives fail. This is especially costly for large-scale technology projects that fail to meet their objectives, for example, the considerable investment by companies in enterprise resource planning (ERP) software implementation. ERP is generally defined as Correspondence Address: Patrick Dawson, University of Aberdeen Business School, Edward Wright Building, Dunbar Street, Aberdeen AB24 3QY, UK. Email: [email protected] 1469-7017 Print/1479-1811 Online/11/000001–23 # 2011 Taylor & Francis DOI: 10.1080/14697017.2011.576653

Downloaded By: [Dawson, Patrick] At: 15:07 25 May 2011

2

K. Charles & P. Dawson

comprising business software packages that impose standardized procedures for the input, use and transmission of data throughout an organization and which aim to integrate business processes (Davenport, 2000). These processes relate to main corporate functions (e.g. financial, operational, sales, purchasing, marketing and human resource management) and Appleton (1997) estimates that about half of all implementation efforts fail to meet their objectives, with 40% being partially implemented, and 20–50% of initiatives shelved (Martin, 1998). Some commentators suggest that implementation of ERP promotes improved efficiency and financial returns through the integration of discrete business processes (Davenport, 2000; Shanks et al., 2003; Dery et al., 2006). ERP implementation in multinational corporations (MNC) aims to allow effective decision making as it enables full control over resources through imposing standardized procedures for the input, use and transmission of data throughout their global operations (Umble et al., 2003). However, there are a number of challenges faced by MNCs who embark on large-scale organizational change, such as managing change across multiple sites, being able to accommodate different cultural expectations, maintaining systems and resources for coordinating activities and ensuring the smooth flow of information, and sustaining complex operations when also implementing major change. For example, Cooperrider and Bilimoria (1993, p. 110) identify the issues that arise from organizing global change as ‘contested, nonlinear meta problems with long lead times, unintended side effects, unclear cause –effect structures, and consequences that are often irreversible’. Technology and Change In MNCs and the Role of Internal Change Agents

Within the strategic management literature there has been a long-standing debate around issues pertaining to the management of MNCS (Bartlett and Ghoshal, 1989; Schendel, 1991). The early work of Prahalad and Doz (1981) drew attention to the problems of maintaining strategic control over subsidiary operations, they examine patterns of strategic control (Doz and Prahalad, 1984) and in identifying a range of mechanisms used by central headquarters to reassert influence, they argue that data management information systems are often viewed as a primary vehicle (Doz and Prahalad, 1981). Bartlett and Ghoshal (1991), in a special issue of the Strategic Management Journal, examine issues arising from managing dispersed geographical operations as companies expand internationally; whereas, Enright and Subramanian (2007, p. 896) argue that ‘one of the crucial questions in international business research is how the multinational organizes and manages its international operations’. For many of these writers, attention is given to control and coordination mechanisms (see, for example, Martinez and Jarillo, 1989, 1991) and the way that technology is used as a potential ‘fix’ to concerns over fragmentation and lack of standardized procedures across different sites of an organizations’ operating environment (see also, Taggart, 1998). On this count, Ciborra (2000) claims that too often the strategic ambitions of corporations are bound within technology-led solutions that are limited to system concerns and the procurement of best-of-breed software applications. In practice, however, implementing information systems across subsidiary sties can exacerbate problems of integration and have unintended disorganizing effects (Robey et al., 2002).

Dispersed Change Agency

3


Problems of Integration and Fragmentation

Integration and standardization of processes instituted via ERP implementation are often seen to offer MNCs a capability to control and coordinate their activities. However, a major challenge for MNCs operating on a global scale relates to balancing choices for integration (standardization) and fragmentation. MNCs are perceived as facing regular problems which relate to their complex organizational structures, cultural diversity, geographically dispersed operations and increasing need to respond to dynamic global industries and markets competition (Doz and Prahalad, 1984). MNCs need centralized control and standardization in work processes as well as fragmented processes that meet diverse local needs (Bartlett and Ghoshal, 1989). Information technology (IT) patterns in MNCs broadly fall along a spectrum ranging from independent systems developed by individual subsidiaries that meet local configuration choices, and standardized corporate-wide systems imposed by the corporate headquarters on subsidiaries. A key issue for MNCs is how to balance integration through the standardization of processes that maintain control with IT systems that cope with diverse local nonstandardized processes. Positivistic thinking that promotes the notion of technology as providing powerful sets of tools that can pull the messy world into an ordered measurable system is, according to Ciborra (2000), misplaced. In an edited collection that reports on six case studies examining the implementation of complex information infrastructures in large corporations, a number of discrepancies are identified between initial goals and eventual outcomes (Ciborra, 2000). Managers are shown to develop a range of initiatives to cope with deviations to planned models and visions. In contrast to those who suggest the need to search for methods to achieve more integration and control (Caruso, 2007), it is argued that the somewhat ‘messy collage’ that exists should not be viewed as necessarily dysfunctional or bad. Likewise, Hanseth et al. (2001), in their study of a SAP enterprise system at Norsk Hydro, usefully suggest that standardizing processes and IT systems across a global organization may paradoxically lead to unpredictability in processes and this may also contribute to failures in ERP change projects. Hanseth et al. identify how concepts of modernization and globalization (Beck et al., 1994) may link to reduced control and predictability. Local processes often may not fit with standard processes and result in side effects. These may create instability and unpredictability that can spread quickly and, due to the integration of MNC processes, may impact on the entire enterprise. As such, greater levels of IT integration may paradoxically spawn reduced control and go some way to explaining the immense difficulty MNCs face in implementing ERP change. For Ciborra (2000), there will always be the uncontrollable and unpredictable, and ‘drift’ (deviations that occur from planned expectations for unexpected reasons beyond the influence of individuals or groups) will occur through contextual influences and, for example, the unknowns of final user behaviour. As Hanseth and Ciborra (2000, pp. 2–3) state: Corporate information infrastructures are puzzles, or better collages, and so are the design and implementation processes that lead to their construction and operation. They are embedded in larger, contextual puzzles and collages. Interdependence,

4

K. Charles & P. Dawson intricacy, and interweaving of people, systems, and processes are the culture bed of infrastructure. Patching, alignment of heterogeneous actors, and bricolage (make do) are the most frequent approaches we found in the company cases, irrespective of whether management was planning or strategy oriented, or inclined to react to contingencies.

These studies highlight the importance of managing the complex processes of change, which are messy, unpredictable and will require modification to set plans and visions. As our case will demonstrate, improvisation and adaptation are central to the management of these processes.


Implementing Large-Scale Change and the Role of Internal Change Agents

Kanter (1983) suggests that corporations that succeed in such times are those that have the ability to be masters of change by creating a climate that encourages ‘the introduction of new procedures and new possibilities, encouraging anticipation of and response to external pressures’ (p. 65). This highlights the importance of ‘change agency’ and the development of organizational capabilities to support adaption and change (Ottaway, 1983). It is recognized that change is facilitated by a range of staff (Gilley, 2005; Kotter, 1996). However, there appears to be a paucity of empirical research concerning the role of change teams in managing large-scale change (West, 1990; Mayon-White, 1993; Cummings and Worley, 1997) and the dispersal of change-agency roles within types of change team (Caldwell, 2003, 2005). The ERP literature also highlights a number of key research challenges which relate to a greater understanding of change management (Esteves and Pastor, 2001); issues around workplace control, power and resistance (Dery et al., 2006) and the roles and influence of key players during change (Somers and Nelson, 2004). In focusing on change agency, we note that change agents have been broadly defined by Caldwell (2003, p. 140) as: ‘the individuals or teams that are going to initiate, lead, direct or take direct responsibility for making change happen’. The organizational literature considers the range of change agents participating in these processes (Ottaway, 1983; Judson, 1991; Galpin, 1996; Buchanan and Badham, 2008). Transitional change teams and leadership of change programmes comprising change teams are noted (Duck, 1993). However, little attention has been given to a more contextual and temporal mapping of the roles, relationships and activities of change agents and teams tasked with large-scale change (Hartley et al., 1997; Balogun et al., 2005). There is also a tendency to integrate change agency within a single model which aims to identify the competencies of one generic type of change agent (Caldwell, 2003). Competencies are viewed as employee behaviours that result in high levels of performance and a competency framework sets out to identify a collection of competency clusters and the behavioural indicators associated with these competencies (Boyatzis, 1982). Much debate centres on a definition of competency and some authors emphasize that identification of traits may present some difficulties, because they are subjectively defined and cannot be trained for (Pettigrew andf McNulty, 1995). Boyatzis (1982), in particular, questions whether competency



5

relates to personal qualities or traits, motives, self-images, aspirations or levels of job performance, or whether it relates to skills or capabilities that may be learnt. Taking account of difficulties in identifying generic change-agent competencies, three key components can be distilled from the literature. These comprise: the skills and knowledge to implement change; a behaviour repertoire of ploys and tactics to influence decision-making; and the abilities to use ‘their knowledge and experience in a creative and improvisatory, contextually appropriate and self critical manner’ (Buchanan and Badham, 1999, p. 227). Our study is particularly concerned with notions of change agency and its dispersal to change teams during the process of ERP transformation in an MNC. Pettigrew (2001), Buchanan (2003) and Caldwell (2003) point out that insight is needed concerning the roles of internal change agents operating in teams. Some authors also highlight how limited attention has focused on dispersed change agency (Buchanan et al., 2007) and the concerted actions of employees to enable transformational change (Gronn, 2002). Caldwell (2005, p. 106) asserts ‘the full implications of leading change in a distributed or dispersed process has yet to be fully explored within contextual research’. Likewise, Pettigrew (1985) and Dawson (1994) identify the paucity of longitudinal studies that explore organizational history, the content of the change, contextual complexity, the dynamic process of change and the diverse vested interests influencing change strategy over time. In this article, our attention is on formal change agency (change agents officially tasked with change), although the roles and actions of other employees and external change consultants are accommodated in data analysis of the change process. We argue that this enables exploration of the relationship between the actions of key actors, and may identify ways to improvise implementation strategy to cope with emerging ‘side effects’ of change processes that undermine change implementation. Research Strategy and Method

The main objective of the study was to gain a holistic and deep understanding of the roles, interactions and competencies of internal change agents operating in change-agent teams and the related complex issues pertaining to the management of large-scale ERP change in an MNC. In pursuing this objective, a processual research methodology (Pettigrew, 1985; Dawson, 1994) was employed to study change over time by conducting four longitudinal case studies over a 24-month period in the Paris headquarters of an MNC, and subsidiaries in Russia, Norway and the UK. The longitudinal nature of this study enabled data to be collected during the entire period of ERP implementation. Gummerson (2000) identifies that the case study approach is especially useful in exploring the unfolding nature of change processes as they occur. He argues that single case studies have the capacity to reach a fundamental understanding of processes, driving forces and structure. Although, some authors argue that single cases lack material for replication and comparison (Eisenhardt, 1989; Pettigrew, 1990), we contend that this single case study, focusing on one MNC, allows for an in-depth study of the ERP change process and provides a unique understanding of the management of change implementation across an entire multinational organization, and thus represents a revelatory case (Yin, 1994).


6


Case study analysis of change explored a range of participant perspectives (change team members, subsidiary employees, managers and external consultants) across four sites in Paris, Norway, UK and Russia. The final write-up of the material is represented by an extensive volume of work. Because it is not possible to cover all these detailed findings within a single article, our focus here is on the Paris site. This was selected because Paris was the location of the project team tasked with control and coordination of the ERP implementation. It usefully identifies the entire global ERP implementation strategy and highlights the decision making, roles, practices and competencies of the central control team (project team) and their engagement with two other types of dispersed change teams: subsidiary implementation teams and a post-deployment team. Data collection comprised 68 face-to-face semi-structured interviews, three telephone interviews, participant observation within the research sites and the collection of company documentary evidence over a period of two years. The Paris site comprised 20 interviews with the central control team and post-deployment team, participant observation and collection of documentary data over the two years of the study with both MNC staff and external consultants. A processual approach was applied which incorporates elements of the frameworks put forward by Pettigrew (1985) and Dawson (1994) and guided both data collection and analysis. Hence, questions focused on staff members’ temporal understanding of change content (ERP strategy), change activities and processes, as well as contextual influences. The benefit of applying this framework lies in its ability to identify linkages or interaction between multilevel analysis of internal and external organizational context and processual analysis of organizational phenomenon. This holistic and embedded approach aims to provide a rich contextual analysis to ‘catch reality in-flight’ (Pettigrew, 1985, p. 37) and also understand and identify the dynamics of change processes. Interview data was transcribed and all data sources input into Nvivo 7 software which facilitated data management and analysis. Concepts were derived from the conceptual framework and emerged from the data. Figure 1 identifies concept codes and category development. At each iterative stage, the conceptual framework and wider theoretical models were considered. Data analysis involved ‘decoupling, classifying and recombining data to develop, refine and create concepts that enable the presentation of new accounts’ (Dawson, 2003, p. 114). This was facilitated by the triangulation of multiple data sources and a search for alternative explanations to explain unexpected outcomes. Analytical generalization of study findings was facilitated by the comparison of interview data against existing theory. This study has some limitations because identification of change-team roles and activities are based mainly on reported behaviours and limited observed behaviours. The detailed case study generated some interesting associations between successful ERP change strategy and change-agency roles, competencies and contextual characteristics, but statistically generalizable inferences cannot be deduced from this methodology. Likewise, the processual methodology provides room for deep contextual understanding of ERP change, but it has been criticized for complexity in replicating this methodology and difficulty in translating findings and recommendations to practitioners (Burnes, 2000).


Figure 1. Concepts and category development.

7


8



Strategic Change In a Multinational Corporation: The Case of MNOC

The context for the study is a multinational oil corporation (which for reasons of anonymity is henceforth referred to as MNOC) that is a leading global provider of technology, project management and information solutions to the international petroleum industry. It employs 87,000 people drawn from over 140 nationalities and located in approximately 80 countries, and it operates through 33 oilfield services regions which are grouped into geographic regions. Examination of company strategy documents indicated that integration of IT business systems was a long-term key objective of the corporation. Competitors had already completed integration of business systems and it was seen as a means for this corporation to improve the quality and timeliness of decision making and hence improve competitiveness. Criticality for ERP implementation was emphasized because a prior attempt at integrating IT business systems, four years earlier, into one software application (SAP) was perceived to have failed, incurring huge costs to the organization (the extent of these costs was not divulged). Access to MNOC gave us a valuable research opportunity to examine, over time, the customization and global implementation of a ‘Lawson’ ERP software, which would have major implications for all MNOC business operations. The Paris Site

The Paris data set was used to analyse MNOC’s global implementation strategy with particular attention being given to the roles, practices and competencies of three dispersed change teams: a central control team (project team), a subsidiary implementation team, and a post-deployment team. From our analysis of these change teams, we focus on three key areas: first, the emergent and converging nature of both ERP software development strategy and MNOC’s global implementation strategy. Second, the composition, roles and interactions of our three different change teams. Third, competencies and practices that were mobilized to support ERP change. In particular, we drill down to suggest how these three change teams worked in concert to enable timely improvisation of the ERP implementation strategy that resulted in continued momentum for ERP change in the MNC. The Emergent and Converging Nature of Both Global ERP Technology and Implementation Strategies

Participant perceptions of critical events and decision making drawn from interview and documentary data (change communications and newsletters) enabled the researcher to trace the evolution and improvisation of the ERP change strategy. This identified that the ERP change strategy comprised two interwoven strategies: one for ERP software development and another for ERP implementation. Tables 1 and 2 indicate the decision-making sequences of ERP software and implementation strategies. All central control team members reported that these strategies involved first, design of the broad parameters of the ERP software, and second, global implementation following a pattern of regional sequential implementation commencing with pilots in Norway and Nigeria, after which global implementation proceeded in



Table 1.

9

Common terms used by central control team to describe ERP software strategy decisions

1. New software needed 2. Choice of easily adaptable software 3. Centralised project team set up to map and customise software 4. Limited consultation with subsidiary staff 5. Subsidiary support change agents appointed 6. Focus on electronic communication with project team 7. Mapping of subsidiary processes 8. Gap analysis of subsidiary processes by subsidiary change agents 9. Changes in subsidiary processes 10. 80/20 rule applied for mapping subsidiary requirements per gap analysis 11. GOLIVE implementation training 12. Problems reported in software 13. Post deployment team appointed 14. Post deployment team identify problems and spread best practice 15. Subsidiary process leaders take over software improvisation 16. Communities of practice assembled to spread best practice 17. Shadows appointed 18. Project team disbanded 19. World-wide financial centre take over software development

Europe 1, Europe 2, Africa, Latin America, Middle East 1, Middle East 2, and finally Canada and the USA. It was generally accepted by all project team members that the complexity, diversity and geographical distribution of business operations, together with the disruptive nature of the ERP change strategy dictated Table 2.

Terms used by central control team to describe ERP implementation strategy

1. Project team assembled 2. Subsidiaiy support team selected 3. Subsidiaiy support team trained in Paris 4. Use of electronic communication to identify ERP change strategy 5. Training in subsidiaries 6. Use of 80/20 rule for implementation 7. Formal evaluation 8. Re-structure project team 9. Subsidiaiy awareness workshops developed 10. E-learning developed for subsidiaiy support 11. Detailed change management and communications strategy developed 12. Newsletter functions developed 13. Training database developed 14. Project team lobby for more subsidiaiy support 15. Subsidiaiy communications specialists appointed 16. Post deployment team appointed 17. Objective of ERP implementation becomes subsidiaiy objective 18. Changes in project team to reflect cultural and linguistic differences in subsidiaries 19. Post deployment team visit subsidiaries 20. Post deployment assemble lists of problems with software 21. Production of implementation knowledge archive 22. Project team disbanded

10


that decisions regarding the choice of software and its parameters and implementation could only successfully emerge by establishing practices to access user software needs. As such, the centrally located project team recognized the importance of working with locally based subsidiary staff to effect improvisation in the development of the ERP software. Likewise, the differing contextual characteristics of subsidiaries also dictated that the ERP implementation strategy would need to emerge rather than being imposed centrally.


Three Types of Change Team

Interviews and ERP change documentary evidence focusing on identification of the activities and roles of participants confirmed the existence of three types of dispersed temporary change team: the central control team (project team) located in the Paris headquarters, local implementation teams located in the subsidiaries, and a post-deployment team that visited each subsidiary. Composition and Modes of Interaction of the Central Control Team (Project Team)

The central control team comprised approximately 102 members, consisting of internal employees and external consultants (approximately 30%). Within the central control team, a core team managed the overall strategy and two further subteams took responsibility for software and hardware development, and change management implementation issues. The core team of MNOC employees played a vital role in mediating both implementation and software redesign. Both subteams comprised employees and external consultants, with specialist roles in software development, redesign of business processes and change management (training and communication). Interaction within the central control team (at the Paris site) was mainly informal; few formal meetings were held. The weekly meeting of the entire central control team was generally regarded as a means of political power posturing within the team. An example of this is indicated in the following team member’s comment: We have a weekly team meeting on Wednesday where they’re meant to give us the latest information on whatever. To be honest, I rarely go to it. When I do go to it, I don’t learn anything new or I hear a lot of information that I know is inaccurate. I feel that sometimes it’s point-scoring on different groups.

Central control team members generally endorsed the informal nature of team communication. They perceived this as a function of the close proximity of the team within an open-plan office arrangement over two floors of the corporate headquarters, and that they were familiar with each other. Many of this team reported that they had worked, socialized or communicated with each other prior to the project. The following comments from a central control team member support this view: We know people in each of the core functions so that if an issue crops up within the field we know the person to consult. There is very little formal interaction within the


11


team. Its very informal. So when the training team goes out to the location and he or she identifies an issue or encounters a query about my expertise, then he or she will direct it to me.

This informality was absent in the initial communications of the control team with the implementation teams located in the subsidiaries. Direct contact prior to implementation was limited by presentations and meetings with senior managers and the designated change agents from the subsidiary, and took place in the subsidiary and at the Paris site. Communication was dominated by the use of e-mails and telephone conferencing. During the implementation phases, central control team change agents did increase their level of face-to-face contact by supporting the trainers and subsidiary staff members in a small number of visits to the subsidiaries. But for the most part, communication between project team members and subsidiary staff occurred via two mediums: an electronic ticketing system, which allocated problems identified in the subsidiary to the appropriate central control team member; and e-mails from subsidiary implementation team members (see Table 3 for a summary of central control team roles). Subsidiary Implementation Teams

Interviews and participant observation at the Paris site also identified the importance of the subsidiary implementation teams in enabling ERP implementation. It was generally accepted that subsidiary implementation teams primarily acted as bridges of communication between the subsidiaries and the central control team (project team). Central control team members initially identified the skills and experience required for subsidiary support teams, but the local subsidiary managers were ultimately responsible for selection. Members of the subsidiary implementation teams were called ‘superusers’ and were specifically assigned responsibility for procurement, logistics and financial processes. Their activities were identified as mapping business processes, identifying processes not included in the software, testing the customized software and Table 3. Role Type Technical Training Communication Change management Political Planning / Coordination Evaluating Problem solving

Terms used to describe central control team roles Activities: examples of terms used

Process mapping, software development, testing software Design and deliver training courses, software support training Production of newsletters, e-mail updates, meetings, ticketing, creating a message Management of motivation Networking, use of reputation, limiting communication Preparation of schedules, project management Feedback sessions, questionnaire evaluation Asking questions, identifying problems, understanding issues, finding solutions, solving problems

12

K. Charles & P. Dawson Table 4.

Role Type

Terms used

Technical

Mapping business processes, producing gap analysis, validating processes, testing software, setting up security profiles Promoting software, using networks Scheduling and managing training Supporting staff with ticketing, help describe problem to project team, supporting using e-ticketing Telephone conversations with core team Helping solve user problems Scheduling training, training in Paris, working with project team

Change management Training Support Communication Problem solving Coordinating implementation


Subsidiary implementation team roles

training. In general, it was perceived that subsidiary implementation teams were critical to successful implementation because they were the physical face of the ERP change process in the subsidiary. Roles in promoting and building support for the implementation were seen as essential, especially in the early stages of the global roll-out when senior management support and engagement with the ERP change process was limited. Central control team members recognized that subsidiary implementation team members were dependent on their personal reputation and informal networks to drive the change process. This led to expansion of these teams from three to six members as the global implementation rolled out. Nevertheless, although central control team members drew attention to the significance of subsidiary implementation teams, more detailed analysis of their roles, activities and competencies could not be accessed from interviews and observation of the project team. This led to negotiated access for further research in subsidiary locations in Norway, the UK and Russia. Table 4 identifies subsidiary implementation team roles.

Post-deployment Team

Interviews conducted at the Paris site identified that as the global roll-out proceeded throughout Europe and Africa, problems arising from the use of the software and raised by staff in the implemented subsidiaries had overwhelmed the central Paris control team. This affected their capacity to focus on further implementation and for this reason, a post-deployment team was assembled and tasked with returning to the subsidiaries to identify and solve user problems. The post-deployment team comprised 10 members: five of these were leaders for the key business processes (purchasing, legal and fiscal, sales, inventory and cash management) and three were external consultants (two for software development and one for project management and document control). The team was led by a senior manager and their key remit was to spend time with subsidiary personnel discussing and observing their needs, and identifying solutions and best practice techniques. They visited the implemented subsidiaries and through on-the-job training, meetings and training workshops accessed user problems and identified


13

solutions. Over this period, they accumulated a set of practices or ‘rules of thumb’ which they disseminated to all subsidiaries where implementation had taken place. The post-deployment team performed a critical role in accessing tacit understanding of user problems. Interviews conducted with post-deployment team members provided a critical evaluation of both the functioning of the project team and insight into how the organization tackled the problems generated by such a rapid implementation process. They soon realized that a key issue was that employees were unable to understand how the software integrated diverse business processes:


They did not grasp the applications, because people didn’t know what to do with applications that’s because we had skipped a key thing of relating the process to the applications. We gave them the application but we didn’t say how it fits in with their role. (Post-deployment team)

This problem occurred because the ERP package was a chain of applications performed by different groups. Most users were struggling to understand their part of the software application and were unaware of the consequences of their actions for other users. According to the post-deployment team, implementation had only focused on teaching the employees about the software. For this reason, the post-deployment team leader deliberately selected team members that had not been involved in the initial design of the software. As such, the postdeployment team were keen not to be associated with the central control team or to be seen as defenders of the software. In seeking to maintain this distance, they used a different logo on all their communications material. Yet despite the team leader’s critique of the implementation process, he did concede that it would have taken too long to access subsidiary staff using face-to-face engagement and consultation from the beginning. The nature of the change process required subsidiary staff to use the software in order for them to begin to understand how it worked. These sentiments are reflected in his comment: We go in after and solve the problem, if we don’t do that, it takes too long . . . When you look at the way the applications are employed in this company, it’s often like that. We always succeed. There is always a six month difficult period when we have more commitment to do whatever it takes to make it work. If you give this project to a consultant, they would say you are crazy going that way but in the end, it will take less time to do it this way, and time is the main thing. (Post-deployment team)

Another key function of the post-deployment team was their role in developing permanent structures or communities of practice within subsidiaries to continuously improve and realign business processes. They were instrumental in developing the roles of subsidiary staff responsible for each of the individual ERP software modules (e.g. purchasing, sales, accounts payable). These roles were extended to include collaboration with subsidiary process leaders to improve existing processes and share knowledge, which in turn mobilized effective problem solving throughout the organization. This was accomplished via the use of teleconferencing between process leaders in regional subsidiaries once a

14

K. Charles & P. Dawson Table 5.

Terms used to describe post-deployment team roles

Roles Sense making Communication Relationship building Facilitator of best practice Build communities of practice between, subsidiaries Counter resistance


Train staff

Terms used Identify user problems Communicate subsidiary problems to project team, kick off meetings in subsidiaries, on the job support Building relationship with staff, close contact Solving problems Find out what works, apply solutions found in other rollouts, spread best practice Subsidiaries monthly telephone conference, Process leaders from subsidiaries discuss problems, finding out answers from other locations Not defend software, use different logo, post deployment team not involved in the initial software design Sit with staff and train them

month, and in their use of an electronic bulletin board. The practices and roles performed by the post-deployment team contrasted with the central control team. Their efforts emphasized direct face-to-face interaction with subsidiary staff, in an attempt to access tacit understanding of user problems and to transmit organizational knowledge of successful solutions. Table 5 identifies post-deployment team roles. Competencies for Managing Change

Particular competencies were referred to by most respondents. These related to the wide range of experience and practical knowledge of financial and operational business processes by staff of long-standing tenure and with experience of working in diverse regional locations of the MNC. Emphasis was also placed on the importance of having practical or functional and operational knowledge. This is reflected in the following comments: Competency – well it’s a mixed cocktail, a little bit between business systems, applications and development. I have also spent several years as a training development manager in different segments. (Change manager)

The competency of central control team staff was seen by many as a key factor in tackling implementation problems. From the outset, the central control team comprised employees who possessed a wide range of skills and were viewed as having a high level of competence covering knowledge of business processes and software problems, whereas the implementation team were seen to have a useful portfolio of competency for dealing with local change management and user issues. In tackling issues on the ground, the post-deployment team demonstrated abilities to access understanding of employee problems with the ERP software. These competencies were supported through their long-standing tenure, practical user knowledge of subsidiary business processes and detailed knowledge of the ERP software.



15

Post-deployment team members remarked on the failure in the design of the implementation strategy to relate changes in business processes to the new application. For them, the implementation had focused on teaching the employees about the new software and paid too little attention to the need for local reconfiguration during the initial operation and use of the new system. Interestingly, although their knowledge of business processes, user needs, ERP software, as well as sensitivity, awareness and experience were all deemed important, it was the political competencies applied to handling people and driving the change process that all respondents considered essential. Examples of this included: being economical with communication; alliance building; networking; and building trust through persuasion, negotiation, diplomacy and changing tactics. As our case analysis has hopefully demonstrated (Figure 2 is used to capture the range of different change team competencies), there was a number of different sets of competencies required of change agents dispersed throughout the corporation who, over time, were involved in different and often overlapping aspects of change from the formulation of strategy, through the design and planning for change, implementation, to the eventual reconfiguration-in-use in the uptake of ERP at MNOC. Making Things Happen: Competencies and Change Improvisation

Central control team members’ competencies for contextual sensitivity and problem solving appeared to enable improvisation of ERP software and implementation strategies with each subsidiary roll-out. They understood the differing contextual characteristics of each subsidiary and developed learning derived from implementation in the preceding subsidiaries. Training was developed to include awareness workshops and e-learning. E-learning software provided the means whereby subsidiary employees could control their own learning. Such techniques sought to overcome the time and resource constraints of implementation, whilst also appealing to the organizational culture which prized autonomy. The change management subteam also recognized the critical role of the subsidiary implementation team: It appears we are following the right track as we have realized we need to change the strategy again, to identify the ‘superusers’ (subsidiary internal change agents), before the training rather than in the training and then give them extra training. I suppose we identified that we needed more resources earlier.

A need to engage with operational personnel was also recognized and facilitated further recruitment of staff with operational experience to the implementation team. These new members used their knowledge of organizational structures and culture to develop changes in the content of training workshops, which became more practically orientated in the use of real scenarios and operational field language. Despite this, their personal delivery of these workshops was restricted because of the high financial cost of subsidiary visits and the short time frame available for implementation (see Table 6, which illustrates how



16

Figure 2. Change team competencies.

Dispersed Change Agency Table 6. Nature of improvisation


Project team recruits staff with operations ‘hands on’ experience

17

Exemplars of strategy improvisation Exemplar

ID

The user needs people who know what thev are talking about . . . The problem for the person is, -’ I have an invoice 1 cannot process it’. We need people to talk the language, and so it was important to bring in more hands on people. Identify subsidiary support team It appears we are following the right track as we have earlier realised we need to change the strategy again, to identify, (subsidiary internal change agents), before the training rather than in the training and then give them extra training. I suppose we identified that we needed more resources earlier, (P1/5). Increase in size of subsidiary We have been successful in getting the subsidiaries to support commit one person so that communication doesn’t come from Paris but from the subsidiary. They have other roles within the subsidiary. . . So we have coordination with people in each subsidiary; they handle communication, (Pl/11). Proactive approach to gain The very first thing I did was to engage at the very top subsidiary management buy-in level. . . We needed to start working with Latin America, but we needed to make sure that this visibility and understanding was going to happen, to gain commitment of the resources to make it happen in the time frame, (P1/6). I learned a lot about how things were being done and I learned that our company was not going to learn that way. . . So the way things started changing was the way we approached the regions, (PI/4). More face-to face support to At GOLIVE they started with a war room where people subsidiaries asked questions but we only had 5 questions. When they were rolling out Asia they said it was a waste. So we sent out a lot of people at the GO LIVE for LAM they threw bodi es out there, (P 2/5). Subsidiary ownership It’s moving from the team in Paris towards the regions trying to solve the issues. . . The local process champion for each process, if they have a programming issue, they report it and it gets moved up the priorities of the Paris development team, (UK2/010). Identify subsidiary support team It appears we are following the right track as we have earlier realised we need to change the strategy again, to identify (subsidiary internal change agents), before the training rather than in the training and then give them extra training. I suppose we identified that we needed more resources earlier, (Pl/5). Increase in size of subsidian support We have been successful in getting the subsidiaries to commit one person so that communication doesn’t come from Paris but from the subsidiary. They have other roles within the subsidiary. . . So we have coordination with people in each subsidiary; they handle communication, (Pl/11).

∗

CC

∗

CC

∗

CC

∗

CC

∗

PD

∗

CC

∗

SI

∗

SI

∗

S1

(Continued)

18


Table 6. Continued Nature of improvisation Recognition of sense making and sense giving

Identify and solve software and business process problems


Not defend software configuration

∗

Exemplar Users cannot describe the problem so that people can understand it. . .if you’re a finance person or accounting person the way you describe a problem is not the way a technical person will understand it. So we are an intermediary between the end user and the programmers, so we could interpret the problem and convey it so it could be understood, (IR/034). They did not grasp the applications, because people didn’t know what to do with applications. We had skipped a key thing of relating the process to the applications. We gave them the application but we didn’t say how it fits in the change of role, (IP1/8). They didn’t know the application. We wanted people with a new eye. . .. The key of trying to develop a best practice is being able to do that. If you are defending a software or an application it won’t work, (Pl/8). The user needs people who know what they are talking about . . . The problem for the person is, -’ I have an invoice I cannot process it. We need people to talk the language, and so it was important to bring in more hands on people (P1/13).

ID ∗

SI

∗

PD

∗

PD

CC¼Central Control Team, ∗ SI¼subsidiary implementation Team, ∗ PD¼Post Deployment Team

change teams competencies for problem solving and contextual sensitivity led to changes in ERP software and implementation strategies). Practices and Structures to Support ERP Change

The central control team also developed ‘best practices’ and structures to support ERP software and implementation strategies. Best practices are defined as commonly perceived actions, processes, methodologies or patterns of behaviour that, applied in a specific context, produced superior outcomes and could be used as organizational ‘rules of thumb’. Political practices included the application of the 80/20 rule and use of their personal networks and reputation to gain support and access for the identification of user needs. The 80/20 rule set an objective that 80% of software requirements identified by the subsidiaries should be achieved. In this way, software and implementation strategies could be promoted as successful without ever achieving all of their requirements. Moreover, omission to articulate a vision for the ERP software left interpretation of the intended software functionality open to development by the subsidiaries. As such, production of the software became a constant process of identifying, balancing and negotiating user needs. The 80/20 rule is the main rationale behind all our training decisions, and what is happening right now does address the bulk of issues, but the remaining 20% is not going away.


19

Structural solutions were also applied to overcome communication problems arising from the remoteness of the central Paris project and subsidiary implementation teams. Electronic ticketing software filtered and allocated the problems identified by staff to appropriate central control team members, whereas computer hardware problems were attended to by a separate hardware team. Similarly, the appointment of subsidiary internal change agents and a centrally located help desk manned by experts provided human intermediaries to cope with implementation problems.


Discussion

This study offers a deeper understanding of change agency and how it is dispersed to enable ERP change in an MNC. Existing knowledge centres on the generic capabilities and roles of change agents without linking these to modes of interaction and the tactics and practices that change team members engage in overtime. In focusing our analysis on how change content (understanding of ERP strategy), MNOC context, competency and politics influenced the actions of these three types of change team over time, we were able to identify the roles, competencies, traits, practices and modes of interaction that favoured the functioning of these teams, and factors that also limited their working. This enabled us to produce a typology of three change teams: the central control team, subsidiary implementation teams, and the post deployment (trouble shooting) team. We established that each of these teams performed differing types of roles, possessed differing levels of competency and were involved in interactions which were based on varying degrees of face-to-face contact and electronic communication. The study confirms the existence of some generic capabilities such as personal qualities of being open and approachable, tolerant of differences, context sensitivity and being prepared to listen and assess issues in a non-judgemental fashion (Buchanan and Badham, 2008). It also highlights how change team members acted as ‘boundary spanners’ (Balogun et al., 2005). Subsidiary implementation teams with local knowledge of subsidiary processes and culture, as well as supportive networks, were able to translate understanding of the ERP software to local staff. Similarly, the post-deployment team members’ close proximity to subsidiary staff and their knowledge of global ERP implementation served to access and transmit understanding of ERP problems and best practices across the MNC. Both these change teams served to support the central control team and mitigated their problems of physical proximity that limited transfer of organizational knowledge and learning. The processual data drawn from the Paris case study illustrates how the change strategy was not produced in a single event, but evolved over time and comprised two key elements. The first focused on the design of the software and analysis of current operating procedures, and the second focused on managing global implementation of the new system in dealing with contingencies and unforeseen events. The central control team, implementation team and post-deployment team consisted of a range of employees with abilities and skills that combined to create a dynamic and effective web of roles. This form of distributed change agency proved highly effective in dealing with a range of social, behavioural and technical issues as they arose during software development and


20


implementation. Hence the unforeseen events that Ciborra (2000) and Hanseth et al. (2001) refer to were dealt with by improvisation of the implementation strategy. These improvisations emerged in response to the situated practices and problems of users, and in this way align with Ciborra’s (2002) view on improvisation as situated action in making sense of contextual circumstances in emergent problem-solving. In our study, the distributed roles within teams and the diverse modes of communication appeared to accomplish two critical functions: first, they improved communication and feedback as they created channels whereby change agents could gain deep understanding of subsidiary user problems and then transmit back their solutions; and second, these teams maintained and built support for the change process. These findings support the claims of Buchanan (2003) and Caldwell (2003) that a range of individuals interact over time in supporting processes and utilizing combinations of skill sets in managing large-scale change. Managing the politics also appears critical (Buchanan and Badham, 2008) and the central control team, in particular, developed a range of practices. These included: omission to articulate a change vision; use of a formal evaluation procedure after the pilot implementation; mobilizing informal networks to build support; use of the 80/20 rule; setting a formal objective for ERP implementation to all subsidiary staff; devolving responsibility for ERP change communication to internal subsidiary change agents; building subsidiary steering committees to support implementation; and use of electronic ticketing and communications systems. Whereas post-deployment team methods included: a focus on face-to-face communication, training and support of subsidiary staff; use of kick-off meetings; promoting and training subsidiary process leaders to use electronic bulletin boards to share learning; promoting themselves as a completely different identity to the project team by use of different logos and staff; and displaying receptive behaviours in allowing subsidiary staff to impart their problems in using the software. Conclusion

In examining dispersed change agency and strategic change our study highlights the range of characters required to support large-scale change and the need for flexibility in adapting to unforeseen events. As such, these findings contribute to our understanding of complex change processes in large multisite corporations. The study also informs debates around the use of technology to tackle issues of fragmentation across dispersed operations and the limitations of positivistic thinking that may ultimately exacerbate disorganizing effects through what Ciborra (2000) refers to as ‘drift’ where deviations from planned expectations occur for unexpected reasons that are beyond the influence of individuals or groups. He calls for management information systems (MISs) to be brought back into the co-created and imperfect real world, arguing that too often technology can become an enemy and that companies should treat technologies as an ambiguous stranger and provide an environment of hospitality that is more likely to lead to innovation and learning (Ciborra, 2000). This requires recognition of the unknowable and unpredictable and highlights the importance of improvisation strategies that are able to accommodate situated problems and in so doing, modify



21

planned models and introduce new avenues of development. In our study, change agency and the leadership for ERP change was distributed across teams. In this way, it usefully illustrates how institutionalized structures or change teams enabled concerted action, and how these teams worked conjointly through co-performing work in collective performance to enable ERP transformational change. In analysing the roles, activities and competencies of different types of change team, the study provides new data on how change agency is dispersed and identifies the synergies between teams and team members which enable knowledge translation and transmission. We demonstrate how responsibility for change was distributed and how teams bootstrapped their activities to overcome problems associated with the complexity of ERP change, geographical dispersion and cultural diversity. In this way, the findings contribute to our understanding of complex change processes (Pettigrew, 1987), to the dynamics of change teams (Caldwell, 2003), and to the dispersal of leadership during large-scale programmes of change (Buchanan et al., 2007). In conclusion, therefore, we hope that this study usefully demonstrates how dispersed teams of change agents facilitated improvisation of the ERP software and implementation strategies to accomplish complex large-scale change.

References Andriopoulos, C. and Dawson, P. (2009) Managing Change, Creativity and Innovation (London: Sage). Appleton, E.L. (1997) How to survive ERP, Datamation, 43(3), p. 50. Bartlett, C.A. and Ghoshal, S. (1989) Managing Across Borders. The Transnational Solution (Boston, MA: Harvard Business School Press). Bartlett, C.A. and Ghoshal, S. (1991) Global strategic management: impact on the new frontiers of strategy research, Strategic Management Journal, 12(S1), pp. 5–16. Beck, U., Giddens, A. and Lash, S. (1994) Reflexive Modernization (Cambridge: Polity Press). Beer, M. and Nohria, N. (1998) Cracking the code of change, Harvard Business Review, 78(3), pp. 133–141. Balogun, J., Gleadle, P., Hailey, V.H. and Willmott, H. (2005) Managing across boundaries: boundaries shaking practices, British Journal of Management, 16(4), pp. 261–278. Buchanan, D. (2003) Demands, manipulations, careers: the lived experience of driving change, Human Relations, 56(6), pp. 663–684. Buchanan, D. and Badham, R. (1999) Power, Politics and Organizational Change: Winning the Turf Game (London: Sage). Buchanan, D. and Badham, R. (2008) Power, Politics and Organisational Change: Winning the Turf Game, 2nd edn (London: Sage). Buchanan, D., Caldwell, R., Meyer, J., Storey, J. and Wainwright, C. (2007) Leadership transmission a muddled metaphor?, Journal of Health Organization and Management, 21(3), pp. 246–258. Burnes, B. (2000) Managing Change: A Strategic Approach to Organisational Dynamics (London: Pearson Education). Boyatzis, R.E. (1982) The Competent Manager: A Guide for Effective Management (New York: Wiley). Caldwell, R. (2003) Models of change agency: a fourfold classification, British Journal of Management, 14, pp. 131–142. Caldwell, R. (2005) Agency and Change (London: Routledge). Caruso, D. (2007) Six ways to ensure an ERP implementation delivers value, Manufacturing Business Technology, 25(8), pp. 27–29. Ciborra, C.U. (ed.) (2000) From Control to Drift. The Dynamics of Corporate Information Infrastructures (Oxford: Oxford University Press). Ciborra, C.U. (2002) The Labyrinths of Information: Challenging the Wisdom of Systems (Oxford: Oxford University Press).


22


Cooperrider, D.L. and Bilimoria, D. (1993) The challenge of global change for strategic management: opportunities for charting a new course, in: P. Shrivastava, A. Huff and J. Dutton (eds) Advances in Strategic Management, pp. 99–142 (Greenwich, CT: JAI Press). Cummings, T.G. and Worley, C.G. (1997) Organization Development and Change, 6th edn (Cincinnati, OH: South Western College Publishing). Dawson, P. (1994) Organizational Change: A Processual Approach (London: Paul Chapman). Dawson, P. (2003) Understanding Organizational Change: The Contemporary Experience of People at Work (London: Sage). Davenport, T. (2000) Mission Critical: Realizing the Promise of Enterprise Systems (Boston, MA: Harvard Business School Press). Dery, K., Grant, D., Harley, B. and Wright, C. (2006) Work organization and enterprise resource planning systems: an alternative agenda, New Technology, Work and Employment, 21(3), pp. 199–213. Doz, Y.L. and Prahalad, C.K. (1981) Headquaters influence and strategic control in MNCs, Sloan Management Review, 23(1), pp. 15–24. Doz, Y.L. and Prahalad, C.K. (1984) Patterns of strategic control within multinational corporations, Journal of International Business Studies, 15(2), pp. 55–72. Duck, J.D. (1993) Managing change: the art of balancing, Harvard Business Review, (November– December), pp. 109 –118. Eisenhardt, K.M. (1989) Building theories from case study research, Academy of Management Review, 14, pp. 532–550. Enright, M.J. and Subramanian, V. (2007) An organizing framework for MNC subsidiary typologies, Management International Review, 47(6), pp. 895–924. Esteves, J. and Pastor, J. (2001) Enterprise resource planning systems research: an annotated bibliography, Communications of the Association of Information Systems, 7(8), pp. 1–51. Gilley, A. (2005) The Manager as Change Leader (Westport, CT: Praeger). Gronn, P. (2002) Distributed leadership as a unit of analysis, Leadership Quarterly, 13, pp. 423–451. Gummerson, E. (2000) Qualitative Methods in Management Research (New York: Educational Management Administration). Hanseth, O. and Ciborra, C.U. (2000) Introduction, in: C.U. Ciborra (ed.), From Control to Drift. The Dynamics of Corporate Information Infrastructures (Oxford: Oxford University Press). Hanseth, O., Ciborra, C.U. and Braa, K. (2001) The control devolution: ERP and the side effects of globalization, Database for Advances in Information Systems, 32(4), p. 34. Hartley, J., Benington, J. and Binns, P. (1997) Researching the roles of internal-change agents in the management of organisational change, British Journal of Management, 8, pp. 61–73. Kanter, R.M. (1983) The Change Masters: Innovation and Entrepreneurship in the American Corporation (New York: Simon & Schuster). Kotter, J. (1996) Leading Change (Cambridge, MA: Harvard Business School Press). Martin, M.H. (1998) An electronics firm will save big money by replacing six people with one. . ., Fortune, 137(2), pp. 149–152. Martinez, J.I. and Jarillo, J.C. (1989) The evolution of research on coordination mechanisms in multinational corporations, Journal of International Business Studies, 20(3), pp. 489–514. Martinez, J.I. and Jarillo, J.C. (1991) Coordination demands of international strategies, Journal of International Business Studies, 22(3), pp. 429–444. Mayon-White, W. (1993) Problem Solving in Small Groups: Team Members as Agents of Change (London: Paul Chapman). Ottaway, R.N. (1983) The change agent: a taxonomy in relation to the change process, Human Relations, 36(4), pp. 361–392. Pettigrew, A.M. (1985) The Awakening Giant: Continuity and Change in Imperial Chemical Industries (Oxford: Blackwell). Pettigrew, A. (1987) Context and action in the transformation of the firm, Journal of Management Studies, 24(6), pp. 649 –670. Pettigrew, A.M. (1990) Longitudinal field research on change: theory and practice, Organization Science, 1(3), pp. 267–292. Pettigrew, A.M. (2001) Management research after modernism, British Journal of Management, 12(Special Issue), pp. 61–70.



23

Pettigrew, A. and McNulty, T. (1995) Power and influence in and around the boardroom, Human Relations, 48(8), pp. 845–873. Prahalad, C.K. and Doz, Y.L. (1981) An approach to strategic control in MNCs, Sloan Management Review, 22(4), pp. 5–13. Robey, D., Ross, J.W. and Boudreau, M.C. (2002) Learning to implement enterprise systems: an exploratory study of the dialectics of change, Journal of Management Information Systems, 19(1), pp. 17–46. Schendel, D. (1991) Introduction to the special issues of global strategy, Strategic Management Journal, 12(S1), pp. 1–3. Shanks, G., Parr, A. and Willcocks, L. (2003) Second-Wave Enterprise Resource Planning Systems (Cambridge: Cambridge University Press). Somers, T.M. and Nelson, K.G. (2004) A taxonomy of players and activities across the ERP project life cycle, Information & Management, 41(3), pp. 257– 278. Taggart, J.H. (1998) Strategy shifts in MNCs subsidiaries, Strategic Management Journal, 19(7), pp. 663–681. Umble, E.J., Haft, R.R. and Umble, M.M. (2003) Enterprise resource planning: implementation procedures and critical success factors, European Journal of Operational Research, 146, pp. 241–257. West, M.A. (1990) The social psychology of innovation in groups, in: M.A. West and J.L. Farr (eds) Innovation and Creativity at Work (Chichester, UK: Wiley). Yin, R.K. (1994) Evaluation: A Singular Craft (Washington, DC: COSMOS).