Application 2 – Annotated Bibliography

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011 109

Transition to IS Project De-Escalation: An Exploration Into Management Executives’ Influence Behaviors

Gary Pan and Shan Ling Pan

Abstract—This paper seeks to understand the factors that shape management executives’ influence behaviors and the influence tac- tics that may be utilized during de-escalation of commitment to information systems (IS) projects. De-escalation is potentially a more important issue than escalation because de-escalation pro- vides remedies for the ills of escalation. Therefore, it is important to understand how project stakeholders’ commitment to troubled IS projects may be transformed under management executives’ influ- ence, hence allowing project teams to carry out their de-escalation activities. Here, we adopt theories of leadership, politics, and inter- personal influence, as our lenses to examine the management ex- ecutive’s influence behaviors during the transition from escalation to de-escalation of a failing electronic procurement project at UK Borough Council. Based on the case analysis, we presented three key factors that shaped the influence behaviors and six influence tactics utilized separately or collectively by the management exec- utive in the unfreezing, changing, and refreezing phases of project de-escalation. Through the findings, researchers may develop a deeper understanding of how project stakeholders may surrender previous failing courses of action and accept alternative courses of action. Practitioners may also devise useful influence tactics when de-escalating troubled IS projects.

Index Terms—Case study, de-escalation of commitment, influ- ence behaviors, information systems (IS) project.

I. INTRODUCTION

T HERE is a significant body of evidence that many in-formation systems (IS) development projects end in fail- ure. While some attribute the alarming rate of failure to the in- creasing complexity of information technology, others believe these troubled IS projects are entrapped within cycles of com- mitment escalation [41], [46]. Accordingly, only 29% of IS projects are completed within time and budget, the rests ex- hibit some degree of escalation [51]. Experts have suggested the most effective way to eradicate the escalation phenomenon is through de-escalation of commitment to prior failing course of action [16], [29]. Montealegre and Keil [33] consider project de-escalation reduction in commitment to a failing course of action that manifests itself as project abandonment or redirec-

Manuscript received February 26, 2009; revised July 31, 2009 and December 10, 2009; accepted February 4, 2010. Date of publication May 18, 2010; date of current version January 19, 2011. Review of this manuscript was arranged by Department Editor J. K. Pinto.

G. Pan is with the Singapore Management University, Singapore 188065 (e-mail: [email protected]).

S. L. Pan is with the Department of Information Systems, School of Comput- ing, National University of Singapore, Singapore 119613.

Digital Object Identifier 10.1109/TEM.2010.2048908

tion. De-escalation is usually triggered when negative feedback indicates that future investment is unlikely to result in positive returns and perceived to be endogenous to the failing course of action [52]. Thereafter, implementing effective de-escalation strategies efficiently becomes critical, since troubled projects are usually characterized by severe time pressure, unclear project di- rection, and low project-team morale, and without resolving the dire situations quickly, these projects may continue to consume valuable resources without achieving their original objectives.

It is believed the success of de-escalation process largely de- pends on the role of project team leaders in influencing project team members’ willingness to cooperate and participate in the de-escalation efforts. While a few IS project management stud- ies have examined the project de-escalation process [29], [41], no study that we are aware of has explored how project stake- holders may be influenced to switch from escalation to de- escalation of commitment during the commitment change tran- sition. We aim to examine this important topic by applying lead- ership, politics, and interpersonal influence theories as lenses to examine the influence behaviors during de-escalation, since management executives’ lateral influence is considered as a form of project political behavior, and separate leadership style may determine the selection of influence tactics. Against such back- drop, this paper focuses on British Metropolitan Borough Coun- cil (BMBC)’s (a pseudonym) effort in turning around its troubled electronic procurement (e-procurement) project. Specifically, the main research questions are: 1) what are the key factors that shape the process of how management executives influence project stakeholders to overcome their previous failing courses of action and accept alternative courses of action? and 2) what are the influence tactics utilized either separately or collectively during the de-escalation process?

The paper is structured as follows. We will first review past literature on IS project escalation and de-escalation, leadership, politics, and interpersonal influence. This is followed by a dis- cussion on the research approach adopted in this study. Next, we present our case study and discuss the factors that shape management executive’s influence behaviors and the influence tactics adopted in various phases of the de-escalation process. Finally, we present the implications and conclusion.

II. THEORETICAL BACKGROUND

A. IS Project Escalation and De-Escalation

The escalation phenomenon has been observed in many IS projects [35], [41]. One reason why IS projects often fall prey to

0018-9391/$26.00 © 2010 IEEE

110 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

escalating commitment behaviors is due to the intangible nature of software that makes it difficult to obtain accurate estimates of the proportion of work completed, and as a result, giving a false perception that proximity to project completion is close [5]. Interestingly, such misconception seldom occurs in other non- IS projects, such as construction, where physical structure is more visible and allows better gauge of project progress [47]. Besides, IS projects are generally complex and tend to have erratic requirements [34] that cause project scope to change frequently. Projects that exhibit such volatility are especially difficult to manage [29], and likely to result in commitment escalation.1 Therefore, implementing effective de-escalation of commitment to prior failing course of action efficiently is crucial in mitigating the escalation problem [16], [29].

In general, de-escalation is triggered when continued in- vestment into a project is going to achieve negative return or a project is discontinuing due to ambiguity in the probabil- ity of success of continued investment [19]. Table I summa- rizes 21 de-escalation triggering activities or conditions and their respective descriptions in both IS and non-IS literature. Here, a condition that triggers de-escalation is considered de- terminant of de-escalation activities. A de-escalation activity is viewed actions that reduce commitment to a failing course of action.

To date, even though Montealegre and Keil [33] have devel- oped a prescriptive framework to examine the de-escalation pro- cess, the transition from escalation to de-escalation still needs much work [16], [29]. In particular, the process of how project stakeholders may be influenced to switch from escalation to de-escalation of commitment during the commitment change transition remains unknown and deserves more attention. This is an important topic, since there are many challenges facing project teams during commitment change transition, such as severe time pressure, unclear project direction, and low project- team morale when projects have already exceeded deadline and planned budget without achieving original objectives. As a con- sequence, project management strategies may differ consider- ably during de-escalation compared to other stages of project development [20]. For instance, project teams may have to re- structure their activities, rapidly coordinate actions of the project team members, and apply appropriate response strategies when projects have gone bad. The success of de-escalation largely de- pends upon the role of project leaders in influencing the project team members in engaging cumulative sense-making and col- laborative [12] de-escalation activities. The selection of influ- ence tactics may vary according to individual leadership style. In addition, since management executive’s lateral influence is a form of project political behavior and to understand its dy- namics, a review of the leadership, politics, and interpersonal

1In terms of de-escalation, the issues of raising negative feedbacks on fail- ing project status and whether management is receptive towards the feedback apply to both IT and non-IT projects. Nevertheless, since the initial phase of de-escalation involves problem recognition, which in the case of construction projects, problems tend to be more visible as compared to IT projects, as a result warning signals from non-IT projects could be detected and potentially triggering the de-escalation process earlier.

influence literature could be useful in understanding the funda- mental role of influence behaviors in the de-escalation process.

B. Project Leadership, Politics, and Interpersonal Influence

A review of the leadership literature suggests that there are two main categories of leadership styles: transformational and transactional. Transformational leadership style that comprises traits of charisma, individual consideration, and intellectual stimulation tends to inspire followers to exceed their own self- interest for the good of the team [3]. It strives to improve the confidence and motivation of followers to obtain performance beyond expectations. Transactional leadership style that com- prises traits of contingent reward and management by exceptions is based on a series of exchange between leader and follow- ers [3]. Transactional leaders clarify followers’ role and things to be done to obtain designated outcomes. Behaviors and traits of followers are influenced by incentives offered by leaders. Table II provides a summary of leadership styles, and their re- spective traits and descriptions.

In project context, project leaders influence team effective- ness by motivating team members to collaborate and engage in problem solving [28]. It is believed that different types of project leadership styles may have varying influence on the IS project team performance [12]. It is common for project team leaders to resort to political behaviors other than authority [25] during project development. This is because projects often exist outside of the traditional line structure, and as a result, project leaders have to negotiate and bargain for resources to fund the projects. Furthermore, project leaders lack the authority to reward or pun- ish project team members; therefore, utilizing influence for the benefit of projects becomes common and relevant [44], [53]. It is through such use of political behaviors that project leaders put themselves in the position to most effectively influence the successful development of the projects [43].

Influence is the process by which people successfully per- suade others to follow their advice, suggestion, or order [25]. It is common for organizations to adopt influence tactics in their daily activities [23]. These tactics may include rational per- suasion, consultation, ingratiation, personal appeals, exchange, coalition tactics, and pressure. Yukl and Falbe [60] and Falbe and Yukl [11] further refined these tactics and showed how and why certain influence tactics are more often used in certain situations. These refinements were subsequently adapted by a group of IS scholars to examine how chief information officers should effectively influence their peers in achieving IS project success (see [8]). For example, during IS project development, projects that are aligned with the overall strategic direction of the organization tend to be more readily accepted than those that are not [9]. For those that are not aligned but still relevant to the organization, getting buy-in through enacting influence behaviors may prove useful in overcoming user resistance [18].

In summary, our reviews of the project escalation and de- escalation, leadership, politics, and interpersonal influence lit- erature have failed to identify any research that examines the process of management executives’ influence during project

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 111

TABLE I TRIGGERING ACTIVITIES AND CONDITIONS THAT PROMOTE DE-ESCALATION

112 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

TABLE II SUMMARY OF LEADERSHIP STYLES, AND THEIR RESPECTIVE TRAITS AND DESCRIPTIONS (ADOPTED FROM [25])

de-escalation situations. It is this knowledge gap that served as the main motivation of the study.

III. RESEARCH APPROACH

A. Research Strategy

This study aimed to undertake a qualitative case research [24] of an e-procurement project conducted in BMBC. The case study method was particularly appropriate for our study, since it allowed us to better capture and explain the management executive’s influence behaviors during the transition to de- escalation [33]. From the site-selection standpoint, BMBC has proven to be an interesting case to study. Basically, BMBC is a UK municipal borough with an elected council that serves a local population of 221 000 residents and provides a large range of services. The idea of electronic government originates from the UK central government’s 1999 white paper, Modernizing Government, which challenged all public sector organizations to achieve “citizen-centered services,” by integrating policies and programs, “joining-up” delivery, harnessing the power of IT, and getting the best out of staff. The overall champion for the electronic government initiative was the cabinet deputy of the council, who was assigned a special post known as the “E-envoy.” His main responsibility was to propel the electronic government initiative within BMBC. In UK, an E-envoy has sev- eral key responsibilities that include defining and implementing a government-wide IS strategy to support the public sector re- form agenda and also providing leadership and guidance on the electronic government initiatives. The project we studied formed part of BMBC’s ambitious plan to purchase its supplies using an e-procurement system.

B. Data Collection

The case illustrates an organization’s commitment evolution cycle from escalation to de-escalation of commitment to a new e-procurement system. Field research (on-site observations, in- terviews, and documentation reviews) was conducted over eight months (January 2002 to August 2002). A total of 17 inter-

views were conducted with 17 interviewees; as summarized in Appendix A (see Table VII), each session lasted one and a half hours. When we began our field research in January 2002, the council had just decided to continue and turn around the failing e-procurement project. It was in the midst of preparing its project turnaround strategies. Therefore, we were able to clearly capture the management executive’s influence tactics utilized during the transition to de-escalation. Data were collected mainly through personal interviews with several senior executives, IS person- nel, and users. Personal interviews were supplemented by direct observations and documents that include organization charts, articles in the business press, and internal documentation. In- terviews were based on topic guides, which indicated relevant probes at suitable junctures. Topic guides were customized for each interview. The list of sampled interview questions is shown in the Appendix A. In terms of meeting observations, the re- searcher took as many relevant notes as possible and added comments for clarification and completeness immediately after. These notes were also compared with the meeting’s agenda and minutes.

The interviews were retrospective and semi-structured in nature. The interviewees were asked to describe the IS de- velopment and specific comments for illustrating general observations were sought, but they were not asked to force their experiences into any pre-established categories. Particu- larly, subjects were encouraged to focus on critical events [35]. Historical reconstruction of event was subsequently performed by the field researcher. All interviews were tape-recorded and transcribed. These texts became the main corpus of the data used for subsequent analysis. Intersubject reliability was increased by using the narratives from one subject to confirm or contradict others in social triangulation [58]. But, there was no attempt to privilege one account over another. Overall, we judged that there was no overt attempt by the subjects to systematically conceal details or distort their stories. Where possible, we also tried to gather other documentary evidence to supplement the evidence gather from interviews. The use of documents alongside obser- vational data enabled a comparison between the researcher’s observation of events and other informed accounts. These

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 113

documents played a crucial role in establishing triangulation and in maintaining the chain of evidence [58].

C. Data Analysis

This study sought to use the rich insights available in the case. For any case, insights into the de-escalation process can only be obtained from thorough immersion into the transcripts for the case. We used the texts for preparing a detailed case description of events of the IS development process. This was done soon after completing the case study. The focus was on critical events that occurred during the project development. In order to reduce researcher bias and also to validate that no important event had been overlooked in the case summaries, a colleague was asked to take part in early analysis of some of the data. The colleague was uninvolved in the fieldwork and was therefore unfamiliar with the case. The role of this colleague was to establish objec- tivity [24]. The information he received did not include the field researcher’s list of critical events and decisions. Next, the col- league developed his own list of events. A senior IS researcher was also involved in commenting at later stages on the field researcher’s list of events. The purpose of this was to detect any bias in the research approach. Data from various sources coa- lesced and built a specific narrative that explained the process outcomes. We went through the interview transcripts several times and made changes where necessary. The next step of the analysis was to determine the factors that shape the E-envoy’s influence behaviors and the influence tactics he adopted at sev- eral critical junctures of the de-escalation process. We identified sentences that implied some degrees of influence have been ap- plied. For example, sentences like “we had to make it happen. The E-envoy was monitoring the progress constantly,” “we had to do it this time to secure our good relationship with the coun- cil,” and “but I had to do whatever the E-envoy wanted.” Besides the critical events, key decisions and respective decision makers were also identified. The key factors and influence tactics iden- tified were compared and contrasted against the de-escalation literature. The entire data-analysis process went through nu- merous iterations [24] to formulate a coherent and consistent overview of the case organization.

D. General Structure of the Process Model That Shapes the Influence Process During Project Development

In general, there are three factors that may shape the in- fluence process during project development. These factors are antecedent conditions, leadership style, and project politics dy- namics. Antecedent conditions may play an important role in shaping management executives’ lateral influence behaviors, since patterns of past interaction between project leaders and their subordinates tend to reproduce [36]. These conditions are essentially the outcomes of a whole history of prior interactions through projects, meetings, and communication activities, and most importantly, they may affect project leaders in interpreting information and decision-making [40].

Leadership styles play an important role in determining project development processes and outcomes. Whether it is transformational or transactional, the style of project leader-

ship has varying influence on the project team performance. This issue is particularly prominent during project crisis situ- ations, where time is tight and project direction is ambiguous, an effective leader with appropriate leadership style may steer the project team clear of troubled waters. Project politics can be broadly defined as actions taken outside the formal power structure on an individual that are “designed to influence others, especially those at higher levels, to promote or maintain one’s vital interests” [38]. It is imperative that there must be mu- tual trust and common interest among project stakeholders with compatible goals [4]. Political distrust among project stakehold- ers is likely to lead to stakeholders suspecting one another of ulterior political motives [44]. With political awareness, project managers can effectively remove conflicts among project team members and utilize incentive schemes to solicit “buy-in” from project stakeholders. Therefore, one can assume that the dy- namics of project politics, indeed, plays a pivotal role in project development and implementation. In the subsequent analysis section, we will be applying these factors to our case in this study. We aim to examine their roles in the de-escalation influ- ence process and identify several influence tactics used in the process. Fig. 1 shows a process model of factors that determine project managers’ influence behaviors during project develop- ment. Before the analysis, we will first present the BMBC case in the following section.

IV. CASE STUDY DATA: THE E-PROCUREMENT SYSTEM AT BMBC

This section presents background information about BMBC and its e-procurement system. The case data are presented in various phases to provide a better understanding of the project stakeholders, and sequence of actions/decisions associated with de-escalation [33]. The phases are: 1) problem recognition; 2) reexamination of prior course of action; 3) search for alternative course of action; and 4) implementing an exit strategy.

A. Project Development Process

The role of the IS department within the council was to pro- vide general guidance on information technology issues for the whole organization. The council had a history of poor project development success. According to the IS strategic project man- ager: “There had been very low success rates in terms of hitting the target dates and cost. Below 70 percent of our projects were completed on time. Probably, less than 60 percent com- pleted within the original budget. In terms of how many of these projects actually delivered benefits, it was only around 40 percent. Besides, we also had 15 to 20 percent of abandoned projects.” When asked why the council had achieved so little success in project development, the IS strategic manager ex- plained: “Basically, a local government could be very different in its working culture from private sector companies. The cul- ture here had been more laid back and less deadline-driven. Furthermore, project failure was viewed by the senior manage- ment as unavoidable, and had gradually become an acceptable norm.”

114 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

Fig. 1. Process model of determinants of project managers’ influence behaviors.

In 2000, there was a need to revamp the existing purchasing function in order to meet the target set within the e-government strategy plan that 100% of the supplies purchased by the coun- cil had to be purchased electronically by 2005. Besides that, there were other considerations for the BMBC to implement the e-procurement system. These reasons included improving purchasing efficiency, setting up a cost-control mechanism, and a strong desire to be the first local council in the UK to purchase goods and services electronically. The council head gave full support for the project and the 12-month project was launched in January 2001 with an initial estimated cost of £150 000. The project was headed by the IS manager, who was supervised by an e-procurement committee formed by a group of senior managers within the council. An external software vendor, se- lected through a bidding system, helped to develop the software. Other key stakeholders include the internal users of the system, such as the chief procurement officer, corporate service man- ager, corporate affairs manager, technical service manager, and the e-business manager. External users would include the goods and services suppliers.

The project faced several problems during its early stage of development. The main problem concerned conflicts among the IS project manager, the users, and the IS contractor over de- sign issues. On the one hand, internal users complained about the low quality of the software prototype and the failure of the contractor to understand their requirements. On the other hand, the IS project manager and the IS contractor were dissatisfied with the indecisiveness of the users and pinpointed their fre- quent requests for design change as the main reason for delay- ing project development. The project is initially stalled due to a disagreement between the users and the IS contractor. It started when the IS contractor demanded an additional £150 000 for “redesigning the software again.” Their reason was that since the contract price was “fixed,” any changes to the software after the users signed off the earlier versions of software prototypes were chargeable. The reason why the IS contractor asked for 100% of the original cost for the cost of redesign, was because

it had anticipated the users to make many more rounds of modi- fications to the requirements. However, the users disagreed with their claim because they viewed these changes as alterations resulting from the contractor’s mistakes, rather than additions requested by them. Eventually, the e-procurement steering com- mittee intervened and agreed to make the additional payment.

After the committee’s intervention, the project continued for another two months before it finally collapsed. The same prob- lems resurfaced and the users refused to continue participation in project development. Instead, they proposed the purchase of e-procurement packaged software. At the same time, the IS project manager seemed to lose control of the project and was busy haggling with the IS contractor over the issue of what re- quests were categorized as “additions” or “alterations.” Despite this dire situation, the e-procurement committee did not inter- vene directly, except for insisting to the users that the project had to be continued. However, they did promise more resources. While the users were resolute about project abandonment, the IS project manager insisted that they should continue. He ex- plained: “How could we give up? With all the resources invested, the option of reverting back to buying packaged software was unimaginable.” At this stage, the project had already exceeded £300 000 and was six months behind schedule. Apparently, the IS contractor was billing for changes made on an on-going basis plus the fees for engaging a subcontractor, who specialized in system integration.

B. De-Escalation Process

1) Phase 1 (Problem Recognition): With both camps debat- ing on whether the project should continue, the corporate affairs manager decided to blow the whistle on the failing project by reporting to the E-envoy regarding the stalled project situation. She explained her whistle-blowing decision, “I strongly felt that the involvement of the E-envoy would shake things up. Besides, we had a very open culture, I was confident by blowing the whis- tle would not cost anyone his/her job.” The IS project manager was asked to comment on the corporate affairs manager’s act

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 115

of whistle blowing, “It came as a relief for me. Seriously, I was surprised by her action, but I was not offended at all. It might well offer a solution for this entanglement. At that point, it was really beyond my level of authority to make the major decision on the project direction.” In late December 2001, the E-envoy was informed of the project problems and was surprised at the gravity of the problems. He explained why the news came as a surprise to him, “I had delegated the e-procurement steering committee to lead the project. Besides, even at the bimonthly management meetings over the past few months, the committee members did not inform me of any problems arising.” Imme- diately, he delayed the development project indefinitely, until a decision had been made. “Clearly, the prototype had not met the requirements of the users. It would be better to stop the project temporarily than to rush to launch it and having it shut down later.”

Decision 1 (Reaffirm the E-envoy’s Commitment): To resolve the problems, the E-envoy gathered all internal and external stakeholders, including representatives from the IS contractor and the goods and services suppliers, to reaffirm his commitment to the project. He commented, “It was important for everyone to understand my standpoint, especially in that state of confusion. Besides, we needed everyone’s effort to turn the failing project around.” The E-envoy had stated a strong desire for the project to be continued, promising full support for three reasons. First, the savings that could amount to several million pounds every year. Second, a successful implementation of the e-procurement system would enable itself as a role model among local coun- cils. Third, lucrative returns from selling the software to other councils whom were interested to follow suit in implementing the system. The E-envoy spoke of his determinations to proceed with the project development, “The project had to go on, and it was definitely in the right direction for the council. At that time, I had strong belief that we could still succeed by making some changes.” When asked for his reaction after the meeting, the chief procurement officer replied, “We had to follow the E-envoy’s decision. But, it would be interesting to see how we could turn it around after so many attempts.” The IS contractor also supported the E-envoy’s decision, “This time we would re- ally like to put things right. It was important for us to leave a positive impression for future business with the council.”

2) Phase 2 (Reexamination of Prior Course of Action): Once the decision to continue the troubled project had been de- cided, the E-envoy organized a focus group meeting with the e-procurement steering committee, the IS project manager, the user managers, and the IS contractor to reexamine their previ- ous problems for the first time. With the E-envoy’s presence and participation, everyone showed great enthusiasm in the meeting. At the beginning of the meeting, the E-envoy delivered a speech to explain the significance of the meeting. When asked about the speech, the E-envoy commented, “I simply assured them that no individuals would be punished in this project. I also stressed that turning around the failing project was our utmost priority in order to salvage our reputation and the confidence the external constituencies had in us.” The assurance from the E-envoy was well received by everyone present in that meeting as they began to discuss their differences openly. They were

unafraid of highlighting their own mistakes and were focused on problem solving. In that meeting, several problems were identified.

Decision 2 (Invite External Observers to Scrutinize the Project Turnaround): In January 2002, after having consulted the E-envoy, the strategic director accepted our proposal to study their e-procurement project development and implementation process. When asked why we were allowed to be involved at that sensitive stage, the E-envoy replied, “I wanted this project to be a learning lesson for everyone in this council. Furthermore, it would keep everyone on their toes, since we were going to have outsiders monitoring our turnaround effort. I was very sure this would have positive efforts on them.” When asked whether our presence altered any of their decisions, the IS project manager commented, “I had to admit that it did make several of us work- ing under pressure. We had to make sure that the turnaround was a success.”

3) Phase 3 (Search for Alternative Courses of Action): Hav- ing identified the problems, the whole team started to explore alternative courses of action. For the first time, with the partic- ipations of the E-envoy and the e-steering committee, the three groups (the user managers, the IS project manager, and the IS contractor) started to cooperate and work toward a common goal. They began to look for solutions to rectify their problems found in the earlier development process. In order to prevent a full-blown project failure, the E-envoy intended to salvage some project development costs by suggesting the adoption of a partial abandonment strategy. The plan was to reduce the orig- inal scope of the project without causing significant changes to the project’s original specification. For this reason, three user departments were shortlisted as the pilot sites, hence allowing the IS project manager to deal with the needs of only three user departments, rather than eight departments formerly.

Furthermore, the project had been separated in three stages. Instead of implementing full-scale procurement functions all at one go, the first stage would now focus on the “front purchas- ing process,” which included only ordering, issuing of purchase orders, and delivery of items. The e-envoy concluded, “By re- ducing the scope, certainly enhanced our chances of success. Adopting partial abandonment was better than having a full- blown escalation or a total abandonment with zero return.” Sensing the E-envoy’s determination to succeed, all relevant parties arrived at a multilateral consensus to draw up a list of turnaround plans. The list is summarized in Table III.

Decision 3 (Gather stakeholders’ commitment): In February 2002, the E-envoy ordered a stakeholder scanning before carry- ing out the action plans. The purpose was to find out whether all internal and external constituencies fully supported the de- vised turnaround strategies. The E-envoy reckoned that a new stakeholder analysis must be performed, since actors involved in the development process could still be strongly committed to prior course of action. The e-procurement steering commit- tee members carried out the stakeholder analysis. The reactions from various stakeholders were summarized in Table IV.

The e-procurement steering committee members spent con- siderable time in convincing those actors, who still seemed to be doubtful to accept the new plans.

116 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

TABLE III LIST OF PROBLEMS IDENTIFIED IN THE EARLIER DEVELOPMENT PROCESS AND REMEDIES PLANNED AS PART OF THE TURNAROUND STRATEGIES

TABLE IV STAKEHOLDERS’ REACTIONS TO THE NEW COURSE OF ACTION

4) Phase 4 (Implementing an Exit Strategy): By late Febru- ary 2002, the E-envoy ordered the implementation of the turnaround tactics. The turnaround required all project stake- holders’ cooperation and support. The E-business manager was asked how she managed to reassure the suppliers, “In order to gain their support, we announced that the priority of our

allocation of future businesses would be given to suppliers par- ticipating in our e-procurement system. With the guarantee of more business, many suppliers expressed their support toward the project completion.” The chief procurement officer and his department were relieved that the suppliers were fully behind the e-procurement project again. When asked whether faced

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 117

TABLE V SUMMARY OF THE PROJECT PHASES, DECISIONS AND CHANGE PROCESSES IDENTIFIED IN THE E-PROCUREMENT PROJECT AT BMBC,

AND THE RESPECTIVE ACTIONS TAKEN

with any problem during the strategy implementation, he com- mented, “We were able to directly clarify the problems with the IS contractor, which was so much easier. Everyone also seemed to be more committed. It used to be at least two people missing from project meetings, but not anymore.” The IS project man- ager also commented on the implementation of the de-escalation plans, “The team members seemed to work for one another. The new team sent by the contractor also impressed me. They came at least twice a week to discuss the changes. This really saved us a lot of time and enhanced the communication process.”

Decision 4 (Pulling the Plug on the Escalating Contract Pric- ing): The council had the option to hire new IT consultants. Much to everyone’s surprise, the E-envoy struck a deal with the same contractor to replace the previous team with a team of senior consultants. To repay the council’s trust in them, the contractor had offered a “no further charge” deal for subsequent changes made to the prototype. Under the new arrangement, the contractor would not charge the council any further cost until the project completion. Furthermore, a senior director from the contractor was put in charge of the e-procurement project and had assured the E-envoy of a turnaround success.

C. Consequence: The End of Crisis

When the e-procurement system finally went “live” in August 2002, it was eight months behind schedule and £500 000

over original budget. The relatively smooth implementation af- ter the adoption of the turnaround tactics meant that the crisis concerning the e-procurement project was over.

D. Case Analysis

De-escalation is a complex and gradual process, and manage- ment executives play key roles in facilitating the de-escalation strategy [16], [46]. Therefore, understanding the process of how management executives influence project stakeholders to sur- render their commitment to previous failing courses of action, and subsequently, jointly agreeing to an exit strategy becomes critical in the de-escalation process. Simply put, an actor’s change in commitment may involve three phases [27]: un- freezing, changing, and refreezing. Commitment change may be viewed as a multistage process, and all stages must be nego- tiated before a stable change can be said to have taken place [55]. Table V summarizes the project phases, decisions, and change processes identified in the e-procurement project at BMBC and the respective actions taken.

E. Factors That Shape Management Executives’ Influence Behaviors in BMBC

Our case analysis suggests the three key factors: antecedent conditions, leadership style, and project politics dynamics, in- deed, played an important role in the de-escalation influence

118 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

process of our case study. The role of antecedent conditions was demonstrated through the open corporate culture and the high tolerance toward IS project failure, as suggested in previous project experiences, which all could explain why the E-envoy at BMBC adopted supportive and reassurance strategies toward the project team despite the failing project situation. This is a sharp contrast with many organizations, where threats and re- taliations are often initiated when dealing with failing projects that left ill feelings and fear among project team members [10]. Such behaviors may hurt project team members’ morale and it is unsurprising many of such projects are eventually aban- doned [40]. Therefore, it is important to cultivate appropriate culture, develop acceptable project expectations, and overcome previous conflicts or differences among project team members before de-escalation can succeed [36].

The role of leadership style was demonstrated through E-envoy’s swift and decisive action in promoting the de- escalation effort, which proved to be catalytic in improving the unity and cohesion of the project team during the de-escalation process. The finding is in accordance to Augustine’s [1] recom- mendation that it is useful to rapidly dispatch the management executive to the crisis scene because the involvement of se- nior management adds weight to the significance of a crisis response operation. In our view, the E-envoy had adopted a hybrid leadership approach that comprises some characteristics of both transformational and transactional leadership styles [3]. For example, in the initial phases of de-escalation, the E-envoy encouraged the project team to reconsider the problems and come up with alternatives. This behavior reflects the intellectual stimulation trait of a transformational leader that emphasizes problem solving and new way of thinking [25]. At the same time, the E-envoy agreed to grant the suppliers priority status when allocating future business contracts in exchange for their continued support in the de-escalation process. Such reassur- ance was instrumental in gaining overwhelming support from the suppliers for the new course of action. Here, the E-envoy clearly demonstrated contingent reward trait of a transactional leader [3]. Overall, the hybrid leadership style prompted and improved the efficiency and interoperability of the deployment of de-escalation activities.

Finally, the role of project politics dynamics was also proven important in our case. Apparently, the E-envoy was explicit about why the troubled project had to be turned around, and also reiterated the benefits of project success, hence removing project team members’ doubts on his commitment toward de-escalating the troubled project. This commitment reassurance was crucial as failure to fulfill this part is likely to lead to disintegrated efforts for the project team and endangered the de-escalation effort. Furthermore, the expectations of stakeholders are estab- lished based on early impressions they form about the goals of a change initiative and by their initial understanding of how the proposed changes are to be achieved [13]. Therefore, project leaders may consider actively promoting change initiative, of- fering incentives, and in return, garnering as much support from the stakeholders as possible. In our case, the new course of action was promoted as a win–win situation, where all related parties stand to benefit by supporting the project turnaround [31]. Be-

ing politically sensitive, the E-envoy acquired and retained the project stakeholders’ support by minimizing their antagonism toward the troubled project and conflicts among the project team members. He considered various stakeholders’ perspectives by conducting a stakeholder assessment before implementing the de-escalation strategies. This tactic proved to be crucial in un- derstanding and getting “buy-in” from the project stakeholders during project turnaround.

F. Management Executives’ Lateral Influence Tactics

An analysis of our case suggests the adoption of six major de-escalation influence tactics in the unfreezing, changing, and freezing phases of de-escalation either separately or collectively. They are agile mobilizing, provision of psychological safety, consultation, personal appeals, reestablishing legitimacy and stakeholder commitment, and continuous empowerment. These influence tactics, their respective de-escalation phases and the supporting case evidence are shown in Table VI and discussed in the following sections.

Our case analysis indicated the presence of the influence tactics in various phases of the de-escalation process. We will next discuss the six de-escalation influence tactics in detail.

1) Agile Mobilizing: Once a project crisis is identified, if intervention is the only solution, it must be executed in an un- wavering and timely fashion, since the longer decision makers are engaged in searching for optimality, the larger the risk that crisis events will spiral out of control [1]. Furthermore, by not responding rapidly to address the project problems, mobilizing project teams to involve in any project turnaround effort is going to be increasingly difficult, since there will be growing frustra- tion and declining morale among the project stakeholders [40]. For agile mobilization to take place, first it is important to under- take the task of resolute informing. In our case when the E-envoy was informed of the project escalation situation, he immediately called a timeout on the project development. He communicated to the project team to investigate the problems and seek their support in turning around the project. Throughout this transi- tion period, project team members are continuously engaged in acquiring and exchanging information related to implementing the de-escalation activities. The outcome proved that resolute informing is one of the key success factors in responding to the project crisis effectively [1]. In addition, it is important to note that the project team members’ previous collaborative working relationships had significantly enhanced the mobilization effort, since the preexisting project coordination structure and proto- col had provided the stability necessary for rapid mobilization to occur [29].

2) Provision of Psychological Safety: The creation of psy- chological safety, either by removing barriers to change or by eliminating the threat inherent in past failures, can motivate change [48]. Weick and Quinn [56] suggest that a change agent plays a crucial role in providing actors a sense of security. This is important since actors are willing to surrender their prior failing courses of action and accept alternative course of ac- tion only if strong sense of security is present. As such, it is vital for project leaders to provide psychological safety when

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 119

TABLE VI LIST OF DE-ESCALATION INFLUENCE TACTICS ADOPTED IN VARIOUS DE-ESCALATION PHASES AND THE RESPECTIVE SUPPORTING EVIDENCE

FROM THE BMBC CASE

120 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

handling project failing situations. One way may be to reduce the severity of penalties or remove punishment completely owing to failure. This is to mitigate continued commitment to failing course of action [21], [35] and encourage early introduction of de-escalation strategies.

In the case of BMBC, the E-envoy adopted a proactive col- lective approach of resolving the crisis. His main emphasis was on restoring the cohesion of the project team. His assurance that no individuals would be punished for earlier problems came as a significant relief for project team members, hence encouraging them to openly discuss their shortcomings in the earlier project development process. It was only then the project team mem- bers started to cooperate and work toward turning around the troubled project. However, it must be pointed out that it was dif- ficult for the project members to balance painful disconfirming messages with the reassurance that change was possible; as our interview data indicate: “It also took several of us quite a while to restore our confidence that a turnaround was indeed possible.” Clearly, this resembles Montealegre and Keil’s [33] description of a gradual consensus-building process. This is also consistent with Heng et al.’s [16, p. 108] suggestion that “superiors and peers may play a role (by providing assurance) to help indi- viduals de-escalate their commitment to software development projects that have poor prospects for success.”

3) Consultation: Yukl [59] defines consultation as the agent seeking target participation in planning a strategy, activity, or change for which target support and assistance are desired, or is willing to modify a proposal to deal with target concerns and suggestions. By consultation, it means broader cooperation between stakeholders engaged to achieve jointly agreed out- comes, which includes a broader range of stakeholders and far greater flexibility. This also implies a commitment to proac- tive partnering that goes beyond fine words and good intentions and implies a willingness to risk sharing. In the BMBC case, consultation tactic was adopted in the unfreezing and changing phases of de-escalation in which all project team members were involved in jointly reviewing project problems and identifying the alternative course of actions [30].

The E-envoy encouraged a cohesive culture by gathering all project stakeholders and consulted their opinions on prior course of action. With an open and forgiving culture, project team mem- bers were open about their mistakes. The E-envoy also promoted teamwork by gathering the entire project team to brainstorm for turnaround strategies. By adopting a consultative approach, it helped to legitimize the new course of action, since it was a joint decision among the project stakeholders. From the de- escalation literature, we are aware that consensus building can play a role in promoting de-escalation of commitment. For ex- ample, in the Denver International Airport case, Montealegre and Keil [33] have shown that engaging in a consensus-building process with the various internal and external project stakehold- ers of the project is an important factor when implementing an exit strategy. Interestingly, the BMBC case differs from the Denver International Airport case on the timing of consensus building, since it started the consultation at the beginning of the de-escalation phase when project stakeholders were asked to reexamine the prior course of action, rather than at later

implementation phases, as in the case of Denver International Airport.

4) Personal Appeals: Large IS projects may involve both internal and external project stakeholders, who could present great obstacles to de-escalation [33]. For example, in the case of CONFIG, Keil [21] highlighted that the company CompuSys ap- pealed to external constituencies, such as customers and share- holders, to convince them that CONFIG was a successful lead- ing edge system to improve customer service. Keil’s findings from his escalation study indicate that appealing or justifying to external project stakeholders is likely to increase the commit- ment to a failing course of action. Similarly at BMBC, personal appeal was also enacted. Nevertheless, it was utilized in the changing phase of de-escalation, instead of the escalation pro- cess in Keil’s study. During the commitment change transition, much persuasion had to be initiated to aggressively win over the project stakeholders to commit to the new course of action. In our case, the E-envoy appealed to feelings of loyalty from the IS contractor and the suppliers toward the council, by promis- ing them a larger portion of future business opportunities. Both external parties responded to his appeal by fully cooperating in carrying out the de-escalation strategies. E-envoy’s behav- ior was consistent with Montealegre and Keil’s [33, p. 438] de-escalation study, which suggested a de-escalation tactic of making “direct appeals to internal and external constituencies in order to negotiate and implement an exit strategy with their help, if possible” [45]. Overall, our finding reaffirms the impor- tant role played by personal appeals in both project escalation and de-escalation situations.

5) Reestablish Legitimacy and Stakeholder Commitment: Legitimacy is defined as a psychological property of an au- thority or institution that leads those connected to it to believe that it is appropriate and proper [54]. With legitimacy, people follow the rules voluntarily out of obligation rather than out of fear of punishment, which increases the effectiveness of project crisis containment. Durand and Mcguire [7] argue for the need to maintain legitimacy among existing constituents and estab- lishing legitimacy in a change initiative. Augustine [1] suggests that such legitimacy may bring about stakeholder support dur- ing project crisis mitigation. In the case of BMBC, reestablished legitimacy was adopted in the changing–refreezing phases of de- escalation. Here, the focus was to reinforce the importance of changing commitment and institutionalizing the new course of action. The E-envoy’s resolute informing strategy during the de- escalation process was the first step toward legitimizing the new course of action. By having an open and direct communication, the project stakeholders were made aware of the gravity of the project situations. The E-envoy’s declaration of his commitment in rescuing the troubled project further enhanced “buy-in” from project stakeholders in the project turnaround effort.

In addition, the E-envoy was able to put together a recov- ery plan within a short time, which helped to restore some of the lost credibility, rebuilt trust in the team’s ability to com- plete the project, and obtained renewed legitimacy from project stakeholders. Overall, reestablishing legitimacy and stakeholder support quickly during de-escalation have proven to be impor- tant, since mishandling the troubled situations is likely to turn

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 121

into a “legitimacy crisis,” where existing stakeholders with- draw support and loyalty to project leaders [37]. Interestingly, reestablishing legitimacy has not been discussed in existing de- escalation literature and our finding has certainly suggested its importance, which probably deserves more research attention in future.

6) Continuous Empowerment: To sustain any change initia- tive, empowerment is useful in developing and communicating a coherent and shared vision throughout the organization [3]. Similarly in the case of BMBC, continuous empowerment was evident in the refreezing phase of de-escalation. By empowering the appropriate project stakeholders, it showed complete man- agement support in the new course of action. The E-envoy kept faith with the same team of project members and IS contrac- tors, and empowered them with autonomy to make decisions in the project turnaround. This has helped the project team signifi- cantly in regaining confidence, determination, and commitment to rectify the original project problems and achieve its original goal of developing the first e-procurement system in the UK public sector at that time. Overall, continuous empowerment fostered commitment and resulted in better coordination and fewer execution difficulties in the turnaround process.

V. IMPLICATIONS AND CONCLUSION

The findings of this study have several research and practi- cal implications. For research, this study answers the call by earlier de-escalation scholars (i.e., [33]) to examine cases on IS project turnaround—especially those that involve in-depth case studies—are clearly called for, so that the IS research com- munity may have a deeper understanding of the de-escalation phenomenon in various contexts. Furthermore, most of the pre- vious case studies on escalation found continual escalation until the eventual cancellation of the project. In this paper, we have shown that organizations may respond differently to project es- calation by adopting a project recovery approach. In addition, this paper makes a major contribution by providing a process perspective to examine commitment transformation during the transition from escalation to de-escalation. Particularly, we have identified three key factors that may shape management exec- utives’ influence behaviors and six relevant influence tactics in a de-escalation process. In this study, we adopted leader- ship, politics, and interpersonal influence theories as theoretical lenses. By applying these theories to examine the de-escalation phenomenon, we extended existing de-escalation literature by including new theoretical angles to explore the de-escalation phenomenon. Our influence tactics may encourage more or- ganizations to consider redirecting troubled projects in future, hence reducing the cost of failure—an area which has been iden- tified important, but remained largely unaddressed in the project escalation literature.

The de-escalation influence process and the influence tac- tics presented in this paper are grounded in the process that unfolded at BMBC and we believe that our findings can be generalized to other similar public sector organizations. Never- theless, a limitation of this study perhaps is the failure to apply our constructs to similar de-escalation scenarios in private sec-

tor setting. This is due to limited-access opportunity in these organizations, especially when the study centers on troubled IT projects. Further studies are clearly needed to apply the influ- ence tactics to other project de-escalation contexts, especially in private sector organizations. It will be interesting to find out if there is any difference between public and private sec- tor organizations in deploying these influence tactics in similar situations. Future research should also seek to formulate more generalizable explanations as to why certain influence tactics lead to certain outcomes at various de-escalation stages, or why certain interventions lead either to success or further project escalations.

For practice, the BMBC case underscores the need for project leaders to be aware of the important roles played by project stakeholders in de-escalation and ways of gaining their commit- ment toward the new course of action. First, partial abandonment emerges to be a very useful turnaround strategy for avoiding project failure. Partial abandonment helps to salvage some in- vestment costs and avoids the embarrassment of a project failure. There is absolutely no reason for project leaders to consider only all-or-nothing decisions. Partial abandonment offers a compro- mise between abandonment and project continuation. Second, management executives should closely monitor the progress of the de-escalation efforts. Such close monitoring of the de- escalation phases would act as an early detecting mechanism and reduce the risks associated with failure. This also forms part of a pressure tactic to influence project team members to be fully committed to the de-escalation strategies. Third, manage- ment executives should explicitly motivate project stakeholders to support the project turnaround. This is important since the initial enthusiasms and confidence in the project may have been exhausted by the earlier failure; therefore, more efforts must be made to restore the project executives and other stakehold- ers’ confidence and interest in the project. Finally, the study demonstrates that emphasizing the values of persistence and de- termination help in obtaining a project turnaround success. Un- doubtedly, it might be exposed to further risks associated with escalation. But without total commitment from relevant project stakeholders in carrying out effective de-escalation strategies, project failure becomes inevitable.

Given that escalation is a common problem among IS projects, it is therefore important to understand how project leaders can redirect troubled IS projects in entrapment situa- tions. The BMBC case underscores the need for project leaders to be aware of barriers threatening the commitment transfor- mation from failing course of action to an alternative course of action. Overall, this study provides a much-needed empirical insights into the formation and execution of a project stakehold- ers’ influence strategy in an IS project de-escalation context. In particular, the development of a set of effective de-escalation influence tactics that could help to extricate themselves from future escalation predicaments.

APPENDIX A

See Table VII.

122 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58, NO. 1, FEBRUARY 2011

TABLE VII INTERVIEW SCHEDULE FOR THE CASE OF BMBC

A. Sampled Interview Questions

1) Please provide the background information of the project (who initiated the project, its objective, who was involved, the budgeted project cost and estimated completion dead- line, and the project scope?). Who made the decision to adopt in-house developed software rather than packaged software?

2) How did you identify your project stakeholders? Under- stand project stakeholders’ varying perceptions toward the new system. Identify any difference in the level of com- mitment.

3) What were the antecedent conditions? Assess the project management history within the organization. Assess the reward and punishment structure of the organization. Did the team have adequate access to organizational resources?

4) Discuss various critical incidents that affect the progress of the project and how it went into trouble. Was the project well managed? Why did the decision maker continue the project despite the problems? Explain the meaning of es- calation to interviewees. Did anyone observe the ‘cycles of escalation’ during the project development? If yes, was anything done to stop the escalation cycle?

5) Did everyone agree to continue with the project? Was project status accurately and consistently fed back to se- nior management? Was there any project audit during the development process?

6) The troubled project had to continue. Why? What was the project group’s initial reaction? Were they supportive? Was there any departure of the project members or key stakeholders during the project? Identify the commitment differentials among the project group members.

7) How did the management convince the project stakehold- ers to surrender the commitment to previous failing course of action, change and accept the new course of action?

REFERENCES

[1] N. Augustine, “Managing the crisis you tried to prevent,” Harv. Bus. Rev., vol. 73, pp. 147–158, Nov./Dec. 1995.

[2] S. Barton, D. Duchon, and K. Dunegan, “An empirical test of Staw and Ross’s prescriptions for management of escalation of commitment be- haviour,” Decis Sci., vol. 20, pp. 532–544, 1989.

[3] B. Bass, Leadership and Performance Beyond Expectations. New York: Free Press, 1985.

[4] R. Block, The Politics of Projects. New York: Yourdon, 1983. [5] D. Conlon and H. Garland, “The role of project completion in resource

allocation decisions,” Acad. Manage. J., vol. 36, no. 2, pp. 402–413, 1993. [6] H. Drummond, “The politics of risk: Trials and tribulations of the Taurus

project,” J. Inf. Technol., vol. 11, pp. 347–357, 1996. [7] R. Durand and J. McGuire, “Legitimating agencies in the face of selection:

The case of AACSB,” Org. Stud., vol. 26, no. 2, pp. 165–196, 2005. [8] H. Enns, S. Huff, and C. Higgins, “CIO lateral influence behaviours: Gain-

ing peers’ commitment to strategic information systems,” MIS Quart., vol. 27, no. 1, pp. 155–177, 2003.

[9] J. Esteves, J. Pastor, and J. Casanovas, “Monitoring business process redesign in ERP implementation projects,” in Proc. Eighth Amer. Conf. Inf. Syst., Dallas, TX, Aug. 9–11, 2002, pp. 865–873.

[10] K. Ewusi-Mensah, “Critical issues in abandoned information systems de- velopment projects,” Commun. ACM, vol. 40, no. 9, pp. 74–80, 1997.

[11] C. Falbe and G. Yukl, “Consequences for managers of using single in- fluence tactics and combinations of tactics,” Acad. Manage. J., vol. 35, no. 3, pp. 638–652, 1992.

[12] S. Faraj and V. Sambamurthy, “Leadership of information systems devel- opment projects,” IEEE Trans. Eng. Manag., vol. 53, no. 2, pp. 238–249, May 2006.

[13] G. Gallivan, “Meaning to change: How diverse stakeholders interpret organisational communication about change initiatives,” IEEE Trans. Prof. Commun., vol. 44, no. 4, pp. 243–266, Dec. 2001.

[14] H. Garland, C. Sanderfur, and A. Rogers, “De-escalation of commitment in oil exploration: When sunk costs and negative feedback coincide,” J. Appl. Psychol., vol. 75, no. 6, pp. 721–727, 1990.

[15] M. Gundlach, S. Douglas, and M. Martinko, “The decision to blow the whistle: A social information processing framework,” Acad. Manage. Rev., vol. 28, no. 1, pp. 107–123, 2003.

[16] C. Heng, B. Tan, and K. Wei, “De-escalation of commitment in software projects: Who matters? what matters?” Inf. Manage., vol. 41, no. 1, pp. 99–110, 2003.

[17] K. Howe and G. McCabe, “On optimal asset abandonment and replace- ment,” J. Financ. Quant. Anal., vol. 18, no. 3, pp. 295–305, 1983.

[18] J. Jensen, “Getting one’s way in policy debates: Influence tactics used in group decision-making settings,” Public Admin. Rev., vol. 67, pp. 216– 227, Mar./Apr. 2007.

PAN AND PAN: TRANSITION TO IS PROJECT DE-ESCALATION 123

[19] A. Juliusson, “Optimism as modifier of escalation of commitment,” Scand. J. Psychol., vol. 47, pp. 345–348, 2006.

[20] J. Jiang, W. Muhanna, and G. Klein, “User resistance and strategies for promoting acceptance across system types,” Inf. Manage., vol. 37, pp. 25– 36, 2000.

[21] M. Keil, “Pulling the plug: Software project management and the problem of project escalation,” MIS Quart., vol. 19, no. 4, pp. 421–447, 1995.

[22] M. Keil and D. Robey, “Turning around troubled software projects: An exploratory study of the de-escalation of commitment to failing courses of action,” J. Manage. Inf. Syst., vol. 15, no. 4, pp. 63–87, 1999.

[23] D. Kipnis, S. Schmidt, and I. Wilkinson, “Intraorganizational influence tactics: Exploration’s in getting one’s way,” J. Appl. Psychol., vol. 65, no. 4, pp. 440–452, 1980.

[24] H. Klein and M. Myers, “A set of principles for conducting and evaluating interpretive field studies in information systems,” MIS Quart., vol. 23, no. 1, pp. 67–94, 1999.

[25] B. Keys and T. Case, “How to become an influential manager,” Acad. Manage. Exec., vol. 4, no. 4, pp. 38–51, 1990.

[26] M. Leatherwood and E. Conlon, “Diffusibility of blame: Effects on per- sistence in a project,” Acad. Manage. J., vol. 30, no. 4, pp. 836–847, 1987.

[27] K. Lewin, Field Theory in Social Science. New York: Harper and Row, 1951.

[28] Y. Li, C. Tan, H. Teo, and B. Tan, “Innovative usage of information technology in Singapore organizations: Do CIO characteristics make a difference?” IEEE Trans. Eng. Manag., vol. 53, no. 2, pp. 177–190, May 2006.

[29] K. Lui and K. Chan, “Rescuing troubled software projects by team trans- formation: A case study with an ERP Project,” IEEE Trans. Eng. Manag., vol. 55, no. 1, pp. 171–184, Feb. 2008.

[30] M. Mähring and M. Keil, “Information technology project escalation: A process model,” Decis. Sci., vol. 39, no. 2, pp. 239–272, 2008.

[31] L. Markus, “Power, politics, and MIS implementation,” Commun. ACM, vol. 26, no. 6, pp. 430–444, 1983.

[32] B. McCain, “Continuing investment under conditions of failure: A labo- ratory study of the limits to escalation,” J. Appl. Psychol., vol. 71, no. 2, pp. 280–284, 1986.

[33] R. Montealegre and M. Keil, “De-escalating information technology projects: Lessons from the denver international airport,” MIS Quart., vol. 24, no. 3, pp. 417–447, 2000.

[34] R. Müller and R. Turner, “The influence of project managers on project success criteria and project success by type of project,” Eur. Manage. J., vol. 25, no. 4, pp. 298–309, 2007.

[35] M. Newman and R. Sabherwal, “Determinants of commitment to infor- mation systems development: A longitudinal investigation,” MIS Quart., vol. 20, no. 1, pp. 23–54, 1996.

[36] M. Newman, S. Pan, and G. Pan, “Why can’t we bet on ISD outcomes?: ISD “Form” as a predictor of success,” presented at the Int. Conf. Inf. Syst. Dev., Paphos, Cyprus, 2008.

[37] J. O’Connor, The Meaning of Crisis. New York: Basil Blackwell, 1987. [38] K. Overton and M. Frolick, “Politics of implementing EISs,” J. Inf. Syst.

Manage., vol. 13, pp. 50–57, 1996. [39] G. Pan, S. Pan, and D. Flynn, “De-escalation of commitment to infor-

mation systems projects: A process perspective,” J. Strategic Inf. Syst., vol. 13, no. 3, pp. 247–270, 2004.

[40] G. Pan and S. Pan, “Examining the coalition dynamics in affecting IS project abandonment decision-making,” Decis. Support Syst., vol. 42, no. 2, pp. 639–655, 2006.

[41] G. Pan, S. Pan, and M. Newman, “Managing information technology project escalation and deescalation: An approach-avoidance perspective,” IEEE Trans. Eng. Manag., vol. 56, no. 1, pp. 76–94, Feb. 2009.

[42] C. Park, M. Keil, and J. Kim, “The effect of IT failure impact and personal morality on IT project reporting behaviour,” IEEE Trans. Eng. Manag., vol. 56, no. 1, pp. 45–60, Feb. 2009.

[43] J. Pinto, Power and Politics in Project Management. Newtown Square, PA: Project Management Institute, 1996.

[44] J. Pinto, “Understanding the role of politics in successful project manage- ment,” Int. J. Project Manage., vol. 18, pp. 85–91, 2000.

[45] J. Ross and B. Staw, “Organizational escalation and exit: Lessons from the shoreham nuclear power plant,” Acad. Manage. J., vol. 36, no. 4, pp. 701–732, 1993.

[46] I. Royer, “Why bad projects are so hard to kill,” Harv. Bus. Rev., vol. 81, pp. 49–56, Feb. 2003.

[47] C. Sauer, L. Liu, and K. Johnston, “Enterprise-level project management capabilities: A comparison of the construction and IT services industries,” in Proc. Int. Conf. Inf. Syst., Charlotte, NC, 1999, pp. 440–445.

[48] E. Schein, Organizational Psychology. Eaglewood Cliffs, NJ: Prentice- Hall, 1988.

[49] I. Simonson and B. Staw, “De-escalation strategies: A comparison of techniques for reducing commitment to losing courses of action,” J. Appl. Psychol., vol. 77, no. 4, pp. 419–426, 1992.

[50] A. Snow, M. Keil, and L. Wallace, “The effects of optimistic and pes- simistic biasing on software project status reporting,” Inf. Manage., vol. 44, no. 2, pp. 130–141, 2007.

[51] Standish Group, Chaos Rep. [Online]. Available: http://standishgroup. com/quarterly_reports/, 2004. Accessed on June 16, 2009.

[52] B. Staw and J. Ross, “Behaviour in escalation situations: Antecedents, prototypes, and solutions,” in Research in Organizational Behaviour, T. G. Cummings and B. M. Staw, Eds. Greenwich, CT: JAI Press Inc., 1987, pp. 39–78.

[53] H. Thamhain and G. Gemmill, “Influence styles of project managers: Some project performance correlates,” Acad. Manage. J., vol. 17, pp. 216–224, 1974.

[54] T. Tyler, “Psychological perspectives on legitimacy and legitimation,” Annu. Rev. Psychol., vol. 57, no. 1, pp. 375–400, 2006.

[55] D. Wastell, P. Kawalek, and M. Newman, “Plus ca change: Defensive translations and resistance to IT-enabled change in local government,” presented at the Eur. Conf. Inf. Syst., Naples, Italy, 2003.

[56] K. Weick and R. Quinn, “Organizational change and development,” Annu. Rev. Psychol., vol. 50, pp. 361–386, 1999.

[57] G. Whyte, “Escalating commitment to a course of action: A reinterpreta- tion,” Acad. Manage. Rev., vol. 11, no. 2, pp. 311–321, 1986.

[58] R. Yin, Case Study Research: Design and Methods, 2nd ed. Newbury Park, CA: Sage, 1994.

[59] G. Yukl, Leadership in Organizations, 3rd ed. Englewood Cliffs, NJ: Prentice-Hall, 1994.

[60] G. Yukl and C. Falbe, “Influence tactics and objectives in upward, down- ward and lateral influence attempts,” J. Appl. Psychol., vol. 75, no. 2, pp. 132–140, 1990.

Gary Pan received the Ph.D. degree in informa- tion systems from the University of Manchester, Manchester, U.K.

He is currently an Assistant Professor at Singapore Management University, Singapore. His research interests include information technology (IT) project management and control and IT capa- bility development. He is the author or coauthor of various research papers published in the Management Information Systems Quarterly Executive, the IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, the

European Journal of Operational Research, the Journal of American Society Information Science and Technology, the Communications of the ACM, the In- formation and Management, the Decision Support Systems, the Information Systems Journal, the Journal of Strategic Information Systems, and the Com- munications of the AIS.

Shan Ling Pan received the Ph.D. degree in in- formation systems from the University of Warwick, Coventry, U.K.

He is currently an Academic Program Director of Strategic Technology Management Institute, Na- tional University of Singapore, where he is also an Associate Professor in the Department of Informa- tion Systems, School of Computing. He is the author or coauthor of various research papers published in the Information Systems Research, the MISQ Exec- utive, the IEEE TRANSACTIONS ON SYSTEMS, MAN,

AND CYBERNETICS, the IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, the IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, the Journal of the American Society for Information Systems and Technology, the Journal of Academy of Marketing Science, the European Journal of Opera- tions Research, the European Management Journal, the Journal of Operational Research Study, the Communications of ACM, the Information and Organiza- tion, the Journal of Strategic Information Systems, and the Information System Journal. His research interests include recursive interaction of organizations and information technology (enterprise systems), with particular emphasis on organizational issues, such as work practices, cultures, structures, decision- making, change, and strategy implementation that often require qualitative re- search methods, specifically, understanding the complex issues related to the adoption, implementation, and use of enterprise systems within organization.