Competing Commitments Theory

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.