chapter xix competing commitments theory€¦ · in 1994 to help solve the ‘wicked problems’...

336

Chapter XIXCompeting Commitments

TheoryJohn McAvoy

University College Cork, Ireland

Tom ButlerUniversity College Cork, Ireland

Copyright © 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

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 straight-forward, 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

337

Competing Commitments Theory

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 arti-facts 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 program-ming 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 ques-tion 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, sys-tems 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 develop-ment project teams and theorizes on the underly-ing 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.

bAckgROunD

The nature of change in IS projects is complex viz. according to Beck (2000, p. 28): “The requirements change. The design changes. The team changes. The business changes. The team members change. The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes”. It is clear from Beck that management of change in a software development project is vital. The problem is how is this achieved? Cushway and Lodge (1999) indicate that change is best managed by developing new strategies and structures; they make no mention of the teams and individuals who will effect, and be affected by, change to processes and activities. However, Zmud (1983) argues that trying to implement process change by changing people will lead to resistance: hence, Rainwater (2002) indicates that projects in which the impact of change is not assessed are in danger of run-ning into problems. Clearly, successful change in software development processes and practices in teams will be dependent on several factors (Beck, 2000; Whitehead, 2001). However, if team mem-bers resist change, whatever their competences and abilities, then problems ensue.

338


The concept of resistance to change center-ing on the reluctance to deviate from group or individual norms is noted in Lewin (1951), and further elaborated in Dent and Goldberg (1999), Asch (1952), and Wren (2005). Argyris (1985) and Robbins and Finlay (1998) argue that resistance to change occurs when an accompanying threat is perceived, as people adopt defensive positions in the face of threats. Individuals also resist when a change is forced upon them. For example, us-ers may resist the change to business processes associated with the adoption of an IS, if there was a low level of participation in the software development project (Cavaye, 1995). In a general context, Mitsufuji (2001) and Venkatesh and Davis (2000) argue that without the consensus of the targeted user group, the diffusion of a new software artifact will probably not be accepted. Without input, the users of the system can feel that they are being forced into using it and their commitment will be reduced (Cavaye, 1995). The significance of commitment to project success can be seen in an exploratory study by Gemmill and Wilemon (1997), who found that sixty-six out of one hundred IT project managers expressed frustration at the lack of commitment from their project team members. From this, we can see the influence, and importance, of commitment to IS projects.

Argyris (1998) describes two types of com-mitment: external commitment and internal commitment. External commitment arises when compliance is required of the employee, where the goals, tasks, and required behaviours are defined by management. Internal commitment is where the individual is committed to a task, project, or person for personal reasons. Internal commitment derives from having personal preferences in terms of goals and objectives.

Resistance to change can indicate a lack of commitment to the change, but there can be other explanations (Bowe, Lahey, Kegan, & Armstrong, 2003). Software developers provide excellent ex-amples of such resistance to change. In his study

of the Microsoft NT Project, Zachary (1994, p. 13) observes that programmers “like converts to a new religion…often display a destructive closed-mindness bordering on zealotry”, a consequence of which is a high level of resistance to change. In ‘Software Development on a Leash’, resistance to change is shown to be modulated by other fac-tors and in perspectives that view change being detrimental to a project (Birmingham, 2002); else-where, and in the same vein, change is something that must be coped with and its disruptive impact minimized, rather than embraced and fostered (Field & Keller, 1998). Returning to the point made by Bowe et al. (2003a), there can be other explanations for resistance to change other than a lack of commitment. Lawrence (1969) believes that this resistance to change can highlight the fact that something is being overlooked, that the change itself has not been thought through and may be sub-optimal. In this scheme of things, resistance to change should not be viewed as being nega-tive, it may be an indicator that the change itself needs further examination. Furthermore, Kegan and Lahey (2001a) propose that some resistance is easy to explain (for example the stress of learning a new skill) but other resistance is not as easily explained. A paradox exists where people show a commitment to, and support for, change yet still resist the change. Robbins and Finley (1998) state that some forms of resistance can be subconscious viz. team members all agree on a new course of action, but then do nothing to implement it. Although individuals may consciously believe that a change would be beneficial, unconscious or latent attitudes may create potent barriers to this change (Patching, 1999; Statt, 2004). This has consequences for practitioners instituting change and researchers studying it. In the latter case, researchers would benefit from the application of a method which would identify and explain the causes for this paradox.

The Open Systems School examines change through organizations and their component sub-sets. It posits that any change in one subset will

339


impact the others; accordingly, it is necessary to take a holistic view of the organization when implementing change. Boody and Macbeth (2000) add subtly to this by stating that change in one area, needs to be accompanied by (as opposed to ‘will cause’) changes elsewhere. Take, for example, the introduction of a datamining application in a marketing department. As with the implementa-tion of all new IS, users would have to accept and have a good understanding of technology before they could use it effectively—thus, there is a requirement for training and help during use, which would not have been necessary before the change. Hunt and Thomas (2000) refer to this as an example of a non-orthogonal system, while Birmingham (2002) describes the small changes affecting other areas as having either a ripple effect or cascading effect. In sum, this school of thought argues that a small change in one area, can have both foreseen and unforeseen or unin-tended consequences in seemingly independent areas or activities.

The Group Dynamics School places emphasis on instituting change by focusing on groups. As individuals work in groups, changes occur through changing a group’s norms and practices (Alkire & Denevlin, 2002). Thus, as this paper argues in line with extant thought in the discipline, the implementation of an IS, or changes in IS devel-opment process and project team, will ultimately change the norms and practices of the end users and/or the developers (business analysts, design-ers, programmers etc.). One finding that needs to be considered in all this is that one of the reasons people form into, and attach to, groups is to shield themselves from change – in addition to the commonly held conceptions, a group is also “an insurance mechanism coping with uncertainties” (Alkire & Denevlin, 2002, p.21).

We argue herein that researching resistance to change in IS development projects can be problem-atic. Venkatesh and Davis (2000) maintain that, for a new system to be accepted, its usefulness must be visible to those using it. Visibility is one

thing, but understanding another, as Raghavan and Chand (1989) state that innovations (such as new software development methodologies) can be both misunderstood and misapplied. Ultimately, therefore, something as apparently simple as a misunderstanding could lead to resistance and the emergence of complex problems. It is apparent, however, that the reasons behind resistance may be more complex than just misunderstanding; hence, the latent, as opposed to manifest reasons, can be hidden from researchers, and be so ingrained that those resisting change are unaware of them (McAvoy & Butler, 2005).

Thus resistance to, or problems with, the ac-ceptance of, for example, a new approach to IS development may be overt or covert. For example, deliberate sabotage of an adoption such as an Agile programming methodology is described as a potential concern by Broza (2005) and Schwaber (2002). These problems, though, are often latent or hidden, even from those involved in the process; Edmondson and Moingeon (2003, p.27) refer to these as “built in impediments”, while Luecke (2003) refers to ‘passive resistors’. Individuals are usually unable to determine the origins of their resistance to change, although they may offer a view of what they consider to be the problem (manifest condition), which may not be the real crux of the issue at hand (latent causes cf. Goleman, 1996; McAvoy and Butler, 2005). Often, resistance to change stems from an emotional reaction rather than a logical reasoning in the consequence of change (Whitehead, 2001). Thus, Veryard (2001) shows how resistance to the diffusion of an innovation can be both logical and ridiculous.

Chris Argyris (1976) captures the essence of such issues in his illustration of how individu-als are unable to discern the difference between what they believe in and what they actually do (‘espoused theories’ versus ‘theories in use’). It is clear from Argyris that the inability to discern between, and reflect upon, ‘espoused theories’ versus ‘theories in use’ is usually not recognized

340


by those affected by the phenomenon. We argue, therefore that surveys, questionnaires, and other such approaches are unsuitable research methods as a respondent cannot, or may not wish to, identify the differences between their ‘espoused theories’ and ‘theories in use’.

Other organisational psychologists, notably Kegan and Lahey (2001 a,b), elaborate on this paradox, and argue that resistance to change does not imply the inability to commit to a particular course of action, rather the existence of a compet-ing commitment. Competing commitments are not normally visible as conscious utterances or actions; they are observed as energy being unwit-tingly applied against the manifest commitments already entered into. This resisting force is caused by commitments that act against the initial com-mitment. For example, while a manager may be initially committed to Business Intelligence in his company, there may be a gradual erosion of com-mitment to the extent that the manager continually complains that the system does not provide the information he requires. Rather than the manager resisting the change to the use of BI, the manager may actually fear that his role in the organisation is being displaced by technology. So while the manager may imply that he is committed to using only the best information, his competing com-mitment, not being displaced by the technology, will work against the original commitment. An approach is required to determine why individuals resist the change inherent in IS projects, and to determine if individuals have commitments work-ing against the change. Competing commitment theory explains the change paradox by examining the people involved in the IS project.

It is clear then, that the investigation of the factors that inhibit, or cause resistance to, the adoption of new technologies or techniques may be phenomena that would be normally hidden from, or not observable by, outsiders such as re-searchers. As indicated above, this situation calls for the application of research approaches that are sensitive to such issues (Jorgensen, 1989).

The cOmpeTIng cOmmITmenTs pROcess

Previous studies on the commitment concept are underpinned by the assumption that highly committed individuals are high-performance employees that provide positive benefits for an organization with reduced turnover and absentee-ism being cited as some of the positive benefits (Mowday, 1998). Mowday illustrates the extent of ‘commitment’ research and its many dimen-sions and anomalies, and concludes that its contribution has been positive. Benkhoff (1997, p.114) concludes, however, that “[a]fter 30 years of research on employee commitment the results are disappointing. So far there is no evidence of a systematic relationship between commitment and its presumed consequences – turnover and job performance – even though these links are almost implied by the definition of the concept. Nor do we know very much about the factors that explain the phenomenon.” Thus, there appears to something paradoxical with the concept.

IS research, while limited, has picked up on this and has focused on the escalation of commit-ment in IS development projects (see, for example, Keil, Rai & Mann, 2000). In brief, escalation of commitment is a negative phenomenon that occurs when project managers and teams remain commit-ted to particular courses of action in projects that should change direction or be abandoned (Keil et al., 2000). The other stream of commitments research follows the conventional line and focuses on the benefits of commitment for IS develop-ment projects (cf. Newman & Sabherwal, 1996). Inspired by Winograd and Flores’ (1987) seminal work, Butler (2003) drew on institutional theory in sociology to illustrate that commitments are shaped by, and are manifested at, several levels: individual, group, organizational, and societal. We now focus on the most interesting anomaly with the concept of commitment, which may help explain its often paradoxical and confusing nature.

341


Kegan and Lahey (2001a; 2001b) have been instrumental in exploring the paradox of compet-ing commitments. In their scheme of things they prefer the term ‘immunity to change’ in place of ‘resistance to change’. Resistance implies know-ingly working against something for reasonably defined objectives. They argue that competing commitments, in which there is a manifest com-mitment (i.e. an ‘espoused theory’) and a latent commitment (a ‘theory in use’) that are not obvious, even to the individuals who possess them. Banerjee (2003, p.74) describes compet-ing commitments as “self-defeating behaviour.” Elsewhere, Goleman (1996) refers to ‘vital lies’ and ‘simple truths’. These behaviours, particularly if subconscious, act against change in attitudes and behaviours.

Competing Commitments Theory, also known as the Big Assumptions Theory, proposes a process through which the competing commitments, that negatively effect change, can be surfaced (i.e. made manifest) and identified for what they are. This process was originally proposed in Kegan and Lahey (2001a), and further discussed and demonstrated in Kegan and Lahey (2001b), Sparks (2002), Nash (2002), Bowe et al. (2003a; 2003b), and Banerjee (2003). Competing commitments have some similarity with the view of Milgram (1971) who argues that public declarations of ad-herence to group decisions do not imply that the individual will translate this adherence into ac-tion. Kegan and Lahey’s competing commitments describe the reasons why this initial acceptance or commitment to change is not acted upon. It should be pointed out, though, that Millgram’s experiments showed that adherence to a particu-lar position can translate into desired behaviours and actions.

It is clear from Kegan and Lahey that their theory has wide application. For example, Nash (2002) and Bowe et al. (2003a; 2003b) apply the process in the field of medicine and medical education, while Banerjee (2003) applies it at the organisational level in business enterprises.

We argue that competing commitments theory and method is of particular use at the level of IS development or software project teams, and to investigate change management in IS imple-mentations, from senior management to the end users. Thus, the theory can operate at several levels of analysis. To the best of our knowledge, other researchers have not applied this theory in the IS domain.

The suitability of this approach for Medical Education is identified in Bowe et al. (2003b, p.723) who describe the technique being used to examine why problems arose “during implementation [of programs] when unanticipated or unaddressed organizational resistance surfaces.” Nash (2002, p. 592) describes the use of the competing com-mitments process to go beyond “buy-in”. Kegan, in Sparks (2002), describes what Nash refers to as “buy-in” as a short-lived espoused commit-ment. For example, Bowe et al. (2003a, p.715) described the problem with “buy-in” as “like many new years’ resolutions, sincere intent to change may be short lived and followed by a return to old behaviours.”

Kegan and Lahey (2001a,b) developed a technique to investigate and identify compet-ing commitments. Various authors describe this technique (Bowe et al., 2003a, 2003b; Kegan & Lahey, 2001a, 2001b; Nash, 2002; Sparks, 2002), although it had not been applied it in the IS field. The technique comprises six steps, in the form of questions, although different authors merge some steps. The examples used below are those used in Kegan and Lahey (2001b).

In the example above, the dialogue between the researcher and the manger moved from a complaint by him about a team not keeping the project manager informed, to the ‘big assump-tion’ that people will think him incompetent if it is perceived that he cannot solve every problem. The individual publicly states a commitment to full communication, yet the competing com-mitment—not learning about things the project manager can’t control—effectively works against their commitment to full communication.

342


fuTuRe TRenDs

McAvoy and Butler (2005) utilized this process in an investigation into resistance to the adoption of a software development methodology in an IS development team. While the team expressed an initial commitment to the methodology, over time this commitment was watered down and resistance to it developed. Likewise, the developers and the project manager expressed a commitment to effective use of resources in the project. After a short period of use, team members expressed the opinion that the new methodology was a waste of time, and the resources employed could be better used elsewhere. The process followed, on one of the team members, is shown below (table 2.), and follows the steps provided in Kegan and Lahey (2001b), shown in table 1.

The researchers applied the competing com-mitments process to each individual team member to determine why the change was being resisted. There was uniformity in the competing commit-ments that were identified; they were each more committed to team unity than the introduction of the new methodology. They felt that team unity was being impacted by the new methodology, so they resisted it. The cause of the resistance was

actually not initially visible to the researchers, in fact those resisting were not aware of the reasons themselves. Simply interviewing the team would have come to the conclusion that the problem was a resource allocation problem. The team had convinced themselves that their problem was with resource allocation; through the competing commitments process they could identify that the real concern was with its impact on the unity of what was a highly cohesive team – cohesion was more important to the individuals than the new methodology.

While the research described above was in the IS development domain and with project teams, the approach here outlined can also be applied in other areas such as management of change around IS adoption. Organisations do not truly reflect on problems surrounding IS adoptions. Weick (1995) argues that sensemaking occurs when individuals make retrospective sense of where they are now, and how they got there. Swanson and Ramiller (2004, p. 554) argue that organisa-tions, which adopt and implement information systems, “entertain scant reasoning for their moves…deliberative behaviour can be swamped by an acute urgency to join the stampeding herd, notwithstanding the high cost and apparent risk

Table 1. Determining competing commitments – from Kegan and Lahey (2001b)

Step Question Example Response

1 What problem are you experiencing in work – a gripe or com-plaint? My team do not tell me what’s happening in a project

2 The complaint identifies something about you. What commit-ment does it imply?

I am committed to maximising the flow of information within the project.

3 What am I doing or not doing that goes against this commit-ment?

Sometimes I don’t go out of my way to find out what is hap-pening.

4What do you think would happen if you were not doing what you described in question three – if you did the opposite of the undermining behaviour? What would worry you about this?

I might find out things from my team that I can do nothing about, something I can’t fix.

5 What does this worry imply that you are committed to? I am committed to not learning about things I can’t control.

6Inverting the answer from step five, and making it into the beginning of an assumption, complete the sentence. i.e. I as-sume that if I ….

I assume that if I learned about thing I couldn’t control, people would realise that I am not able to do my job.

343


involved”. It is clear from Swanson and Ramiller’s findings that far from being mindful, heedless or mindless behaviour by organisations is the rule, rather than the exception, when it comes to the adoption of Information Systems. One of the major concerns with organizations adopting In-formation Systems is what Swanson and Ramiller describe as unchallenged assumptions. It is argued herein, that the competing commitments process is a mechanism that can be used to identify and challenge these assumptions.

cOnclusIOn

Change is inherent in IS projects, and often problematic. It is argued herein that competing commitments may play a part in the problems in IS change efforts, and that “without an under-standing of competing commitments, attempts to change employee behavior are virtually futile” (Luecke 2004, p.150). One of the recommendations deriving from this chapter is that team members involved in an IS adoption should not conduct a competing commitments analysis, as we believe that the team member will bring their own biases, even their own competing commitments into the

process. A suitably removed Devil’s Advocate would be most effective in this role. Significantly, this runs counter to Swanson & Ramiller’s (2004) recommendation of the use of internal experts working in the relevant domain. This would have the paradoxical consequence of a using mindless approach to investigating a mindless adoption.

The use of the competing commitments process is not recommended as a panacea for all research into resistance to change in IS projects. Some resistance occurs because the proposed system or idea is intrinsically flawed or unsuitable (Veryard, 2001). In scenarios such as this, there may be no hidden factors influencing the resistance; the resistance is open rather than latent. Similarly, individuals may be able to readily identify their reasons for resistance without recourse to the competing commitments process – assuming of course though they are genuinely providing a truly reflective answer. There are, though, times when a researcher needs to be able to identify hidden factors behind the resistance to an IS project. Competing commitments theory, on its own, will not solve resistance to change within IS projects; rather it can be the first stage where the cause of the resistance can be identified. Competing com-mitments theory is therefore a theory to add to

Table 2. Sample determination of competing commitments for one team member

Step Question Response

1 What is your problem with the new methodology? It doesn’t necessarily add value to the project.

2 The complaint identifies something about you. What commit-ment does it imply? I am committed to only doing work that adds value

3 What am I doing or not doing that goes against the commitment to only performing work that adds value? Chatting with the lads on the team. Long coffee breaks.

4What do you think would happen if you were not doing what you described in question three – if you did the opposite of the undermining behaviour? What would worry you about this?

Won’t get on with the team. Harder to interact with team. Team would be less likely to help me.

5 What does this worry imply that you are committed to? I am committed to being part of the team, one of the lads. This is more important than the project itself.

6Inverting the answer from step five, and making it into the beginning of an assumption, complete the sentence. i.e. I as-sume that if I ….

I assume that if I was not committed to the team then I would be a loner and not part of the group.

344


the research toolkit, to be used when the research scenario necessitates it.

RefeRences

Alkire, S., & Denevlin, S. (2002). Individual motivation, its nature, determinants, and conse-quences for within group behaviour. In J. Heyer, F. Stewart, & R. Thorp (Eds.), Group behaviour and development (pp. 51-73). New York: Oxford University Press.

Alsene, E. (1999). Internal changes and proj-ect management structures within enterprises. International Journal of Project Management, 17(6), 367-376.

Argyris, C. (1976). Single-loop and double-loop models in research on decision making. Admin-istrative Science Quarterly, 21(3), 363-375.

Argyris, C. (1985). Defensive routines. In D. Pugh (Ed.), Organization theory. Third Edition (pp. 439-454). London: Penguin Books.

Argyris, C. (1998). Empowerment: The emperor’s new clothes. Harvard Business Review, 76(3), 98-105.

Arrow, H., McGrath, J., & Berdahl, J. (2000). Small Groups as complex systems. CA: Sage Publications.

Asch, S. (1952). Social psychology. NJ: Prentice-Hall.

Banerjee, R. (2003). Organisational character: Issues, imperatives and practices. International Journal of Human Resources Development and Management, 3(1), 72-83.

Beck, K. (2000). Extreme programming explained. Embrace change. New York: Addison Wesley.

Benkhoff, B. (1997). Disentangling organizational commitment - the dangers of OCQ for research and policy. Personnel Review, 26(1), 114-131.

Birmingham, D. (2002). Software development on a leash. NY: Springer-Verlag.

Boody, D., & Macbeth, D. (2000). Prescriptions for managing change: A survey of their effects in projects to implement collaborative working between organizations. International Journal of Project Management, 18(5), 297-306.

Bowe, C., Lahey, L., Kegan, R., & Armstrong, E. (2003a). Questioning the big assumptions. Part I: Addressing personal contradictions that impede professional development. Medical Education, 37(8), 715-722.

Bowe, C., Lahey, L., Kegan, R., & Armstrong, E. (2003b). Questioning the big assumptions. Part II: Recognizing organizational contradictions that impede organisational change. Medical Educa-tion, 37(9), 723-733.

Broza, G. (2005). Early community building: A critical success factor for XP projects. Paper presented at the Agile Conference, Denver, CO, USA.

Butler, T. (2003). An institutional perspective on the development and implementation of Intranet and Internet-based IS. Information Systems Jour-nal, 13(3), 209-232.

Clarke, A. (1999). A practical use of key success factors to improve the effectiveness of project management. International Journal of Project Management, 17(3), 139-145.

Coch, L., & French, J. (1968). Overcoming resis-tance to change. In D. Cartwright & A. Zander (Eds.), Group dynamics (pp. 182-191). NY: Harper & Row Publishers.

Cushway, B., & Lodge, D. (1999). Organization be-haviour and design. London: Kogan Page Ltd.

Dent, E., & Goldberg, S. (1999). Challenging a resistance to change. Journal of Applied Behav-ioural Science, 35(1), 25-41.

345


Duck, J. (1993). Managing change: The art of balancing. Harvard Business Review, 71(6), 109-118.

Edmondson, A., & Moingeon, B. (2003). From organizational learning to the learning organi-zation. In C. Grey & E. Antonacopoulou (Eds.), Essential readings in management learning (pp. 21-36). London: Sage Publications.

Festinger, L., & Carlsmith, J. (1959). Cognitive consequences of forced compliance. In E. Coats & R. Feldman (Eds.), Classic and contemporary readings in social psychology. Third Edition (pp. 194-203). NJ: Pearson Education.

Field, M., & Keller, L. (1998). Project manage-ment. London: Thomson Learning.

Gemmill, G., & Wilemon, D. (1997). The hidden side of leadership in technical team management. In R. Katz (Ed.), The human side of managing technological innovation (pp. 237-245). New Y ork: Oxford University Press.

Giangreco, A. (2001). Conceptualisation and operationalisation of resistance to change. Catel-lanza, Italy: LIUC Papers.

Goleman, D. (1996). Vital lies simple truths: The psychology of self-deception. New York: Simon and Schuster Books.

Harmon-Jones, E. (1998). Towards an understand-ing of the motivation underlying dissonance ef-fects: Is the production of adverse consequences necessary. In E. Coats & R. Feldman (Eds.), Classic and contemporary readings in social psychology (3rd ed.) (pp. 204-213). NJ: Pearson Education.

Herzog, J. (1991). People: The critical factor in managing change. Journal of Systems Manage-ment, 42(3), 6-11.

Hunt, A., & Thomas, D. (2000). The pragmatic programmer. MA: Addison Wesley Longman.

Jennings, D. (2004). Myths about change. CPA Journal, 74(4), 12-13.

Jorgensen, D. (1989). Participant observation: A methodology for human studies. CA: Sage Publications.

Kegan, R., & Lahey, L. (2001a). How the way we talk can change the way we work. San Francisco: Jossey-Bass.

Kegan, R., & Lahey, L. (2001b). The real reason people won’t change. Harvard Business Review, 79(10), 85-89.

Keil, M., Mann, J., & Rai, A. (2000). Why soft-ware projects escalate: An empirical analysis and test of four theoretical models. MIS Quarterly, 24(4), 631-660.

Kling, R., & Scacchi, W. (1982). The web of com-puting: Computing technology as social organisa-tion. In M. Yovits (Ed.), Advances in Computers, Vol. 21 (pp. 3-90). New York: Academic Press.

Lafleur, R. (1996). Project management. Getting control and keeping control of complex projects. American Programmer, 9(4), 24-28.

Lawrence, P. (1969). How to deal with resistance to change. Harvard Business Review, 47(1), 77-86.

Lewin, K. (1951). Frontiers in group dynamics. In D. Cartwright (Ed.), Field theory in social science (pp. 188-237). CN: Greenwood Press.

Likert, R. (1978). An improvement cycle for human resource development. Training and Development Journal, 78(32), 16-18.

Luecke, R. (2003). Managing change and transi-tion. MA: Harvard Business School Press.

Luecke, R. (2004). Coaching and mentoring: How to develop top talent and achieve stronger per-formance. MA: Harvard Business School Press.

Lyytinen, K. (1987). Different perspectives on information systems: Problems and solutions. ACM Computing Surveys, 19(1), 5-46.

Markus, M., & Robey, D. (1988). Information technology and organizational change: Causal

346


structure in theory and research. Management Science, 34(5), 583-598.

McAvoy, J., & Butler, T. (2005). A paradox of vir-tual teams and change: An implementation of the theory of competing commitments. International Journal of e-Collaboration, 2(3), 1-24.

McElroy, W. (1996). Implementing strategic change through projects. International Journal of Project Management, 14(6), 325-329.

Milgram, S. (1971). Group pressure and ac-tion against a person. In D. Taylor (Ed.), Small groups (pp. 157-170). IL: Markham Publishing Company.

Mitsufuji, T. (2001). A perspective of the innova-tion-diffusion process. In M. Ardis & B. Marcolin (Eds.), Diffusing software product and process innovations (pp. 51-66). MA: Kluwer Academic Publishers.

Mowday, R. (1998). Reflections on the study and relevance of organizational commitment. Human Resource Management Review, 8(4), 387-401.

Nader, D. (1993). Concepts for the management of organisational change. In C. Mabey & B. Major-White (Eds.), Managing change (2nd ed.) (pp. 5-19). London: Paul Chapman Publishing.

Nash, D. (2002). Beyond buy-in. P&T Journal, 27(11), 617-618.

Newman, M., & Sabherwal, R. (1996). Deter-minants of commitment to information systems development: A longitudinal investigation. MIS Quarterly, 20(1), 23-54.

Patching, K. (1999). Management and organi-sational development. London: Macmillian Business.

Pellegrinelli, S. (1997). Programme management: Organising project-based change. International Journal of Project Management, 15(3), 141-149.

Raghavan, S., & Chand, D. (1989). Diffusing software-engineering methods. IEEE Software, 6(4), 81-90.

Rainwater, J. (2002). Herding cats: A primer for programmers who lead programmers. New York: Springer-Verlag.

Robbins, H., & Finley, M. (1998). Why change doesn’t work. London: Orion Publishing.

Schelling, T. (1989). The mind as a consuming organ. In D. Bell, H. Raiffa, & A. Tversty (Eds.), Decision making. Descriptve, normative, and prescriptive interactions (pp. 343-357). UK: Cambridge University Press.

Schwaber, K. (2002). When and where agile su-ceeds. Cutter IT Journal, 15(9), 22-27.

Sparks, D. (2002). Inner conflicts, inner strengths. Journal of Staff Development, 23(3), 66-71.

Statt, D. (2004). Psychology and the world of work (2nd ed.). Hampshire, UK: Palgrave Macmillan.

Strebel, P. (1998). Why do employees resist change. In J. Kotter, J. Collins, R. Pascale, K. Duck, J. Porras, & A. Athos (Eds.), Harvard Business Review on change (pp. 139-157). MA: Harvard Business School Press.

Swanson, E., & Ramiller, N. (2004). Innovating mindfully with information technology. MIS Quarterly, 28(4), 553-583.

Turner, J., & Muller, R. (2003). On the nature of the project as a temporary organization. International Journal of Project Management, 21(1), 1-8.

Venkatesh, V., & Davis, F. (2000). A theoretical extension of the technology acceptance model: Four longitudinal field studies. Management Sci-ence, 46(2), 186-204.

Veryard, R. (2001). The diffusion of components. In M. Ardis & B. Marcolin (Eds.), Diffusing software product and process innovations (pp. 131-146). MA: Kluwer Academic Publishers.

347


Weick, K. (1995). Sensemaking in organizations. CA: Sage.

Weinberg, G. (1971). The psychology of com-puter programming. New York: Van Nostrand Reinhold Co.

Whitehead, R. (2001). Leading a software devel-opment team. A developer’s guide to successfully leading people and projects. London: Addison-Wesley.

Winograd, T., & Flores, F. (1987). Understand-ing computers and cognition. MA: Addison Wesley.

Wren, D. (2005). The history of management thought (5th ed.). NJ: John Wiley & Sons.

Zachary, G. (1994). Show-Stopper! The breakneck race to create Windows NT and the next generation at Microsoft. New York: The Free Press.

Zmud, R. (1983). The effectiveness of external information channels in facilitating innovation within software development groups. MIS Quar-terly, 7(2), 43-58.

key TeRms AnD DefInITIOns

Adoption: The selection and implementation of a new system.

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

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

Competing Commitments: Energy being unwittingly applied against a commitment al-ready made.

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.

chapter xix competing commitments theory€¦ · in 1994 to help solve the ‘wicked problems’...

Documents