Warne, L. (1997). "Conflict as a Factor in Information Systems Failure". The 8th Australasian Conference on Information Systems (ACIS 97) 29^th-2^nd October, 1997. School of Information Systems, University of South Australia, Adelaide, South Australia. ISBN 868032581: 387-391.

Conflict as a Factor in Information Systems Failure

Leoni Warne

Faculty of Communication

University of Canberra, Bruce, ACT

E-mail: leoniw@comserver.canberra.edu.au

Abstract

This paper reports on a research study on conflict as a factor in information systems failure. A survey instrument was used to determine the extent of impediment caused by different types of conflict. Conflict among developers of the project was considered to be the least damaging to information systems projects, but conflict between users and developers and particularly conflict between different user groups was considered to be a significant threat to the success of a project. Interestingly, a small minority of practitioners are beginning to assess these types of conflict, and attempt to manage them, as part of their risk management procedures.

Keywords

Conflict, Organisational Dynamics, IS Development

INTRODUCTION

Information systems researchers and practitioners have been concerned about the high failure rates of information systems projects for almost three decades. As the industry evolves, the search for the factors influencing success and failure has intensified, but, although there may have been incremental improvements, this intensive activity has not resulted in dramatic changes to the success rate for information systems projects.

There are no studies that have yet provided the IS community with the “silver bullet” by isolating a single factor that will guarantee project success. In their comprehensive study of information systems success research, DeLone and McLean (1992) found that there was not even a consensus on how to measure information systems success, and, in fact, that there were probably as many different measures as there were studies. Furthermore, while many studies have identified factors adding to the risks of an implementation, few have provided guaranteed ways of avoiding them. Instead, there has been a growing realisation that no single factor, methodology or tool can ensure success in every situation (Saarinen & Vepsalainen 1993) and many models have been developed to help identify the risks and suggest the most suitable combination of procedures to combat them. One such model, a model of conflict showing causal relationships among participation, influence, conflict and conflict resolution was extended by Robey et al (1993) to include project success as an output variable. This research confirmed that conflict is negatively related to success. However, the model did not explore the impact of different types of conflict and how they were managed, or the perceived degree of conflict. These are the issues addressed in this research study.

Managing the power, politics and the organisational context of information systems is increasingly recognised as being of critical importance to successful information systems development (Ahituv et al 1994; Davenport et al. 1992; Kling 1993; Pliskin et al. 1993; Rouse & Watson 1994; Sauer 1993; Warne & Hart 1996). And yet, there does not appear to be a clear understanding of the extent to which these issues may impact on a project, nor the role conflict plays in the equation.

Organisational Conflict as a Factor in Project Failure

There is considerable evidence in industry and in the literature suggesting that organisational conflict is a contributory factor in many failed information systems projects, however, research on this aspect of information systems development is still scattered and largely embryonic (Davies and Myers 1994). Conflict is often referred to more as a symptom of other factors rather than examined as a phenomenon in itself. However, even if conflict is merely a symptom of development problems, it still must be examined, assessed and subsequently managed so that projects can thrive.

An information system development is often the instrument of change, and the larger the information systems project, the greater the number of people in the organisation affected by the development Therefore, the larger the information systems project, the greater the opportunity for organisational conflicts to occur and the more likely that these conflicts will impact on the success of the project. According to Robey et al (1989), by introducing an information system and changing the method of processing, the political structure of the organisation is inevitably affected. This suggests that any large or integrated systems development project would be fertile ground for the kind of conflict born of protecting one's interests in an organisation (Warne 1995). According to Hirschheim and Newman (1991) integrated systems offer many advantages, but they are also a source of much conflict within organisations, as they undermine existing power structures. Pichault (1995) hypothesises that “in organisations where the power distribution is concentrated (centripetal systems), a technologically related organisational change project will tend to be considered as a threat and will probably lead to failure”.

The conflict among users and between users and developers is often reflected in the power-base of these groups. The political process in organisations influences outcomes in terms of the way power is exercised, and this exercise of power may in itself be influenced by actions intended to change the relative power of parties in an organisation (Franz & Robey 1984; Markus 1983; Orlikowski & Robey 1991; Sauer 1993). However, conflicts of interest will not always be apparent from open, angry disagreements, or negative actions, since power relationships may be such that conflicts are never overtly obvious (Dawson 1986). Power, politics, and conflict therefore, are inextricably intertwined. This research study is an attempt to gain a better understanding of conflict and its role in information systems development.

Research Study Objectives

The research questions for this study were derived from the findings of a comprehensive case study of a prematurely terminated, intra-organisational information systems project in a large public sector organisation (Warne 1995). The research described in this paper was designed to test the wider applicability of the case study findings.

Case Study Findings

The Case Study Project operated in a climate of conflict at a number of levels: conflict among developers; conflict between users and developers; conflict among user groups defending their own divisional procedures; and conflict between end users and their managers. The major source of conflict was between senior user management and the rest of the participants with senior managers lobbying overtly and covertly to gain control for their divisions. The most surprising outcome of this study was that the project was most detrimentally affected by the impact of conflict among users. This level of conflict is often invisible to developers, and in danger of being dismissed as not relevant to them.

Definitions

The following terms were defined for the purpose of this study.

(a) Users

Users are defined to mean potential users of a system, or, anyone from the business area of an organisation who will be directly or indirectly impacted by the development or implementation of an information system. This includes managers who will manage staff using the system, staff on steering committees or other committees influencing the development, and senior managers who have some decision making power in regard to the development.

(b) Developers

Developers are defined to mean members of the information system project development team and their supporting and clerical staff, contractors from outside the organisation who may be employed to work on the development of the project; and members of the organisations information systems department who have some responsibility for the development or ultimate maintenance of the system.

(c) Failure/Success

Failure is defined in terms of the Ewusi-Mensah and Przasnyski (1991) definition of total abandonment, where a project is terminated before full implementation. This definition is consistent with Sauer's (1993) definition of failure where development of an information system ceases, leaving supporters’ interests unsatisfied. For the purposes of this study, success is limited to “non-failure” as defined above. Although this definition clearly excludes several known categories of failure and success, it means that failure and success can be objectively declared and is considered to be an acceptable limitation for this study.

(d) Conflict

Conflict is not defined for this study. Conflict can be constructive or destructive (Davis et al 1992; Hirschheim and Newman 1991; Marakas & Hornik 1996) and it was considered to be preferable to allow respondents to interpret the term as they perceived it. However, the types of conflict of interest to this study were defined to be Developer/Developer conflict, Developer/User conflict and User/User conflict and the extent of each conflict type was scaled as major, significant or minor.

(e) Overt/Covert

Overt conflict is defined to be conflict that is openly visible and not concealed. Covert conflict is defined to be conflict that is hidden or secret, often involving an attempt to change decisions by political manoeuvring and exploitation, rather than by explicit means.

Objectives

As this research study was largely exploratory, the study was designed to find answers to many different research questions which can be summarised by the following three broad objectives:

to explore the nature of conflict in information systems development and the extent to which conflict may be perceived to impact on the success of projects;

to determine which sort of conflict (from Developer/Developer, Developer/User and User/User) may pose the most risk to an information systems development; and

to determine if conflict is generally detected, managed and resolved in the information systems development environment.

Research Methodology

A questionnaire was prepared to gather data to meet the research objectives: to gauge the perceived importance of the openness of conflict, the extent of conflict observed among developers, between users and developers, and between different users or user groups; and the degree to which the different types of conflict impede effective project progress. Information was also sought on the detection and resolution of conflict. A checkbox style was used for much of the survey, with some qualitative questions included. The questionnaire was divided into two parts: the first dealing with overt and then covert conflict in the largest, delivered (successful) project the respondent was involved with, and the second part dealing with overt and then covert conflict in an unfinished or terminated (unsuccessful) project. In each of these four sections, respondents were asked to report on up to 10 different types of conflict, so up to 40 cases of conflict could be identified on each questionnaire.

The sample

Senior Information Technology managers were targeted, rather than project managers or end user managers, because they were considered likely to have more comprehensive experience and a more objective view of the issues from both the business and information systems perspectives. To limit the sample to a reasonable size and eliminate any extraneous variables, the sample was limited to Canberra-based public sector IT mangers. The ACT Branch of the Australian Computer Society provided their mailing list of public sector IT managers. This list included IT managers in charge of Federal and ACT Government departments and agencies. These managers were mostly at Senior Executive Service level, or just below it. The list was updated to reflect recent Government changes, as far as possible, by using the Government On-line Database (GOLD) at the Australian Government Publishing Service web site. There was a total of 68 IT managers targeted with the survey.

FINDINGS

Eventually 27 valid responses were received and analysed, reflecting a 40% response rate. These 27 respondents reported 393 instances, or cases, of conflict in projects with which they had been associated. A profile of the respondents experience was derived from the demographic questions: 30% of respondents had more than 20 years of IT experience and 44% had between 11 and 20 years; 52% had between 6 and 10 years of IT Management experience and 9% had between 11 and 20 years. Altogether, the respondents represented more than 329 years of IT experience and more than 187 years of IT management experience. In regard to the type of information systems projects the respondents had been involved with: all respondents had been involved with IS projects that had been successfully delivered, and utilised by the users (more than 183 projects); and 80% of respondents had been involved with prematurely terminated projects (more than 50 projects). Altogether, the responses represented experiences with more than 250 IS projects.

Analysis was conducted in two stages. For the first stage, reported on in this paper, descriptive statistics were used, although Chi-squared tests were also applied to determine significance in several instances. In the following discussion of the results, means are expressed as percentages. In the second stage of analysis, a logistic regression procedure was used to fit a predictive model of conflict showing that the independent variables: extent of the conflict; degree of perceived impediment caused by conflict; assessment and management of conflict; and finally, the type of conflict, impact on the probability of project success. This is the subject of another paper.

Large, Completed Information Systems Development Projects

Respondents were asked to consider the largest, completed, information systems development project they had been involved with and then answer the questions that followed. These were successful projects in terms of “non-failed” projects, as defined for the study. In terms of project size, 48% of the respondents nominated a project which had an elapsed time between 1-2 years from inception to delivery; 48% nominated a project with an elapsed time between 3 and 5 years, and 4% nominated a project that had an elapsed time greater than 10 years. Respondents were then asked if this large project involved the centralisation or integration of information resources that would change the way these resources would be controlled in the organisation, and 81% responded that it did.

(a) Openness of Conflict in Large Project

In response to the question are you now aware of any conflict that arose during the development of this large project, 89% of respondents said yes. Of these, 100% stated that this conflict was so overt and obvious they were aware of it during the project, and 54% said that there was also some conflict within the project that was so covert that they were not directly aware of it during the project. Interestingly, 85% of those identifying covert conflict claimed to have become aware of the conflict during the project, and only 15% said they did not become aware of the covert conflict until after the project was over. This suggests that very little conflict actually remains covert over the duration of a large project.

A number of explanations were offered as to how respondents became aware of this covert conflict: “Attempts to postpone decisions during committee/approval processes”; “There is always some covert manoeuvring in [any] project (IT or non-IT). I always find out from trusted users who have respect for what we are trying to achieve”; “Gossip”; “You notice subtle resistance where you do not expect it.”; “Feedback from industry representatives or from user representatives”; “Constant changes to scope & requirements being imposed from external sources without formal processes being used”.

(b) Conflict and Conflict Management in Large Projects

Respondents were asked to identify the type and extent of overt and then covert conflict they were aware of during the project. They were asked to select from the list reproduced in Table 1 and to indicate whether the degree of conflict was major, significant, or minor. Respondents were encouraged to add other types of conflict they had encountered. Several respondents responded to this invitation, but the conflict situations they described (eg. developer/database administrator, consultant/client department, financial staff/end-users) could all be categorised under one of the three different types defined for this study. Table 1 shows the degree of conflict, overt and covert, attributed to each individual description of conflict. Table 2 summarises the degree of overt or covert conflict identified for each of the three types of conflict (incorporating the conflicts identified as other) by showing the percentage of major or significant conflict against the percentage of minor conflict.

Table 1 - Manner and Extent of Overt and Covert Conflict in Large Projects:

Individual Descriptions

Table 2 - Type and Extent of Overt and Covert Conflict in Large Projects:

Summary

These results suggest that first User/User conflict and then Developer/User conflict were the most problematical in large projects. The majority of overt Developer/Developer conflict was considered to be minor, although covert conflict among developers was largely major or significant. The data for covert conflict suggests that User/User conflict is much more likely to create problems than either Developer/User or Developer/Developer conflict, although, since the majority of each type of conflict was considered to be major or significant, this may indicate that covert conflict is generally more problematical than overt conflict.

This trend can also be seen by assessing the percentage of each type of conflict that occurs within a given degree of conflict. The breakdown of conflict reported as major or significant. shows a definite order of magnitude (with 18% being Developer/Developer Conflict, 38% being Developer/User Conflict and 45% being User/User Conflict). In terms of covert conflict, the breakdown of covert conflict reported as major or significant shows that more than half of this type of conflict is between users (with 17% being Developer/Developer Conflict, 27% being Developer/User Conflict and 57% being User/User Conflict).

For each individual description of conflict respondents identified, they were asked how that conflict was assessed and managed as a risk to the project. Respondents were asked to indicate “yes”, “no” or “don’t know”, for each of the risk management responses or outcomes identified in Table 3. Obviously, covert conflict can only be managed if it is detected, so while respondents were asked if overt conflict was formally assessed, they were asked if covert conflict was detected in time to have acted on it, if necessary. “Don’t know” responses were only recorded for conflict resolution of overt conflict, and these are shown in the “?” column.

Table 3 - Management of Overt and Covert Conflict in Large Projects: Summary

It appears that very little formal risk assessment is conducted to detect conflict in an information systems project domain, although it is interesting to note that, for some projects, a conflict risk assessment was conducted for User/User conflict as well as the more commonly acknowledged risk of Developer/User conflict. It was also clear that covert conflict does not stay concealed for long, since the majority of instances of covert conflict were detected in time to do something about them. A surprising result was the very small relative percentage of conflict the Project Manager sought to resolve, and the extraordinary low rate of successful conflict resolution of all types of conflict.

Clearly, many large projects attempt to continue on despite a considerable amount of unresolved conflict, and despite the fact that the majority of respondents believe that overt and covert conflict impedes the effective progress of the project. This is shown in Table 4, which summarises respondents’ answers to the question do you believe this conflict impeded the effective progress of this large project?. This question was asked both for overt and covert conflict.

Table 4 - Perceived Impediment of Overt and Covert Conflict to Effective Project Progress in Large Projects

Overall, 96% of respondents who were aware of overt conflict during the project believed it impeded the progress of the project, and 71% believed the this impediment was significant or major. Similarly, 69% of respondents who identified covert conflict associated with the project believed it was a major or significant impediment to the progress of the project.

(c) Explanatory Comments

Some of the qualitative comments returned with the questionnaire elucidated attitudes to conflict and reasons why some of the destructive conflict recorded had occurred.

On Developer/Developer Conflict: “Mainly a difference in professional opinions of the Project Manager and senior team member. Most issues solved by General Manager and no effect on project timeframe”; “From observing the Project Manager taking the advice of the wrong staff instead of managers of functional areas. The Project Team became introverted and two-dimensional”.

On Developer/User Conflict: “Conflict is mainly concerned with individual PM unable or unwilling to consider corporate information objectives. Conflict also occurs between technology developers and end-users generally concerning different views of user requirements”; “The system was the vehicle/catalyst for major conflict over organisational change. Eventually I refused to allow any resources to be dedicated until the management issues were resolved”.

On User/User Conflict: “Conflict related primarily to lack of common understanding of system requirements and an inadequate consultation process before the specification was released to the developer... users were in conflict with one another going into test, wanting changes”; “Pig-headed senior user who wanted what was best for him, not the organisation”.

A small number of respondents experience was with conflict in its constructive role, as a useful way to air and resolve differences: “I saw the conflict as reasonably healthy; it seemed to be resolved amicably on all occasions, as we concentrated on the issues, not the people when we disagreed”; “The project changed operations so much that conflict was to be expected. Sometimes the conflict led to (heated) discussions which actually helped clarify issues.”

Terminated Information Systems Development Projects

In the second part of the survey, respondents were asked to consider another project they had been associated with, this time an information systems development project that was terminated before the system was delivered to the client. In other words, a failed information systems project as defined for this study. The questions asked were virtually identical to those asked in the first part of the survey to facilitate the comparison of factors in a failed information systems project with those in a successful (non-failed) project. Altogether, 93% of all respondents indicated that they had been involved with a terminated project. In answer to the question did this terminated project involve the centralisation or integration of information resources that would change the way these resources would be controlled in the organisation, 76% of respondents said yes.

(a) Openness of Conflict in Terminated Projects

68% of respondents said they were aware that conflict arose during the development of the terminated project. Of these, 100% stated that this conflict was so overt and obvious they were aware of it during the project, and 53% said that there was also some covert conflict within the project. Of those that identified covert conflict, 78% claimed to have become aware of the conflict during the project, and only 22% said they did not become aware of the covert conflict until after the project was over. This is consistent with the data for large, successful projects, with the exception that fewer respondents reported conflict during the development of the project. This may simply be a function of the relative length of the projects. It is difficult, however, to make definitive judgements, because of the small number of respondents identifying covert conflict. The set of data on covert conflict was not statistically significant according to Chi-squared analysis, however, the results obtained are consistent with overt conflict in both project types and with covert conflict in large projects.

(b) Conflict and Conflict Management in Terminated Projects

Table 5 shows the extent of conflict attributed to each individual description of conflict. Table 6 summarises the extent of conflict identified for each of the three types of conflict

Table 5 - Manner and Extent of Overt and Covert Conflict in Terminated Projects:
Individual Descriptions

Table 6 - Manner and Extent of Overt and Covert Conflict in Terminated Projects:

Summary

These results suggest that Developer/User conflict and User/User conflict were the most problematical in terminated projects, which is consistent with the results for large, successful projects, although, not surprisingly, there is clearly a much greater percentage of user-related conflict that was considered to be major or significant in the terminated projects. The data for covert conflict indicates that User/User conflict is again much more likely to create problems than Developer/User, and Developer/User is more problematical than Developer/Developer conflict. This maybe because most Developer/User conflict is likely to be overt, whereas much User/User conflict can be covert or concealed (Ahituv et al 1994; Marakas & Hornik 1996). However, the relativities between the three types are consistent with the data for large, successful projects. In other words, Developer/Developer conflict is considered to be far less of a problem than either User/User or Developer/User conflict.

While only 10 % of the overt conflict considered to be of a major or significant extent is attributed to Developer/Developer conflict, 41% is identified as Developer /User conflict and almost half (49%) is due to User/User conflict. In regard to covert conflict, 11% of major or significant conflict is Developer/Developer conflict, 29% is Developer/User conflict and 60% is User/User conflict. Table 7 shows conflict management responses or outcomes relevant to the conflict types identified.

Table 7 - Management of Overt and Covert Conflict in Terminated Projects: Summary

The results show that very little formal risk assessment is conducted to detect conflict in information systems projects and where it is conducted it is largely used to assess Developer/User conflict, and, in one case, User/User conflict. In the terminated projects the respondents were involved with, no formal risk assessment was conducted on Developer/Developer conflict. As for large projects, the project manager appears to attempt resolution of the overt conflict for approximately half of the User/User and Developer/User conflicts and for a little more than one third of Developer/Developer conflict. However, when it comes to covert data, the project manager attempts to resolve an even smaller percentage of the detected conflict. Again the data suggests that the success rate of conflict resolution in the information systems project domain is extraordinarily low. These findings are consistent with those for large projects, differing more in magnitude than in relativities.

Many respondents felt that conflict (both overt and covert) was directly responsible for the termination of the project. Table 8 summarises respondents’ answers to the question do you believe this conflict impeded the effective progress of this terminated project.

Table 8 - Perceived Impediment of Overt and Covert Conflict to Effective Project Progress in Terminated Projects

Clearly, with 35% of respondents stating that they believed overt conflict to be the prime reason for the projects’ termination and 44% stating they believed covert conflict to be the prime reason for termination, conflict is an issue that should not be ignored by project managers and system developers.

It is interesting to note that the most frequently reported form of major or significant overt conflict was between corporate managers and developers. This is consistent with the literature on the need for maintaining top management support (Ahituv et al 1994; Ewusi-Mensah & Przasnyski 1991; Sauer 1993) and suggests that this dynamic can involve considerable conflict. The three most frequently reported forms of major or significant covert conflict were: conflict among different groups of user management; conflict between user management and corporate management; and conflict among different end user groups. This is consistent with the literature on power and information politics in organisations (Davenport et al 1992; Hirschheim & Newman 1991; Marakas & Hornik 1996; Robey at al 1993) suggesting that a primary cause of conflict is the politically-charged ownership and control of information resources in organisations. The implementation of an information systems which may change and devolve ownership can be viewed as a threat and result in covert and overt machinations to subvert or change the course of the information systems development.

STUDY LIMITATIONS AND FURTHER RESEARCH

The most significant limitation of this study, and therefore, its findings, is the restriction to public sector organisations in the ACT, and the subsequent small sample. Several respondents to the survey commented that they had only just moved to Canberra, or had recently joined the public sector or had spent equal amounts of time in the private and public sectors. However, while this may suggest that results in the private sector and outside of Canberra may, in fact, be similar to the study’s findings, it is not possible to extrapolate the findings to the private sector or a wider geographical area without further research and a larger sample.

While it is possible to speculate on what the results of this research tell us about the causes of the different types of conflict and when they may be expected to occur, this was not the focus of this study and further research is required to investigate these issues. Furthermore, given the extraordinary low rate of conflict resolution where resolution is attempted, further research is mandatory to discover what forms of conflict resolution are the most successful in the information systems development environment, and when and how they should be applied in order to maximise the probability of project success.

CONCLUSION

Conflict in the information systems development environment is largely regarded to be destructive, an impediment to effective project progress and ultimately project success. Whether that conflict is overt or covert does not appear to be a particularly significant factor. In fact, this research study suggests that there is very little conflict that is so covert it does not become apparent during a project. The most potentially damaging type of conflict appears to be conflict among users. This type of conflict is not as well documented as conflict between users and developers and not always recognised as being part of a project manager’s domain. Many developers still believe that organisational politics is not their concern. To facilitate a successful implementation, developers should make it their business to gain a clear understanding of who is likely to win and who is likely to lose from a potential information systems development (Hirschheim and Newman 1991;. Levine & Rossmoore 1994). If developers ignore the politics endemic in large, intra-organisational developments they risk the project becoming embroiled in a number of destructive, time consuming disputes.

Few developers actually assess organisational conflict as part of their formal risk assessment procedures, although it is interesting to note that a small minority do. Of this minority, most assess Developer/User conflict, but some are formally assessing User/User conflict as well. Project managers attempt to resolve less than half of the detected conflict in an information systems project, and it is interesting to speculate about why so many conflicts are apparently ignored. It may be possible that the conflict is not ignored, but monitored, and resolution only attempted in the 33-58% of cases represented by the data. It is also possible that resolution is attempted at grass roots level or at IT manager level and not by the project manager. In fact, one of the respondents commented that “PM does not have total responsibility for conflict resolution. Attempts made by corporate policy makers to resolve”. However, the woefully poor success rate for resolving conflict of all types does not support this conclusion. Further research is required to understand this issue.

Unfortunately, many project managers still do not accept that there is a need to involve themselves in this aspect of organisational dynamics and many still consider this to be a “management” problem, and not of particular concern to systems staff. It is hoped that the results of this study can persuade them otherwise.

REFERENCES

Ahituv, N., Neumann, S. and Riley, H.N. (1994) Principles of Information Systems for Management, 4th ed., Wm. C. Brown, B&E Tech, Dubuque, Iowa.

Davenport, T.H., Eccles, R.G. and Prusak, L. (1992) "Information Politics", Sloan Management Review, 34,1, Fall 1992, 53-65.

Davies, L.J. and Myers, M.D. (1994) "Scholarship and Practice: The Contribution of Ethnographic Research Methods to Bridging the Gap", Proceedings of the IFIP TC8 Open Conference on Business Process Re-Engineering: Information System Opportunities and Challenges, ACS, Qld., Gold Coast.

Davis, G.B., Lee, A.S., Nickles, K.R., Chatterjee, S., Hartung, R. and Wu, Y. (1992) "Diagnosis of an information system failure: A framework and Interpretive process" Information & Management, 23, 293-318.

Dawson, S. (1986) Analysing Organisations, Macmillan, London.

DeLone W.H. and McLean E.R. (1992) "Information Systems Success: The Quest for the Dependent Variable", Information Systems Research, 3, 1, 60-95.

Ewusi-Mensah, K. and Przasnyski, Z.H. (1991) "On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices", MIS Quarterly, 15, 1, March, 67-86.

Franz, C.R. and Robey, D. (1984) "An Investigation of User-Led System Design: Rational and Political Perspectives", Communications of the ACM, 27, 12, 1202-1209.

Hirschheim, R, and Newman, M. (1991) "Symbolism and Information Systems Development: Myth, Metaphor and Magic", Information Systems Research, 2, 1, 29-62

Kling, R. (1993) "Organizational Analysis in Computer Science", The Information Society, 9,1-29.

Levine, H. G. and Rossmoore, D. (1994) "Politics and the Function of Power in a Case Study of IT Implementation", Journal of Management Information Systems, 11, 3, 115-133.

Marakas G.M. and Hornik, S. (1996) "Passive Resistance Misuse: Overt Support and Covert Recalcitrance in IS implementation" European Journal of Information Systems, 5, 208-219.

Markus, M. L. (1983) "Power, Politics and MIS Implementation", Communications of the ACM, 26, 6, 430-444.

Orlikowski, W.J. and Robey, D. (1991) "Information Technology and the Structuring of Organizations" Information Systems Research, 2, 2, 143-169

Pichault, F. (1995) "The Management of Politics in Technically Related Organizational Change", Organization Studies, 16, 3, 449-476.

Pliskin, N., Romm, T., Lee, A.S. and Weber, Y. (1993) "Presumed Versus Actual Organizational Culture: Managerial Implications of Information Systems", The Computer Journal, 36, 2, 143-152.

Robey, D., Farrow, D.L. and Franz, C.R.I. (1989) "Group Process and Conflict in System Development", Management Science, 35, 10, 1172-1191.

Robey, D., Smith, L.A. and Vijayasarathy, L.R. (1993) "Perceptions of conflict and success in information systems development projects", Journal of Management Information Systems, 10, 1, 123-139.

Rouse, A. and Watson, D. (1994) "The Role of Culture in Information Systems Quality", Proceedings: 5th Australasian Conference on Information Systems, Monash University.

Saarinen, T. and Vepsalainen, A. (1993) "Managing the Risks of Information Systems Implementation," European Journal of Information Systems, 2, 4, 283-295.

Sauer, C. (1993) Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-On-Thames, Oxfordshire.

Warne L. and Hart D.N. (1996) "The Impact of Organizational Politics on Information Systems Project Failure - A Case Study", Proceedings of the 29th Annual Hawaii International Conference on Systems Sciences IV, IEEE Computer Society Press.

Warne, L. (1995) "Organizational Power and Information Systems Development: Findings from a Case Study of a Large Public Sector Project" Proceedings of the 6th Australasian Conference on Information Systems, Cutin University, Perth.

ACKNOWLEDGEMENTS

The author would like to thank the two anonymous reviewers of this paper for their helpful comments and suggestions.

COPYRIGHT

Leoni Warne (c) 1997. The author assigns to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to ACIS to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the ACIS 97 conference papers, and for the documents to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.