InfoSci®-Journals Annual Subscription Price for New Customers: As Low As US$ 4,950

This collection of over 175 e-journals offers unlimited access to highly-cited, forward-thinking content in full-text PDF and XML with no DRM. There are no platform or maintenance fees and a guarantee of no more than 5% increase annually.

Receive the complimentary e-books for the first, second, and third editions with the purchase of the Encyclopedia of Information Science and Technology, Fourth Edition e-book. Plus, take 20% off when purchasing directly through IGI Global's Online Bookstore.

Abstract

Information system development, like information systems adoption, can be considered to be a change process; yet problems arise when change is introduced. Resistance to the change can develop and the reasoning behind the resistance needs to be determined in order to address it. Resistance can be straightforward, where the change threatens a person’s job or creates stress for individuals, yet resistance can also be hidden and complex. Individuals may describe themselves as supporting a change, yet they work against that change (even if they are unaware that they are doing so). When this is happening, competing commitments can be at play; a competing commitment is where an individual professes a commitment to a course of action yet works against that commitment in different, usual subconscious, ways. The competing commitments process is a means of identifying why resistance is occurring even though individuals profess support.

Introduction

Information system (IS) development has been conceptualized as a change process (Lyytinen, 1987); however, the change referred to by Lyytinen refers to the intervention into complex social webs (Kling & Scacchi, 1982) by a project team in the design and implementation of software artifacts for use in organizational IS. Similarly, the seminal article by (Markus & Robey, 1988) looks at the relationship between information technology and change within organisations. The process by which software artifacts are developed is itself subject to change (Beck, 2000), with the behaviours of project team members being one such object of the change. Significantly, Lafleur (1996) maintains that change is a constant in a software project, while in a broader context, several authors have described how projects are often used to bring about change: an example of which would be introducing a new ERP system, or a change of work practice (Alsene, 1999; Boody & Macbeth, 2000; Clarke, 1999; McElroy, 1996; Pellegrinelli, 1997; Turner & Muller, 2003).

Much has changed since the 1990s in terms of IS development practice; however, problems still persist. For example, the Standish Group’s Chaos Report of 2004 found that over 53% of software projects were challenged, in that they were either over time, over budget and/or the software artifacts lacked critical features and requirements. Another 18% were failures, with the remaining 29% being deemed a success. In explaining the modest improvement since the 1994 survey, Standish Group Chairman Jim Johnson stated that: “People have become much more savvy in project management. When we first started the research, project management was a sort of black art. People have spent time trying to get it right and that has also been a major step forward” (SoftwareMag.com, 2004). The clear implications from this comprehensive industry-based study is that improvements in project management practice have not delivered the necessary improvements in the process and product of IS development. In addition, new design and development programming languages, methods, and techniques have been introduced since the original Chaos Report in 1994 to help solve the ‘wicked problems’ that plague software project teams. The obvious question is why haven’t these improvements worked? The answer may be that all this change to software development processes and practice may not have been as beneficial as is believed. It is clear from extant research that problems arise when change is introduced to project teams. For example, systems developers endeavor to maintain stability and security in the face of change to design and development processes and procedures (Nader, 1993). They do this because the imposition of change can result in stress and, accordingly, developers endeavor to avoid stressful situations by resisting change (Whitehead, 2001).

This chapter explores the phenomenon of change, and commitment to change, in IS development project teams and theorizes on the underlying factors that shape this complex phenomenon; it then proposes a research method with which to effectively investigate this phenomenon. The goal of this chapter is therefore to identify the difficulties resistance to change brings to many IS projects, and then to describe a method with which to identify the cause of the resistance.