Competing Commitments Theory

Competing Commitments Theory

John McAvoy (University College Cork, Ireland) and Tom Butler (University College Cork, Ireland)
DOI: 10.4018/978-1-60566-659-4.ch019
OnDemand PDF Download:
$30.00
List Price: $37.50

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.
Chapter Preview
Top

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.

Key Terms in this Chapter

Commitment: The act of binding yourself (intellectually or emotionally) to a course of action.

Adoption: The selection and implementation of a new system.

Competing Commitments: Energy being unwittingly applied against a commitment already made.

Assumptions: Statements and beliefs accepted as true without proof or demonstration

Resistance to Change: The action taken by individuals and groups, both conscious and subconscious, when they perceive that a change is a threat to them.

Complete Chapter List

Search this Book:
Reset