Introduction

Understanding key factors contributing to Information Technology (IT) adoption in organisations is a central concern in Information Systems (IS) research. Among key factors associated with IT project failures, users’ resistance is one of the most salient because it is related to human resistance to change (Jiang et al., 2000b). Existing literature provides practical knowledge about conflict types and conflict management styles (Miranda & Bostrom, 1993; Markus et al., 2000a; Barki & Hartwick, 2001; Cramton, 2001; Montoya-Weiss et al., 2001). However, most of this research was empirically conducted after IT had been implemented in organisations surveyed; thus, it can be considered to be observations made on downstream results of the upstream resistance process. As a consequence, a lot of acts of resistance are observed as being task-oriented and related to the non-appropriateness of IT that users have to cope with. Few empirical studies have investigated how individual and group resistance emerges and evolves during prior project stages (Lapointe & Rivard, 2005).

However, negotiations during IT implementation can raise affective-oriented resistance if users perceive threats concerning their values or power relationships because of expected organisational changes. A focus on pre-implementation phases is thus important, as IS managers need to anticipate potential conflicts and users’ resistance that can lead to project failure (Marakas & Hornik, 1996; Joshi & Lauer, 1998; Robey et al., 2002; McAfee, 2007). Because enterprise systems are considered to impact IT on future actions (Lee & Myers, 2004) because of their cross-functional perspective (Markus et al., 2000a, 2000b) and readiness to change (Kwahk & Lee, 2008), we report resistance evolution toward the ERP adoption project during the pre-implementation phase.

The rest of the article is structured as follows. The literature analysis reviews conceptual foundations of resistance, conflict and conflict management styles associated with IT implementation. While IS literature has separately developed related theories, we conceptualise a whole theoretic-system we call ‘IT Conflict-Resistance Theory’ (IT-CRT). The case study analysis delivers the results of a 2-year action research project conducted at Netia Corporation (a worldwide leader in video and audio broadcasting for TV and radio channels). First, our observations reveal that task-oriented conflicts expressed by employees actually hide a socio-political oriented conflict. These instances of resistance require the abortion of the ERP initially considered for a less impacting application on some specific process changes and on underlying power redistribution across groups of employees. Second, whereas conflicts toward IT are often considered as being required to be actively managed by the CEO (Markus et al., 2000a, 2000b; Barki & Hartwick, 2001), our case study delivers an alternative observation. IT describes how a passive-like attitude of managers during the IT pre-implantation phase does not prevent the resolution of a socio-political oriented conflict between two groups of employees. Our observations illustrate how the avoidance management style invites team members to cope with conflict situations and to express tacit causes of resistance. We also observe how this conflict between developers and administration employees switches to a compromise. In conclusion, the article views users’ resistance toward IT not as systematic negative behaviours aiming at project abortion, but invites researchers to explore how task-oriented and socio-political oriented conflicts can turn out to be key processes embedded in IS design.

Literature review

In management and organisation theories, the political school of thought developed by famous authors such as Mintzberg et al. (1998, 2002) or Crozier & Friedberg (1977) considers strategy formation and implementation to be shaped by political ploys. As a consequence, a strategic project usually involves shifting coalitions of dominant actors of parochial interests (Lee & Myers, 2004). Even if some research in IS views IT users’ resistance as a deep approach (Joshi, 1990; Krovi, 1993; Joshi & Lauer, 1998), it seems marginal compared to the many articles published on the subject. Lapointe & Rivard (2005, p. 462) reveal that among the 43 articles published during the last 20-year period on users’ resistance toward IT, only four do not consider resistance to be a factual characteristic of the context. The majority of these studies treat users’ resistance as a component of an organisational system at the individual and group level (Markus et al., 2000a, 2000b), and only a minor part of these studies focuses on causal conflicts (Jiang et al., 2000a).

While literature stresses resistance or conflict without making clear differences between both concepts, our analysis, both based on psychology and sociology theories, considers resistance as a behavioural dimension of conflict: the way a person expresses a conflict. Referring to the Theory of Reasoned Action (Ajzen & Fishbein, 1980), we consider resistance as an actual behaviour preceded by conflict, and conflict as a form of attitudinal beliefs corresponding to an affective or evaluative judgement of a person about the likelihood of the object or event consequences.

Resistance

User's resistance is defined as a subjective process psychologically based at the individual level (Jermier & Knights, 1994). In an important semantic analysis, Lapointe & Rivard (2005) describe behaviour as the primary dimension of resistance (p. 464). In this sense, behaviour is a reaction to a present or ongoing situation perceived as being negative (Ang & Pavri, 1994), as inequitable (Joshi, 1991), as a threat (Dent & Goldberg, 1999) or as a stressful feeling (Marakas & Hornik, 1996). According to Joshi (1991), resistance appears when the user perceives changes involved by an ‘unfair’ project in regard to his/her personal work or in regard to the group he/she belongs to.

Users can express resistance toward IT in an active form (visible and relatively easy to detect) or a passive form (harder to detect and difficult to deal with) (Tetlock, 1999; Tetlock, 2000; Jiang et al., 2000a). Empirical studies show that resistance is higher at the group level than the individual level (Lapointe & Rivard, 2005). In other words, a group of persons (depending on their professional category, professional competencies, age, gender, etc.) represents the most likely unit to develop high resistance toward IT. Indeed, at the group level, users’ resistance is often socio-political, whereas at the individual level, it is more psychological (Markus, 1983). Coetsee (1999) identifies four types of resistance:

  • Apathy corresponds to behaviour of disinterest and inaction of a person toward the situation. Also named ‘neutral zone’, it represents the situation in which people are aware of changes, but their perceptions are neutral and their behaviours characterised by a sort of passive resignation. According to Coetsee, this situation represents a transitional state between resistance and acceptance.

  • Passive resistance: a person adopts some behaviours aimed at slowing down changes and keeping the previous system (examples: voluntary delays in tasks to do, argumentation in favour of so-called advantages of existing rules and processes).

  • Active resistance is considered as a ‘constructive form’ aimed at the improvement of the project (examples: expression of different points of views, negotiation about a consensus, accommodation).

  • Aggressive resistance: users can resort to threats, blackmails, boycotts and all other actions whose objective is blocking the situation.

According to the author, these forms are not exclusive and should be considered as part of a continuum that encompasses, on the extreme, user acceptance and involvement. The way persons can behave toward an object can vary a lot. Some persons can accept changes involved, while others may reject them. In other words, persons can perceive differently the threats of a same object in function of the initial distribution of power (Markus, 1983) or established routines (Marakas & Hornik, 1996).

Conflict

Conflict is defined as a disagreement of persons or groups of persons perceiving a situation as being inconsistent with their own interests (Boulding, 1963; Robbins, 1974; Putnam & Wilson, 1982; Hocker & Wilmot, 1985). While acts of resistance concern forms of behaviours, conflicts are about the object of resistance and perceived threats (Lapointe & Rivard, 2005, p. 467). Several definitions made in Organisational Science (Putman & Poole, 1987), Psychology (Thomas, 1992) or IS (Barki & Hartwick, 2001) consider three conditions of conflicts: interdependence, interference and disagreement. By itself, each condition cannot be considered as a sufficient condition. Conflicts are more dependent on overlapping.

  • Interdependence exists when each party reaches a specific goal, at least because of the actions of the other party. In essence, interdependence is a structural condition for conflicts in a professional context because of respective consequences of the way the other party acts (Kumar & Dissel, 1996).

  • Interference is a behavioural condition for conflict and occurs when one or several parties oppose the other party’s attainment of its interests, objectives or goals. Interference thus represents the central behavioural node of any conflict (Barki & Hartwick, 2001, p. 198).

  • Disagreement is a cognitive condition for conflict and corresponds to divergence of interpretations toward values, objectives, needs, methods, etc. Disagreement refers to disputant behaviours and is considered as the central process associated with conflict (Wall & Callister, 1995).

While first and second properties sound like structural configurations associated with conflict, the latter deals with upward causes. At the individual level, a conflict can represent opposition to oneself (internal conflict), to other persons, groups of persons or to institutions (Thomas, 1992). According to Coser (1956), a conflict can be ‘realistic’ or ‘unrealistic’. A ‘realistic conflict’ arises from a frustration of a specific demand, and ceases if the actors’ demands are satisfied or if they can find alternative ways to achieve their ends. On the other hand, an ‘unrealistic conflict’ is the result from one antagonist's need to release tension; the conflict is an end by itself and there is no alternative to means.

At the group level (or intradepartmental level), conflicts can be task- (or process-) or relational-oriented (Deutsch, 1969; Pinkley, 1990; Jehn, 1995; Jehn & Bendersky, 2003). Conflicts about tasks or processes are issue-oriented, arising from differences between professional missions to be performed, whereas relational conflicts refer to personalised disagreements or individual disaffections. The former can be considered as differences of points of view rarely associated with negative emotions, while the latter can raise frictions and tensions, consequently affecting team performance (Jehn & Mannix, 2001). Research in psychology distinguishes this ‘affective component’ in two ways: a conflict can be ‘intellectual’ when persons focus on facts and thoughts involved, or ‘emotional’ when it is caused by feelings like jealousy, anger or frustration (Pinkley, 1990, p. 120).

At inter-group (or interdepartmental) level, Pondy (1967) identifies three types of conflicts among the subunits of formal organisations: (1) bargaining conflict that concerns interest groups in competition for scarce resources; (2) bureaucratic conflict between the parties to a superior–subordinate relationship; and (3) systems conflict about coordination issues among parties to a lateral or working relationship. Then, beyond task-related asymmetries (Walton et al., 1969), social and political ‘subsystems’ (Pondy, 1966) (about ideologies, values, power tensions, etc.) play a significant role in inter-unit conflicts. As consequences, obstacles to communication are considered to be main factors associated with this category of conflicts (Walton & Dutton, 1969), whereas frequent contacts (Nelson, 1989) or communication quality (Massey & Dawes, 2007) are observed as having a calming effect.

Conflicts associated with ERP implementation can encompass intra- and inter-department levels and mix several aforementioned dimensions. Our literature analysis in IS allows us to identify five different conflict types (see Table 1), which we aggregate as functions of their task vs socio-political orientation.

Table 1 Conflict types associated with IT implementation
Full size table

Conflicts about the system are about the IT design by itself, its functionalities and efficiency. These conflicts can be associated with the ‘perceived ease of use’ dimension of well-known acceptance models (Davis et al., 1989, 1992; Venkatesh, 1994), and are related to the attitude of individuals to use a new technology. Empirical research has provided useful observations about personal characteristics associated, such as readiness to change (Walczuch et al., 2007), personal competences and organisational commitment (Kwahk & Lee, 2008).

Conflicts about task definition and execution are caused by the way organisational processes have to be adapted or transformed to fit with IT process requirements (for example: how invoices and orders must be established, new data codification, signature validation process). These conflicts can be ‘internally initiated’ when users compare the way they achieve their tasks and perceive modus operandi and operational definitions (Besson & Rowe, 2001). They can also be ‘externally initiated’ because of the process constraints imposed by the IT to be implemented. For instance, ERP standard modules represent one of the most well-known conflict drivers because of ‘best practices’ imposed on employees without too much consideration of organisational specificities (Davenport, 1998; Markus et al., 2000a, 2000b; Lim et al., 2005). This type of misalignment with organisational processes (Hsiao-Lan et al., 2005) is all the more important, as problems in Management Information Systems (MIS) are more about the ability of users to understand how they must carry out their new tasks than about the ability of the firm to manage change (Robey et al., 2002).

Conflicts about new professional skills deal with competences users must develop in order to be qualified for job transformations involved by IT (Markus et al., 2000a, 2000b; Besson & Rowe, 2001). Accountancy is one of the most salient professional illustrations: before ERP implementation during the 1990s, an important part of daily work of these employees consisted of collecting, aggregating and synthesising a huge quantity of financial data. Enterprise applications dramatically change their assignments: being no more the ones who collect financial data, they are asked to interpret the information ex-post, in order to make sense and recommendations to top managers (Bernard et al., 2004).

Cultural conflicts are psychologically based. They refer to ideology by which some people share beliefs and make sense of their worlds (Trice & Beyer, 1993). Firm subunits may have their own subculture varying in their ideological content (Stewart & Gosain, 2006). In IS, value conflicts may arise from inconsistency between cultural principles of users or groups of users and the perceived underlying strategic objectives assigned to IT implementation (Leidner & Kayworth, 2006). Several empirical studies (Besson, 1999; Kohli & Kettinger, 2004; Bhattacherjee & Hikmet, 2007; Bhattacherjee et al., 2008) reveal how these conflicts can arise in the hospital sector. For example, Besson (1999) observes that financial control allowed by the ERP regarding hospital activities is perceived by medical employees to be an attempt of a market-based activity inconsistent with fundamental principles of health public services. The empirical analysis of Wagner & Newell (2004) reveals complementary observations according to which ERP can be problematic for organisational subcultures because mandating one epistemological position through the software design is based on ‘best practices’.

Power conflicts concern the way hierarchical authorities, autonomies and capabilities of influence of employees and management are likely to be redistributed after IT implementation. Power conflicts among managers are also sometimes referred to as governance conflicts or leadership conflicts (Besson & Rowe, 2001). Research in IS challenges understanding of IT development and implementation deviations by pointing out intricacies due to power influence exerted by actors (Markus, 1983; Davis et al., 1984; Markus & Bjorn-Andersen, 1987; Jasperson et al., 2002; Avgerou & McGrath, 2007). On the one hand, IT can give more power to key users by allowing them to use real time data access to functionalities (Davenport, 1998); on the other hand, IT can reduce the autonomy of employees (Markus, 1983). Despite hierarchical monitoring supported by IT, power losses for employees may be caused by more interdependencies with colleagues. For instance, in civil engineering project management, ERP implementations change the way main actors (project supervisors, architects, electricians, plumbers, etc.) collaborate (Gilbert & Leclair, 2004). Formerly, they did not have to communicate to colleagues the details of calculations on which their analyses were based. The integration of processes associated with IT looks like a management of interdependencies (Rockart & Short, 1995) by which an actor becomes a prescriber for his colleagues. As a consequence, the political perspective in terms of power distribution misfit appears to be primarily applicable for cross-functional IS (Markus, 1983) like enterprise systems.

Actually, conflict types are not exclusive, as they can occur simultaneously and have mutual influence. For example, Munster (2007) analyses the presence of simultaneous inter- and intra-group conflicts and observes that when the intra-group contest becomes less decisive, there are more inter-group conflicts. According to the avoidance theory (Knowles & Linn, 2004), a person can be simultaneously for and against change. For instance, somebody is likely to have a task-oriented acceptance of an IT project and, at the same time, a socio-political conflict by perceiving some unfair threats and abuses. Thus, resistance turns out to be a complex behavioural process. Manifest conflicts in organisations result largely from value, power or status factors that originate outside the particular lateral relationship under consideration or which antedate the relationship (Thompson, 1960; 1961; Walton et al., 1969). In the same vein, MIS literature based on the interaction theory (Joshi, 1992) suggests that the fundamental reasons of resistance toward IT systems are not the ones expressed about the system, nor personal characteristics, but users’ perceived values and social content gain or loss before/after system implementation (Kendall, 1997; Jiang et al., 2000a). Indeed, advocating system inconsistencies or organisational misalignment is probably a more comfortable resistance strategy than the one consisting of expressing underlying individual socio-political challenges. In this research, we assume that users having socio-political oriented conflicts related to IT projects are likely to use a bypassing strategy and to express only task-oriented conflicts. Following this reasoning, we formulate the following research proposition:

Proposition 1:

  • Task-oriented conflicts expressed toward IT to be implemented may hide socio-political oriented conflict.

Conflict management styles

IT projects can rarely be properly completed without implications of the CEO. Often, top managers appear as ‘sponsors’ of the project in order to promote its credibility toward employees (Davenport, 1998; Markus et al., 2000a, 2000b). A CEO should be able to balance the choice that must be made between satisfaction of individual expectations and the general objectives of IT projects. Sillars (1980) distinguishes three common conflict resolution approaches: The integrative approach aims to identify and achieve outcomes perceived as satisfactory to all team members. The distributive approach tends to assert outcomes that favour some persons only. The avoidance approach concerns managers not intervening in the conflict and relying rather on the team capability to self-resolve the conflict.

Burke (1970a, 1970b) identifies five different management styles concerning conflict resolution. These conflict resolution modes have been validated and used in many management and IS projects (Marciniak, 1996; Barki & Hartwick, 2001), as well as virtual teams (Kankanhalli et al., 2006). We decided to adopt these five conflict resolution styles (see Table 2).

Table 2 Management styles of IT resistance
Full size table

Previous studies have demonstrated the preference of IT users toward collaborative resistance management methods in opposition to direct management methods imposed by managers (Robey & Taggart, 1981; Ives & Olson, 1984). According to Montoya-Weiss et al. (2001), integrative and distributive approaches appear to facilitate team performance, whereas the avoidance approach seems to hinder it. In her longitudinal study of 24 IT projects Marciniak (1996) found that the avoidance approach was inefficient and ineffective. However, she also noted that when the stakes were not so important, this management style could be recommended. In their empirical analysis conducted on IS staff and future users of 162 IS projects, Barki & Hartwick (2001, p. 218) observed asserting mode and avoidance management as being associated with negative results in terms of interpersonal conflict solving. In other words, the two most opposed styles were considered to be inefficient techniques.

At the same time, the authors indicate that negative emotions involved by interpersonal conflicts are not only negative experiences, but negatively affect IS project outcome and remain pervasive, even when properly resolved (op. p. 220). However, resistance management styles cannot be considered to be exclusive. MIS literature shows that in function of the project budget, the delays, the evolution of employee perspectives, etc., project managers are likely to change their style several times during the project duration. For instance, Gibson (2004) describes how during an ERP implementation project at Dow Corning corporation, resistance management style evolved from an ‘improvisation approach’ to ‘big bang’ assertions. To a large extent, IS literature invites managers not to remain passive (Leidner & Kayworth, 2006, p. 381) and to solve users’ resistance by identifying conflict situations in order to prevent a project from evolving negatively. Similarly, some empirical studies observe conflict situations that are self-managed by team members to be linked to conflict reduction (Kankanhalli et al., 2006) or team performance improvement (Jehn & Mannix, 2001). In other words, there is no evidence that, depending on the context, a management style relying on teams’ self-ability to resolve resistance would not be suitable. Because these observations have been limited to task-oriented conflicts, we expand the corresponding assumption to socio-political oriented conflicts.

Proposition 2:

  • Avoidance management style can produce positive results in the case of socio-political oriented conflict.

Our literature analysis, based on psychology and sociology theories, puts forward some relationships between resistance and conflict, whereas IS literature separately develops related theories. Simply contrasting and comparing both concepts would reinforce this ‘isolationist tendency’. Instead, we propose an integrative approach articulating resistance and conflict related to IT implementation as a comprehensive theoretic system. We call it ‘IT Conflict-Resistance Theory’ (IT-CRT), for which the main considerations can be summarised as follows:

  • Acts of resistance indicate the way conflicts are expressed. In this sense, resistance is a behavioural dimension, whereas conflicts are indicative of attitudinal beliefs toward IT to be implemented.

  • Conflict types related to IT are not exclusive and can overlap.

  • Users may resist IT implementation by expressing only one part of the related conflicts.

  • One challenge for managers is adopting conflict management styles enabling identity of non-expressed parts of the conflicts.

This IT-CRT served as a theoretical basis for the action research conducted at Netia corporation. At the same time, the practical settings facilitated informing theory. This cyclical action research explores employees’ resistance and conflict situations that were behind the preliminary phase of ERP implementation when managers decided not to intervene.

Case description

Netia is a French corporation and one of the worldwide leaders in broadcasting (40 countries covered). Its customers are TV channels and radios such as BBC, ABC, Rai uno, Canal+, France Télévision, etc. Created in 1993, the company employs 100 persons spread over two sites in France and several subsidiaries abroad (Amsterdam, Liège, Rome and New York). The firm is an IT service agency dealing with development of audio and video data digital solutions. Apart from IT development, Netia offers implementation management services (consulting, process analyses, engineering, training, maintenance and evolution of audio and video data digital solutions). The firm has two types of IT people: those in the core business of the firm and those in the IT dept (support process). The IS of Netia have been developed progressively by ad hoc initiatives. These isolated and independent developments have involved a lack of data coherence as well as an excessive growth of applications. Consequently, many employee tasks were dedicated to re-typing data in order to feed all redundant applications implemented to respond to local needs. For example, the finance department developed a set of Excel macros to partially deal with SAGE accountancy software. Each process (order forms, delivery forms, etc.) corresponded to a data entry for one or more shared Excel files (on the server there is a file for the order forms, another for the clients, another for prospects, etc.). The IS was structured around a huge quantity of office files from which data were manually extracted and aggregated into other files to produce the performance indicators required by managers. Thus, a loss in productivity was raised because of repeated data entries and redundant procedures. The lack of IS integration was also highlighted by data access problems. For example, the project coordinator did not know the status of customer orders in progress. He had to contact the logistic department manager who had to browse the SAGE database to communicate needed information. Transaction histories were dispersed throughout several isolated applications and purchase tracking was hazardous to carry out. Customer invoices were not automatically triggered by a delivery note, and the logistic staff had to find the account number in a shared Excel file in order to edit the invoice.

Due to these inconsistencies, administrative employees asked for the implementation of an ERP to ensure a more coherent and efficient management of daily tasks. The solution of one of the leader editors was to select and implement three modules: accounting, customer relationship management and Human Resource (HR) management. However, the project was suspended because the computer department employees were opposed to this ERP system solution. Several meetings, self-organised by partisans and non-partisans of the projects, turned out to be unsuccessful, and a conflict between the two categories of employees arose. Thus, this case study was consistent with our research objective and represented an opportunity to observe how acts of resistance were likely to evolve when depending on choices and decisions to be made regarding the ERP implementation.

Research design and results

In general, conflicts in organisations evolve over time, which justifies the higher adequacy of process analysis over static analysis (Jehn & Mannix, 2001, p. 239). Because our research propositions were difficult to access in a quantitative manner, qualitative analysis was deemed particularly appropriate for examining resistance and conflicts toward IT project during the pre-implementation phase. First of all, to evaluate the ability of users’ groups to solve the conflict by themselves or to find a compromise, we had to find a firm whose managers adopted an avoidance management style. There was interest in using a single case delivering an illustrative story (Benbasat et al., 1987). At the same time, one risk of such a ‘self-managed conflicting situation’ was having to deal with a ‘dormant project’ and long stagnation periods before observing any significant behavioural evolutions. In other words, we needed a research configuration that allowed us to stimulate the project in order to observe how conflicts evolved that depended on the solutions proposed to users and employees.

For all these reasons, we decided to use an ‘action research’ method to analyse the selected case study. While some authors consider action research to be positivist (Clark, 1972; Klein & Myers, 1999, p. 69; Pare, 2004), usually the methodology is seen to imply an alternative conception of scientific criteria (Susman & Evered, 1978, p. 594) and is presented as a critical or interpretative social research method (Klein & Myers, 1999) that is ideally suited to the study of technology in its human context (Baskerville & Wood-Harper, 1996, p. 235). Although previous action research publications have been extremely rare in major North-American academic reviews (Orlikowski & Baroudi, 1991), the method is now popular and largely accepted in IS research (Baskerville, 1999; Baskerville & Myers, 2004).

Additional motivations to use action research methodology were linked to the characteristics of Netia Corp. Indeed, the company was eager for recommendations on IS project management from a research point of view. Moreover, the firm was medium-sized and had a short budget concerning this project and could not afford to buy the services of a consulting agency. Even if other methods could have been used to analyse our research object in its natural context, action research was the most appropriate because of its interventionist approach dedicated to the development of knowledge useful to research and practice (Susman & Evered, 1978). Researchers can exploit empirical data collected that are relevant to their publication activity, and practitioners can take advantage of researchers’ recommendations or experimentations. Indeed, action research considers that it is unhelpful to study a real-world problem without assisting its solution (Lindgren et al., 2004, p. 441).

However, several action research methods exist and provide a portfolio of different techniques used in IS research. In their review on the pluralistic forms by which the methodology has been used in IS research, Chiasson et al. (2009) make the distinction between the research dominant approach and the problem-solving dominant approach (p. 39–41). The research dominant approach focuses on theoretical ideas that inform one or more problem-solving situations. Researchers who use this approach posit that IS theory can inform the class of problems with which the organisations studied are confronted. As a result, problem-solving activities are used to confirm or invalidate the applicability of theoretical knowledge related to the practical problems analysed. Here, some comparisons could be made with a hypothetical deductive approach of empirical analysis. Conversely, the problem-solving dominant approach could be viewed as more explorative in the sense that it focuses on insights that can be induced from problem-solving activities. After the problem of the firm studied is resolved, researchers use data issued from their problem-solving activities to compare and contrast with existing IS theories, or to develop new theoretical knowledge in later-stage research activities. Thus, our investigation at Netia appears more like a problem-solving dominant than a research dominant approach.

When we started our action research mission, we had no idea about preconceived hypotheses that could have been formulated to assume the causes of the conflict with which the firm was confronted.

A first challenge for us was to understand why some employees had disapproved of the ERP project, since they were not apparently directly concerned by its use. To avoid any potential conflicts over each party's contribution and role, an agreement specifying the responsibilities of the researchers toward Netia was concluded with the CEO (two co-fundholders of the company). According to this agreement, researchers were expected as a source of recommendations about the solution to implement. The firm did not have to allocate any specific financial or material resources. On the other hand, managers agreed to allow researchers to use data collected for academic publications. Our investigation lasted over 2 years, during which time we were involved with the project team (five Netia employees: three from administration departments, and two project managers of the Computer Department) as ‘external experts’ on the base of 1 day of work per week.

Among the portfolio of action research methods, the research design of Susman & Evered (1978) is one of the most widely adopted in social sciences (Davison et al., 2004; Lindgren et al., 2004, p. 441). The authors consider (p. 588) the method to be a cyclical process in five steps: diagnosing which consists of identifying the firm problem to solve, action planning of alternative course actions to solve the problem, action taking corresponding to a course of actions selection, evaluating the consequences of actions and specifying learning of general findings induced from the cycle. The overall process of our action research followed an iteration of three cycles (see details in Table 3) corresponding to key steps of the IT pre-implementation phase.

Table 3 Research process and synthesis of results
Full size table

Our investigations at Netia ended when the selected application was installed on the server. At a meeting a few months later, it was reported that the new IS of Netia was now considered as being properly used and that initial conflicts were considered to be resolved. Thus, we found it suitable to stop our iterations because additional investigations beyond this point would not have provided further insight into understanding conflict resolution during the pre-implementation phase.

When we started our investigation at Netia, a first preoccupation of the CEO was to address resistance expressed toward the ERP project. Indeed, the firm had failed formerly to implement other business IT solutions, and top managers were quite disillusioned concerning the new conflicting project. Moreover, a paradox concerned the business activity of the firm, that is, Netia was a high-tech medium-sized corporation whose core activity was IT application development. In other words, the firm tended to be unable to implement applications comparable to the one it was developing and selling. Our research project was a 19-month collaborative study with Netia corporation, especially with the CEO and the IT project team. The three cycles of result iterations presented needed to be considered as an a posteriori articulation constructed from the key project phases observed. All data collected were collaboratively debriefed and discussed in several sessions involving both researchers and Netia managers. Table 3 presents a global synthesis of our research action, based on Susman and Evered design (1978).

Cycle 1

Design

The objective of the first cycle (January–November 2005) at Netia was to identify explicit and tacit conflicts related to the ERP implementation project. This problem-solving dominant approach (Chiasson et al., 2009) was explorative and consistent with thematic analyses in which codes were constructed inductively (Boyatzis, 1998). Even if the overall activity of the firm was highly technological, an understanding of different subcultures was important in order to study IT implementation (Leidner & Kayworth, 2006, p. 358). It was relevant to analyse how the co-existence of subcultures had influenced conflict situations that involved the IT project rejection. Among sources used, a brainstorming session with key actors associated with the project (11 persons from most of Netia departments) was expected to categorise conflict items in function of their influence level toward the ERP implementation and subcultures. In line with our literature analysis, we focused on concerns expressed toward the system as a potential way to identify underlying socio-political oriented conflicts.

In terms of action taking, researchers here played a role of animators using the ‘change session’ method of Kourilsky (2008). On the flip chart, each department manager had to draw a process map of the activity for which he had the responsibility and to self-evaluate processes that needed to be improved. On the basis of the documentation formerly delivered by the ERP editor solicited, the animator stated on a flip chart the changes involved by the ERP, the advantages and drawbacks. Then all participants were asked to evaluate in which respect the project was in line with the self-evaluation that the employee had made. During this time, the second researcher noted the comments, discussions and non-verbal attitudes of participants. This data analysis allowed the identification of several task-oriented conflicts across Netia departments but failed to get a consensus on the blocking ones. Indeed, we perceived team members as being reluctant to collectively evaluate the influence of each resistance category; some were specific to a group of employees and associated with their professional culture. Later, we understood that collectively mentioning this resistance as the ‘bottleneck’ of the ERP project was partly perceived as indirect ‘denunciations’ of some colleagues.

Despite the misconceptions, this brainstorming session allowed us to identify two main categories of employees opposed to the IT project: the computer department employees on one side (developers and project managers) and administrative employees on the other side (accounting, finance, logistics and sales departments). As another action taking, we conducted eight semi-directive interviews a few weeks later with key employees of firm departments initially invited to the brainstorming session (see Table A1). In order to reduce biases inhibiting the readiness of respondents to talk about the resistance of the group to which they were opposed, interviews were also conducted with administrative employees and computer department employees separately.

The interview grid used was conceived with reference to the key risk factors revealed by the literature on ERP and IT implementation (see Table A2). The interviews were realised in a one-to-one interaction with an anonymous format of response gathering. During the first part, employees interviewed were asked to select on the grid the factors they considered as explaining resistance of the ERP implementation. In the second part, we asked them to explain the causes they perceived as being associated with the ERP implementation project. Interviews lasted around 90 min approximately and were audio-tape recorded in order to avoid potential biases of only one interviewer data interpretation. We completed this analysis by several formal and informal meetings with key actors of Netia. We partially used Weft-Qda software to analyse and synthesise codes and data collected. Although the expected ranking of resistance factors was not established, we succeeded in permitting both opposed categories of employees to hint at blocking resistance associated with the ERP project. Seven categories of causes emerged from interviews and were coded and aggregated according to the five sub-dimensions of the task vs socio-political oriented conflict dialectic (see Table A3). An unexpected category of conflict emerged from both categories of employees regarding the passive attitude of the CEO toward the project and the conflict situation.

Results

The data collected during the first cycle (especially during the initial brainstorming) allowed, as specifying learning, the identification of two distinct groups of employees opposed to the ERP project. The ‘partisans’ group’ (15 persons) was composed of administrative employees from accounting, finance, logistic and sales departments, of which most had graduated from Business Schools, and had no experience of high-tech activity before being employed at Netia. Their activity was focused on commercial and managerial effectiveness. The ERP project was the initiative of one manager of this group, and expectations concerning business improvement were shared by the rest of the group. The ‘detractors’ group’ was undersized (eight persons) and was composed of only computer department employees (developers, designers and project managers), all of whom had graduated from engineering schools and had a strong culture on data processing that focused on efficiency of IT application development. Most of the employees were members of open source communities. Their expertise in IT conferred upon them a sort of non-official authority about applications that could be considered as being technically suitable (regarding interfaces with existing applications, user-friendliness of the application design, etc.), and their approbation was considered as a necessary prerequisite to any IT implementation.

The conflict situation between the two groups was consistent with prior studies that showed that cultural differences within organisations tend to influence contrasting interpretations of IT to be developed (Dube, 1998; Ngwenyama & Nielsen, 2003) or to be adopted (El Sawy, 1985; Robey et al., 1989; Cabrera et al., 2001). We identified two categories of task-oriented resistance expressed by the ‘detractors groups’.

Conflict regarding the system. The ERP application that had been presented was poorly perceived from a technical point of view, that is, the system design showed main criticisms to be about interfaces and screen captures of the ERP. These complaints were essentially formulated by two designers. The following declarations were recorded during the brainstorming session:

ERP libraries are not standard libraries of the operating system. For instance, keys, text zones, forms, etc. were recoded. As a consequence, interfaces are specific and not harmonized with those classical software users are used to. Moreover, this sort of ‘reinventions of the wheel’ involve over-sized softwares to be installed and to be loaded both on the server's side and client's side. (A developer)

As for me, I prefer the way the applications we develop are designed. Our softwares are considered as very ‘sexy’ by customers whereas they are very sophisticated. Indeed, we succeed into developing graphical and visual interfaces allowing users to intuitively understand the way the application must be used. (A designer)

The ERP presented looked like ‘smokestacks’ with plenty of keys and drop lists. Users were forced to do anything with the mouse. Several functions could not be activated with shortcuts. So, if they do no not have a mouse, they cannot do anything …. (A designer)

I have been very surprised when browsing a few web pages generated by the ERP. I checked if the pages were identically displayed with Internet Explorer and Mozilla. Some objects were depreciated with Mozilla. Then I browsed the HTML source code. Actually, the pages were not W3C validated! I thought to myself, how such a several thousand Euros’ software cannot be consistent to such fundamental standards? (A developer)

Conflict about new professional skills required regarding the way the ERP needed to be implemented and maintained on servers was addressed mostly by two project managers. The following declarations were recorded during the brainstorming session a few moments after the aforementioned resistance:

For ages, our database has been a Sage database. Suddenly there was question of implementing an ERP and migrating all data storage on an Oracle or an SQL server database. Initiators of the project totally neglected the difficulties, and the time required to carry out such a migration. Why implementing an ERP not able to communicate with the existing Sage database? (A project manager)

Moreover, implementing the ERP asked us to develop new abilities for managing the new database on our server. Anyway, even if maintenance service was planned with the editor, I know how this sort of options would have been avoided. Indeed, any-time a technical problem would have occurred, the editor would have billed the services. Grudgingly, managers would have discovered over-expensive additional costs and would have asked us to directly fix the problems. (A project manager)

However, additional discussions with the project team encouraged us not to consider these task-oriented resistance as sufficient reasons for the ERP abortion, that is, several questions remained without responses:

  • The criticisms were expressed by computer department employees and not by key users. Thus, why was there such resistance toward a software design that they were not likely to use?

  • The second problem related to the new skills required by the ERP database management. Why had the negotiations not been focused on this point, instead of rejecting the whole project?

  • While developers poorly perceived the way the ERP presented was designed, they were not ready to internally develop an equivalent application in line with their own expectations; nor did they want to look for another ERP that would be considered as more suitable (like an open source solution for example). Why was this?

Later, individual meetings allowed us to grasp that what was perceived as a task conflict was hiding a conflict of power between the computer department employees and administration employees. The data collected revealed that the project was perceived as putting into question the autonomy of the computer department. To be more specific, programmers represented a key competence asset for Netia, and the broadcast software applications developed by the company were not just standard package applications that could be bought on the market. Consisting of solutions billed for several hundred thousands of euros, these programmes ensured storage, management and broadcasting of audio and video programmes for TV and radio channels. Therefore, very specific skills were required regarding sound, image, storage (on servers of several terabytes), and data broadcasting by Hertzian, satellite or 3G transmissions. The programmers represented a rare workforce on the professional market, which gave them a strong negotiation power with top managers. Thus, over time, they had gained strong independence in the way they organised their work. An administration coordinator described the example of holiday management: The programmers are used to freely organize their work depending on tasks and assignments to be completed. They do not really respect the process for taking holidays. Instead of filling out the holiday sheet and having it validated by managers, the requests (when they are made) usually take the form of an informal conversation. During an additional discussion with several computer department employees, we noted the following declarations:

I fix my own objectives! (A developer)

We develop scientific softwares! So, for each project, we need to invent innovative algorithms based on mathematical equations in order to optimize data transmission to a mobile phone or to a TV set with Internet bandwidth. Our job is not about simply typing pre-formated coded pages, and one cannot demand somebody to be an innovator from 9:00 AM to 6:00 PM! (A project manager)

Each time I have an idea to solve a technical program, I must immediately type the corresponding code to test it. Our job is very engrossing. So we are used to working in the evening and even during the week-end. On the other hand, top managers understood how we work and say nothing when one Monday I decide to stay at home. This is trust and it works better than electronic forms to fill …. (A developer)

The formal processes that an ERP HR module would have involved was perceived by computer department employees as a threat to their ad hoc processes and their autonomy. In other words, they related toward the project not only as technical experts, but also as ‘end users’ would have done. Beyond the ‘spy eye’ syndrome, they considered the ERP as putting into question the trust-based relationships they had with top managers and probably indirectly put into jeopardy their added value to the company. This observation is in line with Belasco & Alutto (1969), who considered ‘personnel administration’ as the quintessence of ‘staff-line’ problems. However, we collected no information that led to a perception of administrative employees feeling similar threats. Indeed, while programmers accomplished a results-based job requiring individual inventiveness and creativity as aforementioned, administrative employee jobs were more ‘bureaucratic’ and routinely based. Thus, they were more used to aligning their daily work to official working hours of Netia. In other words, we interpreted the ERP HR module alternative as having less impact on administrative employees than on programmers.

An unexpected cause of resistance emerged during interviews on the passive attitude of top managers toward the project and the conflict. Without being clearly aware of the underlying causes of resistance, top managers avoided any risky decisions – in the sense of Cyert & March (1963) – and adopted a passive management – in the sense of Cooke & Lafferty (1987). The CEO never interfered with the conflict situations and did not decide to impose an unpopular solution on programmers, preferring to allow employees to find a compromise among themselves. However, this avoidance style was perceived to be a frustrating behaviour to both groups of interviewees. An administration coordinator stated: If we really wanted to impose a standard solution, we could. However, this would mean interfering with the programmers. But they are the makers of the programs sold, so … . Because there has been no concrete or major prejudice due to the unreliability of the existing applications used, managers were not particularly motivated to settle this situation and to take a decision likely to disturb the social climate. Regarding the successful implementation, the management favours the programmers, only the programmers … . The rest, such as improving the organisation, is not considered as crucial.

Regarding the computer department, the CEO management style was interpreted as a disregarding attitude toward ERP challenges and the organisational changes required:

The first time the ERP project was presented, the CEO believed the main problem was being able to choose the most suitable application from a cost-based approach. When we hinted at business process management and alignment they did not understand what we were talking about. I believe one fundamental problem associated with the project is top managers was unfamiliar with enterprise systems. They created and developed Netia by selling commercial solutions specifically developed and tailored to TV and radio channels needs, they did not believed that some business softwares can force enterprises to adapt their organisation to fit to business process standards. (A project manager)

Administration employees are totally unaware of what they really need, and top managers do not understand ERP implications to decide what should be done. We have already developed several applications which have never been used. That's out of question to do the same with an ERP. (A project manager)

I have been very surprised never seeing the CEO during meetings about the project. Even when meetings ended with some strong disputes with the finance dept., I told to myself: by this way, next time they will come and they will make up their mind. And actually they never came. (A developer)

One time I was fed up having meetings about a new information system without the two big bosses whereas they are used to trigger plenty of unplanned meetings with us even for straightforward subjects about product development. (A designer)

At this time we also observed a counter-effect of the avoidance management style of the CEO. If the initial objective was not to impose an unpopular solution to one group, both groups of employees perceived it as a neglect. We thus considered resolving the identified socio-political oriented resistance as not being an automatically sufficient condition for the project completion. The conflict management style applied by the CEO also negatively influenced the situation, and top managers had to adopt a more active attitude concerning decisions of the ERP implementation project.

Cycle 2

Design

The second cycle (January–February 2006) was an intermediate phase in the sense that its objective was about decisions to make according to conflicts identified during the first cycle. We played more a research dominant approach (Chiasson et al., 2009) by using, as a first source, literature on ERP implementation success factors (Hong & Kim, 2002; Hsiao-Lan et al., 2005), and more especially articles in which leadership and sponsorship that CEOs played an important part during projects to support achievement and ERP acceptance by users (Davenport, 1998; Markus et al., 2000a, 2000b).

In terms of action taking, our first contribution was establishing a risk analysis of the ERP implementation option. To carry out this analysis, we partly used the list of risk items and risk resolution actions used by Iversen et al. (2004) in their action research on software process improvement (see Table A4). This approach is considered to be suitable to identify risks, both at organisational and managerial levels (op. p. 401), and were presented to the CEO and administrative departments in order to make sense about the ERP implementation challenges. We organised a first meeting session with the CEO to define prioritising strategies according to the risk list established and to decide whether an ERP or a less impacting IT had to be implemented. On the basis of this revised project scope, a second meeting occurred with administrative and computer department employees. On a video screen we displayed the process map initially established during the first cycle and prioritising process improvements. We then asked participants to state whether their main expectations were satisfied with this new project definition and whether additional objectives should be considered. During the meeting, the comments, discussions and non-verbal attitudes of all participants were noted. As a result, this cycle ended with a consensus concerning the new project definition and the delivery of a bid book to the CEO.

Results

The risk analysis we presented to top managers during the second cycle of our action research (see Table A3) aimed to support the ‘go or no go decision’ to be made regarding the ERP implementation. The underlying challenge was to perceive whether the CEO was now ready to impose the ERP on the computer department employees and more actively manage resistance identified.

During the first meeting, top managers were surprised by our risk analysis and declared being concerned about the many problems associated with the project. We had evaluated as risky 15 items of the 22 selected from that of the Iversen et al. (2004) list (see Table A4): six of nine items concerning the project area; all five items about project idea and four of eight items related to the project process. This risk analysis put forward problems involved by resistance we had identified during the first cycle, as well as project management weaknesses. In terms of action taking the CEO preferred, in line with our recommendations, abandoning the ERP solution for an application perceived as being less impacting for organisational purposes. As main specifying learnings of this cycle, top managers recognised that they underestimated what the business process transformation implied and were more worried about preserving the social climate with developers than about the lack of integration of the IS. Indeed, when top managers were asked to define prioritising strategies, they agreed to focus on product innovation and research and developments: activities for which a full implication of developers, designers and project mangers was required. Developing a more efficient IS was also expressed as a strategical issue, but the problem was more about balancing both challenges, whereas the second one was perceived as affecting motivations and trust of the computer department employees:

Good relationships with our developers are crucial. They represent the core competency of Netia. Each time one of them resigns, recruiting somebody with similar competencies takes several months. Because of competitiveness, we cannot afford having a turn over affecting development process quality or delaying services’ deliveries to customers. (A top manager)

Regularly I have meetings with programmers and designers to control if everything is fine for them. I know they are coveted by competitors that try to recruit them. So, despite salary, we are forced to indulge some of their demands. (A top manager)

Instead of totally abandoning the ERP solution, an intermediary solution would have been to implement the ERP without the HR management module associated with autonomy threats of computer department employees. Only accounting, finance and sales’ management modules would have been considered. However, this alternative solution was also rejected for two reasons:

  1. 1

    First, the ERP project experience suffered from a bad image, and keeping the decision of implementing it would have involved a risk of resistance path dependency.

  2. 2

    Simply implementing one or two modules of an ERP was likely to be perceived by the computer department employees as a first step of an underlying strategy aimed at grudgingly implementing additional modules for a more controlled activity.

Thus, we recommended to the CEO to redefine the project with a narrower scope that focused on accounting and customer management, and HR management was eliminated from the project perimeter. A meeting was planned with administrative employees who were asked to choose only two or three functionalities strictly considered as being urgent to gain significant performance improvement. Most discussions were about the under-usability of the Sage database and about possible extensions of its functionalities. Functionalities concerning HR management were abandoned and only envisaged in the long term. As a result of this cycle, a new project definition was written and an invitation to bid was sent for commercial propositions.

Because we played a research dominant approach during this cycle, we must state how the actions informed the theory used as a driver. The risk resolution actions of Iversen et al. (2004) are mainly based on the risk theory and the socio-technical change model of Leavitt (1964). Applied to IT development, this model categorises risk frameworks with four key elements: task, technology, structure and actors (Lyytinen & Mathiassen, 1998). The way the risky incidents associated with the ERP project shaped the attention of managers confirmed the four elements as being strongly related (op. p. 238). The business task improvement objective of the project (task) targeted by the ERP solution and the HR module (technology) turned out to be inconsistent with the behavioural pattern of computer department employees (structure). As a consequence, managers were afraid of the consequences of key employees’ dissatisfaction and potential turnover (actor). In terms of risk resolution strategy, the project redefinition strongly corresponds to the ‘adjust mission’ type of Iversen et al. (1996, p. 416). At the same time, our results enrich the typology of the authors by putting forward how the resolution strategies they distinguished may overlap. Indeed, the new IT project perimeter of Netia can as well be interpreted as a ‘modify strategy’ type. While it was possible to exclude the HR module only, the CEO decided to abandon the whole ERP alternative because it was perceived by computer department employees as a solution related to an unofficial ‘spy eye strategy’ of the management. Instead of claiming the official strategy to be associated with the IT project, the challenge was to adjust the mission in such a way that developers would be less able to make sense of such an assumption. Here again IT choice was used as a ‘bypassing strategy’.

Cycle 3

Design

A third cycle (April–September 2006) was conducted when, after several invitations to bid, a package editor, Genesys Corporation (Genesys Corp.), was asked to present its software. Using, as source, professional offerings provided by editors solicited and direct observation, the objective for us was to evaluate resistance toward the new IT solution selected. Then, like during the first cycle, the approach used was a problem-solving dominant one (Chiasson et al., 2009). The presentation was done in front of the Netia employees concerned with the IS implementation (see Table A5). We took advantage of being invited to this meeting to analyse employees’ direct reactions. To avoid any suspicions of the editor regarding our presence, Netia managers introduced us as academic researchers interested in IT solutions for firms without any role to play concerning the decision to be made. Because of the confidentiality of the commercial offer of Genesys to Netia, we were not allowed to record the discussions. As a consequence, we were not able to do the same qualitative analysis as the one of Cycle 1. However, the observation method we used was consistent with Yin (1994), who considers this technique to be an additional source of data useful to understand the social context of the firm. To control the risk of instrumental biases involved by observational methods (Weick, 1968), both authors attended the meeting and aggregated the data collected. The meeting lasted 3 h and took the form of a presentation and discussion about the software functionalities. Seeing directly on the screen the usability of the software, participants were able to ask questions during the presentation. This type of interaction allowed us to note verbal and non-verbal users’ behaviours. Additional discussions with the CEO, administrative and computer departments, and Genesys engineers occurred to decide on the modules to be implemented, users’ training to be planned and the main technical choices to be implemented (hosting server, database migration, network architecture, etc.). Specific meetings were organised with administrative employees to support organisational changes to carry out before the Genesys application implementation. Main changes concerned accountancy, treasury, sales force and customer support. As a result, this cycle ended with the delivery of the process map specifying the organisational changes involved.

Results

The action taking part of this cycle lasted 6 months because of the time required to receive and select consistent offers from editors. The firm invited to bid seven editors that focused on small and medium enterprises and received six commercial propositions. We analysed each proposition in terms of ‘pros and cons’ concerning five different dimensions: costs, functionalities, IT design, interfaces with existing database and additional services.

Among the commercial propositions received, the project team perceived Genesys application to be the most interesting alternative. Its functionalities covered most salient needs of administration employees: customer and potential customer management, sales and procurement management (quotation, order and invoice tracking, treasury, after-sales management, etc.). Further, the application was focused on the process management of administration employees without implying cross-functional processes. In other words, the software could not be considered as an integrated IS, forcing programmers to cope with badly perceived tasks like reporting their daily work or filling out electronic forms to have a day of rest allowed by the managers. Moreover, it was inter-operable with SAGE application and did not require data migration from the existing database.

During the presentation meeting we attended, both computer and administration representatives found this new solution to be satisfactory for the needs previously expressed (during Cylce 1). The application was supposed to be only used by administration employees. Computer department employees only made remarks and asked questions about technical aspects of the software. Some allusions to the previous recalcitrant behaviours of developers about the ERP solution were expressed with irony and the general laughing reaction allowed us to observe an alleviation of the initial conflict between administration and computer department employees. Among key discussions expressed in this sense, we noted the following:

The finance director to computer department employees. ‘(…) So now you can be quiet. With this software you will not be spied (laughs) and moreover you will not have to fill any electronic form! We know that programmers are used to developing electronic forms but have an allergy when they have to fill one (laughs)’.

Reply of the computer department Head: ‘We have no allergy, just some itchings (laughs)! As for us we have nothing to hide. We are not like you, when we leave Netia in the evening, it does not mean we are no more working. So, controlling our professional activity, would imply controlling our activity at home’.

In other words, as main specifying learning of this cycle, we considered the ‘bottleneck conflict’ was socio-political oriented and not task-oriented.

Despite the general positive impression regarding the application, an active form of resistance appeared a few minutes later when conversations converged on the required task reconfigurations. For example, because of his frequent travels abroad, the Asia commercial agent of Netia mentioned some practical problems not treated by Genesys functionalities. This employee was used to typing a text file to which he added complementary information and comments about potential customers. Then, he uploaded the file on the Netia server in order to make it available to other employees. But the customer management function of Genesys software did not allow joining complementary files such as these. He thus first considered this as an annoying limit of the application, and then the discussion moved to how to overcome this problem until one programmer noted that it was more related to the task definition than the software appropriateness to user needs. Actually, Netia employees were used to including in ‘transaction’ concept all upstream processes to the order (quotations, bargaining, etc.), whereas with Genesys software, those tasks were included in a functionality other than the one talked about. Actually, the resistance expressed during this step were essentially because of ambiguity in the professional jargon between Netia and Genesys corporations.

A few minutes later, another active resistance was raised while Genesys engineers were presenting the treasury management function. The Finance Director was reluctant to use this function because she considered it to cover only a minor part of the activity. According to Netia practices, she revealed that on-going payments of invoices sent to customers were included in treasury while not yet cashed. If this practice may sound inconsistent with accounting classical rules, it sounded consistent with Netia business practices. Usually, the recovery rate of customer debts is 100% and paid immediately when the invoice is received, and any invoices sent to customers are considered as existing cash. However, at the end of the meeting, all employees agreed on the global adequacy of Genesys software for Netia needs, and only task-related oppositions remained and were resolved. As a result, at the end of the year, the decision was made to implement the Genesys solution and the software was bought. At this time, we considered the Netia project to be beyond our initial mission and we decided to end our action research.

Discussion

Action researchers look for sense making with practitioners by using active investigations and interactions about a particular problem situation. Then, depending on epistemological postures, action research leads several limitations and pitfalls (Baskerville & Wood-Harper, 1996) like the lack of neutrality and discipline of the researchers, the consulting-like approach, the strength of the context-dependency, etc. However, our research puts the emphasis on in-depth research, vs cross-sectional data collection, to analyse the dynamic nature of conflict and users’ resistance during project steps prior to the IT implementation. We believe that researchers should consider this ‘upstream resistance’ such as exploring additional influencing factors of IT adoption in order to expand existing theoretical models.

We used a French corporation case study to observe how users’ resistance and conflict situations associated with an IT implementation project evolved over time. Therefore, we cannot claim any generalisation of the results, such as we would have if we had used several case studies or sample quantitative analysis. We thus recognise the limitations of this research. First, during the first step of analysis, data were mainly collected through interviews that could have induced some interpretative biases on the feelings expressed by interviewees. However, we tried to reduce these concerns by interviewing several employees of each department, comparing the data collected by each researcher, adding informal meetings, etc. Second, during the second step of analysis, data were mainly collected through observation techniques during the Genesys presentation to Netia employees. Our presence might have influenced the way persons behaved and participated during the meetings even though we were presented as playing no authoritarian role on the decision process of the IT project. Moreover, an inherent limitation of longitudinal research is that the processes observed continue to evolve after the end of the research investigation (Volkoff et al., 2004, p. 302). Further research should be done in order to examine findings in other cultural, structural (large firms), professional and organisational contexts to give a deeper understanding of users’ resistance and conflicts during a longer longitudinal research that encompasses the whole IT project life cycle.

Nevertheless, by exploring conflict evolution during the pre-implementation project phase, our results informed theories related to IT users’ resistance research. First, task- and system-oriented conflict expressed during Step 1 hindered socio-political conflict related to the autonomy threat perceived by developers – thus, our Proposition 1 is confirmed. This observation is consistent with previous studies done on cultural and power conflicts associated with IT implementation (Markus, 1983; Hart & Saunders, 1997; Jasperson et al., 2002; Kohli & Kettinger, 2004; Leidner & Kayworth, 2006) and is in line with recent investigations of Ford et al. (2008) who observed that emotional conflicts can dominate task conflicts in organisations. These observations illustrate that IT employees are mainly rewarded for delivering technically sound systems on time and in budget, and are not really encouraged to consider organisational issues in IT systems (Hornby et al., 1992, p. 165).

Second, acts of resistance moved from an aggressive form (observed during Cycle 1) to a constructive form (observed during Cycle 3) that led to the implementation of an alternative IT solution. The evolution showed that conflicts are not fixed and our results are in line with the observations of Jiang et al. (2000b, p. 32) who observed that causes of users’ resistance differed according to the IT type to be implemented. Our investigation illustrates how a socio-political conflict related to IT has been solved during these preliminary phases while top managers adopted an avoidance management style. In this sense, the Netia case study does not support the conclusion of Barki & Hartwick (2001) and Marciniak (1996), who observed avoidance management style as associated with negative results in terms of conflict solving. Our results are in line with the attribution theory (Cramton, 2001) and some empirical studies, which show that conflict situations managed by team members are linked to conflict reduction (Kankanhalli et al., 2006) or team performance improvement (Jehn & Mannix, 2001) because of trust, respect, open and consensual discussions. These studies have been conducted mainly on task-oriented conflicts, whereas our observations extend the results to socio-political conflicts that are considered as being more difficult situations that managers prefer to avoid to be involved in (Edmondson & Smith, 2006, p. 25).

We can consider these practical settings as informing the IT-CRT theory initially proposed (see p. 6). However, we do not consider the avoidance management style to be a sufficient factor of the conflict resolution at Netia. Indeed, several elements, such as the firm culture, its flattered structure, the implication of key actors in the IT project, their acceptance of a consensus, etc., play a significant role. We could consider that the avoidance management style was successful because of its consistency to the Netia organisation. At the same time, because our longitudinal observations deliver the story of one conflict management style, we cannot assume the effects that other conflict management styles would have had, and we cannot consider any intrinsic superiority of the avoidance style on other styles.

Moreover, because of the role we played on behalf of the CEO for the duration of the project, we can question the managerial passive attitude initially assumed. At Netia we undoubtedly played an active role as action researchers and we cannot assume how the project would have been completed without any mediating intervention. In other words, even if top managers had adopted an avoidance style, we could consider the resolution mode evolved to be a more compromise-like approach. At the same time, even if this passive conflict management style was perceived as being frustrating by employees, it undoubtedly favoured their resistance expression. A more asserting management style would have probably constrained employees attitudes and behaviour toward the project, and it would have been more difficult, during Cycle 1, to perceive tacit causes of resistance. However, the contribution of the avoidance management style to the conflict resolution turned out to be limited to this first analysis phase. Indeed, the decision process about the IT to implement (Cycles 2 and 3) required managers to switch to a more compromise-like style. In this sense, our Proposition 2 is only partially confirmed. These observations invite us to consider the effectiveness of passive vs active conflict management styles as not being exclusive, but as dependent on the way they are combined during the project. We invite researchers to conduct additional empirical analyses on complementarity and synergies of conflict management styles instead of carrying out classical individual performance assessments and comparisons.

We observed also an unexpected cause of resistance that we had not identified in the literature analysis: the avoidance management style deliberately used by the CEO was badly perceived by both opposed categories of employees. We can consider the conflict management style used to solve conflict as an additional source of frustration toward the completion of the project. As a consequence, the relation between instances of resistance and the way to manage them should not be considered to be linear but more as interlinked or circular. This observation puts forward the complexity of the way conflicts can raise and evolve depending on the way they are managed. Such an assumption is likely to represent an important issue for practitioners and we invite researchers to conduct future investigations on this point.

Concerning MIS literature, the article expands the empirical research that observes the lack of ‘organisational fit’ as a failure cause of ERP implementation (Hong & Kim, 2002; Hsiao-Lan et al., 2005). We could consider our research as a possible extension of these results in the sense that we observed the ‘fit’ not limited to the adequacy of IT to business but covering also underlying organisational change consistency with value principles of the firm subculture units. Indeed, when an organisation is composed of several subcultures, the use of ERP can be problematic because mandating one epistemological position through the software design is based on ‘best practices’ (Wagner & Newell, 2004).

For IS practitioners, our study suggests a greater attention to issues related to power, autonomy and professional subcultures when implementing IT. The main practical implication of this article for managers is inciting them not to consider task-oriented conflicts expressed by users, as sufficient information to understand whole resistance causes related to IT projects. Discovering and understanding potential underlying relationship conflicts about users’ values or power losses turns out to be necessary before deciding on the IT to implement, and the conflict management style to adopt. While our empirical investigation suggests that an avoidance management style can indirectly contribute to conflict resolution, it does not mean that CEOs can afford to remain passive. Even if top managers do not directly intervene, relying on intermediary actors can be necessary in order to avoid a feeling of hierarchical abandonment and disinterest by the parties opposed.

Conclusion

By considering resistance to be dysfunctional conflict, IT project managers can disregard its potential contribution to the change and implementation process. As a consequence, decisions made about the IT implementation can involve systems’ usages very different from the ones expected by managers. Resistance ought to be interpreted as appeals for managerial rectifications, like restoring trust or professional recognition of employees, which should be taken into account in the design of IT to implement. While most MIS methods tend naturally to maximise users’ satisfaction and to reduce potential resistance, the IT-CRT theory developed in this article supports an alternative approach. It consists into enhancing resistance in order to anticipate and resolve latent conflicts directly or indirectly related to the project. In other words, the underlying message of this article for researchers and practitioners is to consider users’ resistance toward IT as a key process embedded into IT choices and IS design. As future investigations, we invite researchers to explore how IT project management supports task-oriented and socio-political oriented conflict identification during the pre-implementation phase resulting in a more efficient users’ appropriation of IT.