Microsoft Word - AJIS Vol 19.docx Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 1 IS PROJECT RISKS AS EMERGENT PHENOMENA: TOWARDS A MODEL OF RISK ESCALATION AND ITS MANAGEMENT Angela Y Lin The University of Sheffield A.Lin@Shef.ac.uk Nipon Parinyavuttichai Rajabhat Rajanagarindra University nparinya@gmail.com ABSTRACT While the number of substantive investments in IS projects continues to grow, the number of failing projects also continues to increase at an alarming rate. Both the academic and industry literature suggests that inadequate attention to risk and its management continues to be a key factor in project failure. The typical approach taken is to identify and map potential risks, to act as a planning and diagnostic tool, and to prepare a contingency plan has been a factor- based approach. While it remains a valuable tool for mapping anticipated risks the factor- based approach is less effective when viewing project risks as emergent phenomena that un- fold during the course of the project, and require ongoing attention and risk management. In- formed by a case study of a failing university IS development project, this paper focuses on the phenomenon of risk escalation. The case findings suggest that rather than being defined ahead of the project, some project risks may emerge during the project as a consequence of escalation factors that were both antecedent to and a consequence of actual risk management decisions. The article concludes with suggestions as to how project managers can better man-age the emergent rather than static nature of risk phenomena. Keywords: information systems project management, risk, risk management, risk escalation, project escalation 1 INTRODUCTION Substantive investments in information systems (IS) continue to be made as managers seek a source of leverage for improving the efficiency and productivity of the organizations within which they work. At the same time a high volume of IS projects continue to end up as failing projects, either cancelled or abandoned through poor management or over spend, or otherwise incomplete in some way through not working or not meeting the expectations of their users (Creswell et al., 2011, McLeod and MacDonell, 2011, McManus and Wood-Harper, 2007, Morrison et al., 2011, Pankratz and Basten, 2013). While factors that contribute to IS project failures are diverse (Fortune and White, 2006), a lack of identification of the risks involved in developing IS along with a lack of adequate management of these risks have been common findings in many studies (de Bakker et al., 2010, Kerr and Houghton, 2010, Kitsch et al., 2013, PM Solutions, 2011, Rozenes, 2011, Wilton, 2005). IS project risks can be characterized as the uncertainties that prevent a project team from delivering a planned system on time and within budget. IS project risk management can therefore be defined as the effort required to develop and implement strategies that counter the uncertainties that threaten the possible success of a project (Sherer, 1992). Traditional IS risk management typically involves a factor-based approach, the first and foremost stage of which involves the risk manager in identifying and defining the potential risks (Dey et al., 2007, Project Management Institute, 2013). At this stage, foreseeable project risks are identified and contingency plans drawn up to mitigate the risks and limit their impact should they arise on a project (Kim and Park, 2006, Project Management Institute, 2013, Teller, 2013). The premise of the factor-based approach to IS risk management is that risks are entities Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 2 that can be identified and defined prior to the commencement of a project; that they are time and context independent, and that the nature and attributes of such risks remain static throughout the lifetime of a project. Such a ‘factor-based’ approach to risk management, has been widely adopted (Barki et al., 1993, Dagher and Kuzic, 2011, Kappleman et al., 2006, Tiwana and Keil, 2004), nevertheless the approach overlooks the emergent nature of risks (Leonard, 2012, Wright and Capps, 2010). First, a factor-based approach takes little account of how risks and their management depend on a decision maker's or group of decision-makers’ own understandings and attitudes towards those risks and the situation to which they relate; as a consequence poor risk management can itself become a risk for a project. Second, the approach does not take into account the fact that risks can emerge as a result of complex social interaction; that risks can emerge in situ and not necessarily be predicted (Lyytinen and Robey, 1999). Third, a factor-based approach has normally not taken into account the interdependence of different risks and how the occurrence of one risk can be the cause of or the consequence of another risk (Belassi and Tukel, 1996, Nandhakumar, 1996). Fourth, since risks can be emergent and interdependent, the nature of these risks and their properties can vary from one project stage to another, and from project to project (Larsen and Myers, 1998). Finally, IS project risks may emerge during a project as a result of unexpected factors; either within the project (e.g. changes in users’ expectations of a system or a change of project champion), or within the environment of the project (e.g. changes in organizational or market environments, or in government policy). In summary, while a factor-based approach remains a valuable tool for mapping anticipated risks the factor-based approach is less effective when viewing project risks as emergent phenomena that unfold during the course of the project, and require ongoing attention and risk management. While a factor-based approach is capable of anticipating what and why risks occur, for the purposes of predicting and controlling these risks through effective risk management; a more dynamic approach begins to ask how risks emerge as a function of ongoing risk management decisions. The purpose of this article is to bridge this gap by focusing on the phenomenon of risk escalation which refers to the tendency for decision makers “ to become locked into a course of action, throwing good money after bad or committing new resources to a losing course of action” (Staw, 1981, p. 578). Informed by a case study of a university IS development project, the findings suggest that rather than being defined ahead of the project, different types of project risk emerged during the project as a consequence of escalation factors that were both antecedent to and a consequence of risk management decisions. The article concludes with suggestions for how project managers can better manage the emergent rather than static nature of risk phenomena. The paper is organized as follows. The next section presents a review of three main categories of risk that can arise on an IS development project: requirements risk, personnel risks, and resource management risks. This is followed by a description of research strategy including the case study approach used, data collection, data analysis methods and escalation model as analytical framework. A findings section initially describes the risks that arose on the project, and why before introducing a model of risk escalation. The article concludes with suggestions as to how project managers can better manage the emergent rather than static nature of risk phenomena. 2 THEORETICAL BACKGROUND In this review, we first focus on project risks occurring in the areas of requirements, personnel, and resource management. While uncertainties and risks can occur in a number of other areas of an IS project including organizational environment, user commitment, project management, resource management, personnel, requirements, development process and technology; it is these areas that are particularly relevant to our case, and which subsequently inform the development of our risk escalation model. In the second part of the review we discuss escalating factors that contribute to project as well as risk escalation. The discussion is based on Keil’s (1995) model and organised under the headings of project, psychological, social and structural factors. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 3 2.1 Risk Factors on information systems projects 2.1.1 Requirements risks Requirements risks refer to project uncertainties that arise from changing requirements, requirements misunderstanding, and incomplete requirements (Schmidt et al., 2001; Robinson et al., 2003; Keil et al., 2006). Changing requirements is a common requirement risk that almost all projects would encounter and the reasons for changing requirements include changes in business environment which inevitably invokes changes in requirements so that the envisaged system can reflect the change (Land, 1982); conflicts or politics concerning system specifications between user departments (Sherer and Alter, 2004; Wallace et al., 2004), and the lack of understanding of the envisioned system on user’s part means that users are likely to change their mind about what they want from the system (Jiang et al., 1999; Kumar, 2002). Continuous changes in requirements means that it is difficult for the project team to control the progress of the project, resource allocation, and budget (Tiwana and Keil, 2004). Risk of requirement misunderstanding occurs for a number of possible reasons. These include differing perceptions of the system or outcome of IS project development between stake- holders (Sumner, 2000, Schmidt et al., 2001); neither of the project team nor users having a good understanding of the envisioned system (Dey et al., 2007); lack of communication between project team and user groups to clarify the requirements (Coughlan et al., 2003); and stakeholders are unable to articulate their requirements to the project team. Furthermore, user requirements may not always be carefully defined and effectively translated into the design by the project team (Kim et al., 2005; Dey et al., 2007; Han and Huang, 2007). An implication from misunderstanding requirements for the system development is the failure to develop necessary or the development of unnecessary functionalities (Ropponen and Lyytinen, 2000; Kim et al., 2005) which leads to subsequent system modifications and hence project delays (McAllister, 2006). Incomplete requirement risks arise when not all of user requirements are collected and considered or some user requirements are overlooked or ignored either by project team or by users (Lauesen and Vinter, 2001; Yeo, 2002). There are reasons for why requirements are not collected or overlooked including changes in the system requirements or in expectation of the system because the situation has changed during the course of the project; the project team does not have appropriate or use inappropriate methods to collect user requirements; and the project team fails to verify their understanding with users but develops the system based on their own assumptions (Howcroft and Wilson, 2003). Incomplete user requirements can result the project team in spending more time on collecting user requirements from users and correcting or modifying the design accordingly in the later stage of the project (Lauesen and Vinter, 2001). 2.1.2 Personnel risks Personnel risks are often cited as reasons for project failure (Sherer and Alter, 2004; Kim and Park, 2006; Han and Huang, 2007). The risks arise due to insufficient number of skilled personnel to deliver the project (Keil et al., 2006); unrealistic estimation of staffing time which causes more work per capita (Ropponen and Lyytinen, 2000; Peterson et al., 2002; Kim and Park, 2006; Han and Huang, 2007); high staff turnover rate that causes legacy in terms of knowledge and time and hence project delays(Wallace et al., 2004; Kim and Park, 2006); and over relaying on one or few people which puts the project at risk if the personnel resigns or leaves the project (Schmidt et al., 2001).Project mangers’ ability to manage personnel can contribute to personnel risks for example overestimating project staff’s ability can result in inappropriate resource allocation such as human and time (Ropponen and Lyytinen, 2000); failing to organize sufficient training sessions for the staff(Peterson et al., 2002; Kim and Park, 2006; Han and Huang, 2007) can create situations where staff does not have sufficient up to date skills and knowledge; and failing to motivate staff to commit to the project (Sherer and Alter, 2004; Wallace et al., 2004). Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 4 2.1.3 Resource management risks Resource management risks refer to uncertainties in relation to project planning and control of project resources. A project can face resource management risk from the outset for example when a project has insufficient budget to deliver the project (Jiang et al., 1999; Sumner, 2000; Sherer and Later, 2004; Dey et al., 2007). Resource management risks can arise from mismanagement of resources because of not using or lack of appropriate tools to calculate required resources and failing to estimate required resources correctly (Ropponen and Lyytinen, 2000; Barki et al., 2001; Schmidt et al., 2001; Han and Huang, 2007); and failure to involve key project stakeholders in the budget planning process (Barki et al., 2001). Mismanaging budget refers to the situations where project budget is unevenly allocated and used for example a project may use up much of its resources early in the project (Keil, 1995; Schmidt et al., 2001) or the resources are misused by being allocated to support the activities that are not relevant to the project (Keil and Mann, 1997; Wallace et al., 2004). 2.2 Escalation factors Escalation of commitment has received much attention in the IS domain in particular the studies in IS project failures (Drummond, 1996, 1998, Jamieson and Hyland, 2006, Keil and Mann, 1997, Mähring and Keil, 2008, Pan et al, 2009). An extensive study of the failing Taurus project at the London Stock Exchange has for example shown and explained how decision makers were constrained by the unique relationship between the London Stock Exchange and the market; and the complex interactions, e.g. negotiation and compromise, between different departments and those who had the power to influence decisions (Drummond, 1996). Consequently they were trapped in a situation of escalation, and committed to allocating more resources to a failing project until such time as the project was cancelled. A study of an IS project in a utilities service company shows that an escalation of commitment was an outcome of recursive interactions between the project, organizational work activities, and their contexts (Pan et al., 2009). A customer centric organizational culture for example created a situation where decision makers found it difficult not to accept requests for changes from users. The commitment to accept constant changes in user requirements soon led to project delays, which in turn led to a problem in resource planning. The project further deviated from the initial plan as some of the systems features were no longer required because of changes in the business environment e.g. the decrease in customer numbers. The Mandata project, which was sponsored by the Australian Public Service Board and aimed to assist office automation, information management, and records processing for the entire Australian Public Service, is another example of project escalation that led to project abandonment (Sauer, 1993). The project ran through 1970s and was finally terminated in 1981 and the total cost of the project was about 30 million Australian dollars. According to Sauer (1993) the project suffered from a chronic haemorrhage of support, lack of sufficient resources, insufficient project planning (e.g. no definite implementation date), lack of strategic applications in the system that were useful to the stakeholders, and so on. Sauer (1993:69) states that a possible explanation for why authority let an obvious failing project continue because the Board wanted to avoid embarrassment or political damage from loss of face; and the project might have been subject to a form of escalating commitment. These studies have observed that escalations are usually determined by a combination of different factors; that they don’t ‘just happen’ but the outcomes of a subtle interplay between people, context, and technology which develop over time; and that they are not one-phase phenomena but cut through all phases (Alvarez et al., 2011, Winch, 2008). Escalating factors can be categorized into four main types: project, psychological, social, and structural (Staw and Ross, 1987). Project factors are the attributes of a project that play a role in determining the continuation or termination of an existing course of action e.g. the size and scope of a project, the economic structure of a project, the foreseeable expenditure or costs required to complete the project, and the availability of alternative courses of action. Decision makers tend to keep allocating resources to a project when they believe that the payoff will Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 5 benefit the organization in the long-term or when they believe that the project is close to reaching completion (Keil et al., 2000). Figure 1. Summary model of factors influencing escalation Source: Keil (1995, p.436) Psychological factors are a further salient influence on people’s behaviour in escalation situations. These include self-justification, self-inference, and bias when processing information. Self-justification is an important element in studying the reasons for escalation in commitment. With respect to self-justification it has proposed for example that individuals will be biased in their attitudes and therefore in their decision making if they feel personally responsible for the initial funding of the project or for its negative consequences, a perception grounded in an individuals’ desire to affirm their reasoning and competence (Staw, 1976, 1981). Therefore individuals will tend to commit additional resources either in order to justify their previously chosen course of action or in an attempt to turn a situation around. Self-inference on the other hand refers to a situation where decision makers tend to examine their own actions in a particular social context, and to infer personal values and preferences from previous actions (Staw and Ross, 1987). Staw and Ross (1987) identify a number of situations where individuals find themselves bound or committed to a behaviour for example when their acts are explicit or unambiguous, their acts are irrevocable or difficult to undo, their acts are important to the individuals concerned, or their acts are public or are visible to others. A further significant psychological factor is the biased processing of information that can occur when interested decision-makers attempt to prove or disprove the beliefs of others (Nisbett and Ross, 1980). When the perceived outcome of another’s suggestion does not meet the decision-maker’s expectations, a decision-maker may be selective for example in the choice of information processed, as a way of bolstering the efficacy of his/her own judgment and in an effort to disprove the source of the counter argument (Staw and Ross, 1987). A framing effect can also influence information processing. A frame of reference may be created that is overly optimistic in the confidence it attaches to the prospect of victory or of winning the ‘game’. Such an overly confident frame of reference commonly leads to a situation of loss rather than of gain, due to the restrictive effects that an optimistic frame of reference places on the subsequent processing of what would have further relevant information (Kahneman and Tversky, 1984, Whyte, 1993). Social factors consist of the social forces that bind decision makers to their positions. The desire of a decision-maker not to lose face or credibility in front of others is a powerful social factor that can lead to escalating behaviour. Face saving also explains a situation where decision makers neither accept their previous mistakes nor reveal any of their errors to others (Staw and Ross, 1987). As a result decision-makers will be inclined to commit even more resources to an existing current course of action so as to avoid losing social credibility (Brockner et al., 1981, Drummond, 1998, Montealegre and Keil, 2000). When faced with an Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 6 ambiguous situation individuals will also be inclined to model their behaviour and responses on their previous experiences in the same situation (Bandura, 1977). Brockner et al. (1984) found that individuals will also allocate further resources to an existing course of action, if the same decision taken by others in a similar situation had led to a successful or satisfactory outcome. Individuals in an organization who can turn a failing project into a successful one usually receive significant reward. The hero effect describes a situation where individuals are encouraged to commit to an act that they believe they can turn around (Ross and Staw, 1986). Finally, the influence of structural factors, e.g. organizational, cultural, political and managerial, may increase as a project unfolds and create conditions for escalation. Issues such as change of project champion, management support for continuing a project, changes in policies for example can occur at any time during a project and can subsequently influence escalation. Sometimes withdrawing from a project is not easy because the project can become institutionalized and embedded in an organization over time. The withdrawal of a project can potentially entail changes in many parts of the organization and as such may not be agreeable to those who are involved. 3 RESEARCH METHOD The case study research method was used to explore the emergent character of IS project development risks and risk escalation, and was chosen for a number of reasons. First, use of the case study method enables us to gain an understanding of the phenomenon at hand, in this case risk escalation, in a naturalistic setting (Benbasat et al., 1987, Yin, 2009). Second, it is a method of inquiry which enables the answering not only of what questions, but also why and how questions in a contextual setting (Creswell, 2007, Yin, 2009). Therefore the method enables the study of risks over time and within a bounded system; something that cannot be achieved via a survey for example. Third, the case study approach enables the researcher to get closer to the phenomenon under investigation through understanding a project’s risks and their emergent character, from the point of view of participants and in their words (Yin, 2009). Fourth, multiple data sources enable not only the collection of rich data but also triangulation of data, which contributes to research validity (Lincoln and Guba, 1985, Stake, 1995). 3.1 Background of the case The case study is of a university IS development project. This case was selected because of a lack of attention to risks, their inadequate management and escalation; factors which can be considered to be one of the major reasons for the project’s eventual failure. The aim of the project was to develop and implement a centralized accounting system that would comply with new government accounting standards in Thailand. The new system, AccSys, was also expected to generate financial reports for university executives that would enable them to make informed financial decisions. AccSys consisted of four sub-systems: budgeting, warehousing, accounting, and finance, and they were expected to be fully integrated in order to provide high quality on and off-campus online access to the system by all staff. According to the initial project plan a prototype was to be completed within the first year of the project (2003), with a fully functioning system completed by 2006. However in 2006 the project team announced a delay in the project and by 2007 only about 50-60% of the system had been implemented. In 2010, the project manager announced a further delay in the project, promising that the system would be fully operational by the end of 2012. The project was initially funded by the Thailand Office of Higher Education and then by the university during the extension period of the project. 3.2 Data collection The primary data sources for the study were: semi-structured interviews and project documentation. The data collected from the semi-structured interviews provided rich descriptions of the project. Interviewees consisted of the project team members only since the study was interested in the project team’s perceptions of risk, along with the decisions and actions taken to prevent and manage these risks. At the commencement of the project, the Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 7 team consisted of eight staff members. At the time the data for this case study were collected all remaining members of this initial project team were invited to participate. Four project team members took part: the project manager, the project leader, a systems analyst, and a project developer. Table 1 summarizes the role and responsibilities of each interviewee. A standardized schedule of questions was devised before the interviews took place, with additional questions asked during interviews to respond to interviewees’ answers. The interviews lasted between 1.5 and 2.5 hours. Member of the team Responsibility Project manager Monitor overall project development and milestones, formal communication about project-related matters with users in each university unit, including requirements collection and system testing. Project leader Project coordination, make final decisions on behalf of the team, resolve technical problems found in the project development, monitor and control day-to-day progress on the project. System analyst(s) Responsibility for system design, database analysis and design, user interface design, and documentation. Day-to-day contact with users to collect and clarify their requirements for project developers. Project developer(s) Each programmer will be assigned the task of building a particular sub-system of AccSys. Collaboration with system analyst in order to develop the project. Table 1. Interviewees: project role and responsibilities The project documentation collected was used to crosscheck and validate data obtained during interviews (Silverman, 2006). Table 2 summarizes the documents collected and used in the study. Document Name Date Produced Meeting minutes December 2004 – May 2008 Organization structure December 2005 Project manuals and details for the four major sub-systems October 2005 – November 2008 Project progress to OHE December 2007 Report of problems and solutions December 2005 Risk management report September 2006 Table 2.Key project documentation used Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 8 3.3 Data analysis method A thematic analysis of the risks that occurred on the project, how they arose and were perceived, and the actions and decisions taken to mitigate these risks was initially conducted (Drummond, 1998). While this method of analysis enables the answering of questions around what risks arose and why, it is unable explain how actions and decisions relating their management in itself was a contributing factor in escalating the risks and in turn the project. A subsequent analysis was therefore conducted using Keil’s (1995) model of escalation factors as a lens to analyse the observed cycle of risk escalation that unfolded following risk management actions taken to address initial risks. 4 FINDINGS This section presents the risks that emerged as the project unfolded; focusing on the three major areas of risk, i.e. requirement risks, personnel risks, and resource management risks, which are believed to be the consequence of poor project management and which contributed to the project failing. The remainder of this section will describe and explain why these risks arose; while the next section (Section 5) will present a model of how escalation factors contributed to and resulted from inadequate management of these project risks 4.1 Requirements risks Requirements risks were identified as the most significant risk contributing in this case to the delay of the project and user dissatisfaction with the system. Three types of requirement risks were observed and they were: diversity of requirements, misunderstanding of requirements, and instability of requirements. Diversity of requirements refers to the degree to which stake- holders differ in their views of the system’s requirements and as a result have difficulty reaching agreement (Robinson et al., 2003). The size and complexity of a project are the main reasons for diversity. In general the more user departments involved the greater diversity of user requirements is; and similarly the more complex the project is the more likely requirements diversity will occur (Liu et al., 2011). The general expectation of the AccSys was that it would be used by at least 80 user departments across the university and could accommodate the different workflows that each department had. Therefore the project team was struggling to consolidate the diversity of requirements and to get user representatives to reach a consensus on their department’s requirements. “[...] each user department has its own workflow and practice. A project that tries to create a system with a standardized workflow that is agreed and shared by all departments would be inevitably challenging and complicated. (Project leader) “We had a lot of meetings to try to reach consensus on user requirements” (Project manager) “The challenge to us was to implement a system that can satisfy all user departments’ needs and system preferences.” (Project leader) In order to simplify and shorten the time of the requirements collection process the project manager took a decision only to collect requirements from those who were perceived to be a reliable source of those requirements. This decision created a situation where the project team misunderstood the system requirements due to the partial or inaccurate information given. This was compounded by the failure, before the system was developed, to verify the requirements with the rest of user representatives before the system was developed. The system which was subsequently developed was therefore based on the project team’s partial understanding of the system requirements and the system was rejected by the user departments whose requirements had not been taken into account. “The UML design did not contain sufficient details of the user system. […] On several occasions, we had to collect more requirements from the users.” (Project developer) Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 9 Requirements instability poses a significant risk to project success because a simple change in design in one part of the system can incur substantial changes elsewhere in the system (De- Marco and Lister, 2003, Liu et al., 2011). Other project and external influences can also exacerbate a situation of requirements instability e.g. a change of project champion or a change in government policy. In this case study the new Head of Finance Department requested additional changes to a set of user requirements that were agreed by the previous head. This request, according to the interviewees, was motivated by her wanting to prove knowledge of and competence with the finance system to others. Obliged to accept the request the project team agreed to modify the system despite the fact that this might mean a further delay in the project delivery. Changes in the Thai government’s policy on budget control at the time of the project led the university’s Budgeting Department to request modifications in the way AccSys generated budget reports. Again the project team accepted requests for changes since they believed the request was legitimate and that the situation was a one-off. In reality the change meant that about 3000 reports generated from the system were affected. “This was not the first case. I told them how dared they let users change these requirements. They should have asked me before making any changes. I am confident that I would be able to persuade the users to reconsider their requests for change so that project could continue without any delay.” (Project leader) “What is the point to have a system which ends up unused by users?” From the users’ point of view it is their rights to change requirements for the system as the perceived that “it would be unfair to ask them to provide all requirements in one time as they should be allowed to give the requirements whenever and whatever they can come up with.” (System analyst) 4.2 Personnel risks The lack of qualified personnel in the project had a significant impact on the progress of the project. Less than 50% of the system was ready by the end of the system development phase for system testing, while the rest of the system was either in the process of the development or still at the planning stage. The risk occurred mainly because of the recruitment policy which prevented the project team from recruiting sufficient number of people to work on the project and which subsequently led to staff shortage. “I think that the executive probably thought that we didn’t have much to do! I heard that there were 33 applicants applying for the available positions in this project, but none of them met the executive's criteria. How could that be possible?” (System analyst) This staff shortage together with the problems associated with the requirement risks contributed to a serious delay in the project. “If we really wanted to finish the project within the timeframe, we need more staff working on the project.” (Project leader) The shortage also created a situation where existing members had to take on additional work without being given any incentives. Thus, some staff actively sought employment opportunities elsewhere. The resignations of project developer and system analyst escalated the situation. “One project developer resigned because he found a better paid project developer position in other organization.” (System analyst) According to the management, they were not aware of the situation otherwise they could have resolved the problem earlier. And their solution to the problem was to relax the recruitment policy by changing required qualifications. Although this solution helped the project team recruit new staff it made the situation somewhat worse because the existing staff not only had to continue taking additional work but also had to look after new recruits who did not have the necessary skills to carry out the project. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 10 4.3 Resource management risks Resource management risks refer to poor resource management, e.g. a lack of effective resource planning and control (Schmidt et al., 2001). In the case of AccSys the resource management risk was due to the lack of appropriate project management experience especially in the area of project planning, project management of large project, and implementation mismanagement. The emergence of this risk can be traced back to the beginning of the project when the decision was made to develop the system in-house. According to the project manager, the decision was inevitable as the grant given by the Office of Higher Education Commission was not enough for the university to outsource the project to an experienced software house. “Honestly, the reasonable funding for a user organization to outsource this project would be around 200 million bahts. The outsourcing company might implement SAP or Oracle in the university and ask everyone to just follow the standard and procedures embedded in the system. The outsourcing strategy has been proven successful elsewhere for example in Petroleum Thai group. But, we did not have that much money. The maximum amount of funding that we could get was only 3-4 million bahts.” (Project manager) None of the people in the team including the project manager himself had sufficient knowledge and experience of managing a complex and large-scale project. This lack of experience was reflected for example in the lack of a contingency plan for some common and anticipatable risk factors, e.g. changing user requirements and departure of staff members, so that when those risks emerged the team was unable to deal with them effectively (Project Management Institute, 2013, Pender, 2001). Another example of lack of experience was that the project team underestimated the complexity of the system’s development and did not allocate enough time to each task (Peterson et al., 2002, Vener et al, 2005). The unrealistic scheduling had knock on effect on the subsequent tasks and their schedules. “To be frank, at the beginning I thought that what we needed to do was only to convert users’ existing fill-in-form documents into electronic applications and that’s it!” (Project leader) In addition to unrealistic scheduling the progress of system development was not made transparent to the management. The project leader pointed out that he was not aware of any problems or being updated with the state of play in project progress. In this sense the management was unable to revise the project schedule to reflect the actual situation and the gap between the real schedule and the schedule on the paper continued widen. “The system analyst did not respect my authority. I kept asking for a progress report and its details so many times, but she intended to forget.” (Project leader) 5 TOWARDS A MODEL OF RISK ESCALATION This section develops an explanation of how the risks identified and managed contributed not to their alleviation but their escalation. This explanation is organized around the positing of escalation factors intervening between the identification and the management of risk factors, and emerging as a result of that management. We have observed in the case study that the decisions taken by the project manager and leader tended to be pragmatic decisions designed to fix problems that were perceived to be temporary setbacks and which could be easily resolved for example by their decision to reduce the number of participants during user requirements collection in order to reduce diverse requirements; and by lowering recruitment standards in order to recruit personnel for the project. Pragmatic decision-making is a behaviour that usually leads to a quick, obvious, or easy solution while the problem indeed needs more considered thought (Drummond and Hodgson, 1996, Talukder and Quazi, 2010). The consequences of such decisions often lead to further problems because decision makers fail to appreciate the situation in its broader context (i.e. outside its immediate context), along Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 11 with the impact of the decisions on the project as a whole (Keil, 1995; Keil et al, 2000; Drummond, 1998). By allocating resources to manage the consequences of these ‘quick and dirty’ decisions means that resources can be withdrawn from the pool and diverted to fix the unexpected problems (Pan et al., 2009). Needless to say, project escalation can quickly be triggered. Pragmatic decision-making can be both an effect of and cause of information framing and processing bias. It can be an effect because information framing and processing bias can influence decisions about resource allocation by ‘perceiving problems as temporary’ or ‘believing that the project will be finished soon’(Rutledge, 1994). It can be a cause of information processing bias because the decision is likely to ‘direct’ people to think in a particular way or to ‘encourage’ people to ignore certain information and signs. For example, the project manager’s decision about collecting user requirements from a few randomly selected user representatives had encouraged the team to consider certain aspects of the systems and process only the selective information. The decision subsequently led to requirement risks including partial understanding of the system requirements and requirements instability. Pragmatic decision-making can also be interpreted as self-interest. It is widely agreed in the IS literature that while involving users in project development can be time consuming, costly, and difficult to manage nevertheless not involving users can risk project success (Cresswell et al., 2013, Markus and Mo, 2004, McLeod et al., 2007). In this study we observed that the decision not to involve all user representatives was mainly down to saving costs (time and resources) and trouble (collecting and managing diverse requirements) and to shorten the time for gathering user requirements “We had a lot of meetings with users and I was bored with trying to get all users to agree on the requirements.” (Project manager) The literature also suggests that when an IS project is perceived to have large potential payoff for the organisation in the long run the level of commitment tends to be high and the resources allocated are perceived as long-term investments rather as ‘costs’ (Alvarez, 2011, Drummond, 2005, Guah, 2008,Keil, 1995,Northcraftand Wolf, 1984,Staw and Ross, 1987). With such perception decision makers tend to continue to commit resources to the project. The management of the university and project team continued to pursue the project at any cost was partly because they collectively believed that the system could benefit the university in the long run in different aspects. Socially speaking, the university could earn respect among other universities for completing the project; politically, the university could show the funding bodies their system development credentials and increase their chances of being awarded with other grants in the future; and organizationally the system could improve the efficiency in the university. Perceiving the project as a long term investment, the university management continued funding the project because collectively they also believe that the project would be completed as soon as the problems are resolved. The beliefs highlight that with the shared interests different groups of stakeholders can collectively commit to a failing projects and this finding is unlike what has been shown in many studies that only individual decision makers are trapped in such situation (Drummond, 1998, Keil, 1995, Newman and Sabherwal, 1996, Snow and Keil, 2002). Collective commitment can be interpreted as a result of self-justification behaviour where both individuals and organization as a whole try to avoid embarrassment because of mistakes made. Garland (1990) argues that people are likely to continue to authorize additional resources as a way of justifying the initial investment especially when the size of the initial investment is large (Garland, 1990). The university's decision to continue funding the project can hence be interpreted as an attempt to avoid the realization of sunk costs and loss (Keil, 1995). While not wanting to admit the failure and avoid embarrassment may be the causes of collective commitment they are also the results of face saving. For example the project team had to save their face within the university at the same time the management of university wanted to save the face among other universities, therefore they were both in the situation that they could not Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 12 withdraw from the project but continue with it. This can explain why the projects that have a lot of publicity are more prone to project escalation e.g. Mandata project (Sauer, 2003),Taurus project at London Stock Exchange (Drummond 1996, Goulielmos, 2003, Smith and Keil, 2003), Computer Aided Dispatch system at London Ambulance Service (Finkelstein, 1993, Goulielmos, 2003), and US Census Bureau Information System (Krigsman, 2008). The two risks, lack of project experience and recruitment problems escalated because of learned helplessness, mum effect, and deaf effect. Learned helplessness refers to a situation where an individual neglects to respond logically to the current project situation because of his/her previous attempts to resolve the problem continue to fail or are refused by others (Seligman, 1975, Beck et al., 2010). It is noteworthy that the members of the team were reluctant to report problems but solving the problems themselves because their previous attempts to offering solutions to the management were often rejected. Not reporting or communicating vital information can also be what is termed as ‘mum effect’ where individuals are reluctant to report negative information and ‘blow the whistle’ (Robey and Keil, 2001, Smith and Keil, 2003). The mum effect is normally associated with individuals’ concern not to be punished and as such as risk their careers. Robey and Keil (2001) report that those who have little job security or mobility have most to lose and little to gain. They are therefore the least likely to act as a whistle blower. The mum effect can explain why members did not report the problems but tried to solve problems themselves because except for the senior system analyst the rest of the team held only temporary position for the duration of the project and they were worried about losing their job if they reported any problems or were perceived to make any troubles. Not only were the project team members reluctant to report problems (e.g. learned helplessness and mum effect) but the management was also reluctant to digest bad news. ‘Deaf effect’ occurs when decision makers downplay or otherwise not take vital information on board (Cuellar et al., 2006). The case study shows that deaf effect can be intentional and psychologically, politically, and organizationally motivated (Robey and Keil, 2001). Psychologically for example the systems analyst’s attachment to a particular system development method and her own way of doing things resulted in her turning a deaf ear to the expert opinions of others. Politically the project leader turned a deaf ear to the complaints about the system analyst; and organizationally the decision makers did not respond in any meaningful way to the problems reported. Self-interest is a striking feature of the project. Self-interest was observed when the project leader was reluctant to ask progress reports from the system analyst because he did not want to harm his relationship with the colleague; the project manager did not put much effort into the project monitoring because he valued his other roles in the university which were more career significant; the system analyst had her personal agenda and only interested in developing the system using her own methodology; and the new Head of Finance Department, who appeared later on the scene, wanted to demonstrate her competence in the area and requested changes in the previously agreed requirements. “There were arguments over the database design between the members of the advisory group and our system analyst. ...the system analyst was over confident in her knowledge. She never listened to any suggestions about the database design made by the lecturers.” (Project leader) Drummond and Hodgson (1996) assert that deviousness and self-interest usually associate with individuals’ political motivations and behaviours and influence the decision process. The presence of management supports and commitment to a project has been argued as a critical success factor (Wallace et al., 2004).The standard IS literature argues that the management support and commitment publicly display the importance of an information system to the users and therefore encourage user collaboration and reduce user resistance to the project and system (Elbanna, 2013; Petter et al, 2014; Sharma and Yetton, 2011). From the escalation of commitment perspective, the management support and commitment means the management will be more vigilant and monitor the project progress closely (Newman and Sabherwal, 1996). Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 13 For ‘self-interest’ reasons both project manager and project leader failed to monitor and take control of the project progress therefore they failed to manage the risks in time and as such those risks became instrumental in the creation of other kinds of risks. “I should blame myself for the inappropriate design. I should have paid more attention to this process. I would not find any problems if I constantly monitored the project. [...] Especially for the database design issues, I think I would be able to give suggestions on how to prevent the design problems.” (Project leader) The other side of the same coin, senior management support and commitment can also be a key to continue investing in a failing course of action. Senior managers may commit to a project for political reasons even though warning signs exist (Staw and Ross, 1987, Keil, 1995). The AccSys project continued to receive funding from the university after the funding from the Thai Higher Education Commission ceased because it was important politically for the university to complete the project. Project completion would demonstrate to other universities and government funding agencies the university’s competence in carrying out a multimillion baht project. Structural changes are normally less predictable and their occurrence either within a project or in its environment cannot be so easily controlled. The confusion and uncertainty created as a result of these structural changes can be observed in IT projects where regulations and institutional logics in an organization change because of changes in the organization’s own environment e.g. a change in government policy (Guah, 2008). The changes in government policy and the change in project champion in the Finance Department both have impacts on user requirements and project schedule. Risks Escalation Factors: antecedent (A) to and consequence (C) of decisions Risk Management Decisions/Actions Project factors Resource management risks Collective commitment （A or C） Continue funding the project Resource management risks Perceived the problems as temporary setback (A) Allocating additional resources Resource management risks Long-term-investment (A) Continue funding the project because the system will benefit the university in the long term Psychological factors Resource management risks Self-justification (C) Continue funding the project to avoid embarrassment and realizing sunk costs. Personnel (staff shortage) and resource management risks (unrealistic schedule) Learned helplessness/Mum effect (C) Not reporting problems to the management and trying to solve problems themselves Resource management risks (resources were allocated to fixed the problems arising from the wrong design) Deaf effect (C) The analyst designed the system with wrong assumption and methodology; the management not responding to the complaints about the analyst’s behaviours Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 14 Requirement risks (misunderstanding requirements, partial understanding requirements), personal risks (unqualified personnel) Information framing and processing bias (A or C) Quick and dirty decisions (pragmatic behavior) including reducing number of user representatives to participate in requirement collection, change recruitment policy in order recruit new staff. Resource risks (unrealistic scheduling, allocating additional resources which were not planned to fix the mistakes), Requirement risks Self-interest (C) The project leader failed to pressurize the analyst to submit the progress report; the project team decided to simplify their tasks by not involving all user representatives Social factors Resource management risks Face saving (A or C) Collective commitment to the project; long term investment Structural factors Resources management risk Lack of managerial support (A) Lack of commitment to project monitoring and control Requirement risks (changing requirements), resource management risks (allocating more resources) Changing project champion (C) New Head of Finance asked for changes Requirement risks, resource management risks Changing environment (C) Changing functionality to meet changing government policy Table 3.Risks, Escalation Factors, Risk Management Decisions/Actions: Summary Based on the above discussions, Table 3 summarises the relationships between risks, decision/action, and escalation factors. We have categorised our findings: collective commitment under the category of project factor and learned helplessness/mum effect, deaf effect, and self-interest under the category of psychological factor. These factors were not identified in Keil’s initial work in 1995 (Figure 1) but they have been found playing a part in escalation in this and other studies. For example, Keil and his colleagues in their late work have argued that learned helplessness/mum effect and deaf effect can cause project escalation (Cullar et al, 2006, Keil et al., 2001, Lee et al, 2014, Robey, and Keil, 2001, Smith et al, 2001, Smith and Keil, 2003). Self-interest and collective commitment are least discussed in the escalation literature nevertheless their importance in decision making have been discussed elsewhere especially in group decision making literature, for example the former can lead to less than optimal collective outcome (Caporael et al., 1989, Meglino and Korsgaard, 2004) while the latter can lead to escalation (Chapman 2006, Kroon et al., 1991). Based on the finding and escalation theory, we argue that the sub-optimal decisions are subject to the influences of combinations of different project, psychological, social, and structural factors (e.g. learned helpless and mum effect; deaf effect and self-interest; perceived as temporary setback and information processing bias) at both individual and group level. For example, face saving (social factor) and self-interest (psychological factor) can lead to collective commitment to allocate more resources to a failing project as no one is willing to withdraw from the project and face with social and political consequences. Similarly, the belief in long- Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 15 term investment (project factor) can be used as an excuse for self-justification (psychological factor) and face saving (social factor). Figure 2. Towards a Model of Risk Escalation Figure 2 highlights that the decisions or actions taken to solve problems can lead to unintended risks. As Drummond (1998) describes “’solutions’ intended to eliminate ‘problems’ actually compound them. Unintended negative consequences arise from pursuing economically rational objectives” (Drummond, 1998, p923). The unintended risks can reinforce particular factors and force more suboptimal decisions, and so on. 6 CONCLUSION AND IMPLICATIONS This study has investigated the IS project risks from the perspective of their escalation. The case study has shed light not only on their identification and management, but also how the presence of escalating factors contributed to the project manager’s and leader’s escalation of these risks rather than their mitigation (Drummond, 1998). The knock-on effects of these decision give rise to further project escalation and in turn risk escalation (see Figure 2).The study has identified and demonstrated that rather than being anticipatable, and hence predictable and controllable, risks can also emerge during a project due to escalating socio- psychological factors (e.g. self-interest, learn helpless, mum and deaf effects, collective commitment) over-riding technical and economic rationalities (Drummond, 1994, 1998; Ross and Staw, 1993). The study also highlights the relationship between risk cause and risk effect is not always straightforward due to the presence of intervening factors and that decisions or actions taken to counteract risks can also have unintended consequences which generate more risks. This study has a number of implications for the literature. First, the study has demonstrated how an escalation model can be adapted as a useful analytical tool to study risk and its emergence. Figure 2 combines escalation factors and IS project risks into a conceptual framework that can be used and extended to study the IS project risks from an emergent perspective that overcomes the limitations of linear thinking (i.e. simple cause and effect Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 16 relationships). When studying risk, attention should be given not only to risk, the reasons for its occurrence (activating mechanism), and its management; but also to factors that mediate between the risks that occur and their effects. Second, the study shows how the presence of socio-psychological factors in a project are more critical to the emergence of risks and their escalation than has hitherto been given credit for in the literature. The impact of these factors in the context of IS and IS project risk management is an area for subsequent research. Third, the study has shown how risks, and their escalation can emerge as the unintended negative consequences of positive interventions. Thus, in order to better understand how risks occur one should trace the sequence of events and illuminate the underlying logics of decisions (Drummond, 1998). Fourth, this study demonstrates how the impact of these escalating factors is mediated through decisions or actions taken to solve risk problems. Therefore in order to understand how risks emerge and escalate it is important to identify the relevant decisions and actions first and then proceed to trace back how the decisions were arrived at in the given context. Finally, this study has identified further escalation factors (Table 3) to supplement Keil’s 1995 work (Figure 1) and suggests that to advance the understanding of risk escalation these factors: collective commitment, learned helplessness/mum effect, deaf effect, self- interest and their effect on project need to be further researched individually. The practical implications of the dynamic relationship between risk management and escalation is that it demonstrates how the mismanagement of risks can become a vicious circle and that can eventually lead to project escalation. Recognizing early warning signs and managing risks carefully can avoid project escalation (Pan et al., 2009). Nevertheless it is worth noting that being able to recognize the warning signs and escalation patterns and act upon the signs and make appropriate decisions require sufficient project management experience. In this sense, appointing experienced project managers for large scale and mission critical projects should be the first step of risk management (Bloch et al., 2012, Fortune and White, 2006, Hougham, 1996). Second, the findings of the study and the literature have shown that project risks is not just about managing ‘risks’ but dealing with people and social dynamics (Wrights and Capps, 2010). Practitioners hence should view and manage risks as people and social problems rather than as system and technical problems. Finally practitioners must avoid making pragmatic decisions or taking shortcuts when problems arise because those decisions or shortcuts are often made without considering the project as whole and the long term effects of its consequences on the project and they are likely to backfire. In sum, the case presented and the model developed can be used in the future both to aid further research into IS project risk as an emergent phenomenon, plus act as a tool for practitioners to begin to manage risk not only from a perspective of their anticipation but also from the perspective of observing and managing their emergent, situational and interdependent character. REFERENCES Alvarez, J., Pustina, A. & Hällgren, J. (2011). Escalating commitment in the death zone: New insights from the 1996 Mount Everest disaster. International Journal of Project Management29, 971-985. Bandura, A. (1977). Social learning theory. Englewood Cliffs, Prentice-Hall. Barki, H., Rivard, S. & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management Information Systems, 10, 203–225. Belassi, W. & Tukel, O.I. (1996). A new framework for determining critical success/failure factors in projects. International Journal of Project Manage, 14, 141–51. Benbasat, I., Goldstein, D. & Mead, M. (1987). The case research strategy in studies of information systems. MIS Quarterly, 11, 369-386. Beck, R., Marschollek, O. & Gregory, R. (2010). Establishing preconditions for spanning the boundaries in public private IT megaprojects. International Journal of Information Technology Project Management, 1, 20-37. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 17 Bloch, M., Blumberg, S. & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company, 1-6. [Access on 01/05/2015] http://www.samuellearning.org/Project_Management_Slides/Delivering%20Large%2 0IT%20Projects.pdf Bowen, M. (1987). The escalation phenomenon reconsidered: Decision dilemmas or decision errors. Academy of Management Review, 12, 52-66. Brockner, J., Rubin, J. & Lang, E. (1981). Face-saving and entrapment. Journal of Experimental Social Psychology, 17, 68-79. Brockner, J., Nathanson, S., Friend, A., Harbeck, J., Samuelson, C., Houser, R., Bazerman, M. & Rubin, J. (1984). The role of modelling processes in the ‘knee deep in the big muddy’ phenomenon. Organizational Behavior and Human Performance, 33, 77-99. Carter, R.A., Anton, A.I., Laurie, W., & Dagnino, A. (2001). Evolving beyond requirements creep: A risk-based evolutionary prototyping model. Proceeding of the 5th IEEE International Symposium on Requirements engineering, Maryland, US, 94-101 Caporael, L., Dawes, R., Orbell, J., & van de Kragt, A. (1989). Selfishness examined: Cooperation in the absence of egoistic incentives. Behavioral and Brain Sciences, 12, 683-699. Chapman, J. (2006). Anxiety and defective decision making: an elaboration of the groupthink model. Management Decision, 44, 1391-1404. Coughlan, J., Lycett, M., & Macredie, R. D., (2003). Communication issues in requirements elicitation: A content analysis of stakeholder experiences. Information and Software Technology, 45, 525-537. Creswell, J. (2007). Qualitative inquiry and research design: Choosing among five approaches. Thousand Oaks, Sage. Creswell, K., Roberston, A. & Sheikh, A. (2011). Lessons Learned from England’s National Electronic Health Record Implementation: Implications for the International Community. Proceedings of the 2nd ACM SIGHIT International Health Informatics Symposium, 685-690 Cresswell, K., Bates, D. W. & Sheikh, A. (2013). Ten Key Considerations for the Successful Implementation and Adoption of Large-scale Health Information Technology. Journal of the American Medical Informatics Association, 0, 1-5. Cuellar, M., Keil, M., & Johnson, R. (2006). The deaf effect response to bad news reporting in information systems projects. e-Service Journal, 5, 75-97. Daft, R. L. & Macintosh, N. B. (1981). A tentative exploration into the amount and equivocality of information processing in organizational work units. Administrative Science Quarterly, 26, 207-224. Dagher, Joseph & Kuzic, Joze. (2011). Factors Influencing ERP Implementation in Australia. In: Ariwa, E. and El-Qawasmeh, E. (eds.), Digital Enterprise and Information Systems, Springer, pp. 197-205. De Bakker, K., Boonstra, A. & Wortmann, H. (2010). Does risk management contribute to IT project success? A meta-analysis of empirical evidence. International Journal of Project Management, 28, 493-503. DeMarco, T. & Lister, T. (2003). Risk management during requirements. IEEE Software, 50, 99-101. Dey, P., Kinch, J. & Ogunlana, S.O. (2007). Managing risk in software development projects: A case study. Industrial Management & Data Systems, 107, 284-303. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 18 Drummond, H. (1996). Escalation in decision making: The tragedy of Taurus. Oxford, Oxford University Press. Drummond, H. & Hodgson, J. (1996). Between a rock and a hard place: a case study of escalation, Management Decision 34, 29-34. Drummond, H. (1998). Is Escalation Always Irrational? Organization Studies, 19, 911-929. Drummond, H. (2005). What we never have, we never miss? Decision error and the risks of premature termination. Journal of Information Technology, 20, 170-176. Finkelstein, A. (1993). Report of the inquiry into the London Ambulance Service [online]. http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/las/lascase0.9.pdf [Access on 27 May 2014] Elbanna, A. (2013). Top management support in multiple-project environments: An in- practice view. European Journal of Information Systems, 22, 278-294. Fortune, J. & White, D. (2006). Framing of project critical success factors by a systems model. International Journal of Project Management, 24, 53-65. Garland, H. (1990). Throwing good money after bad: The effect of sunk costs on the decision to escalate commitment to an ongoing project. Journal of Applied Psychology, 75, 728- 731. Goulielmos, M. (2003). Outlining organisational failure in information systems development. Disaster Prevention and Management, 12, 319-327. Guah, M. (2008). IT project escalation: A case analysis within the UK NHS. International Journal of Information Management, 28, 536-540. Han, W.M. & Huang, S.J. (2007). An empirical analysis of risk components and performance on software projects. Journal of Systems and Software, 80, 42-50 Hougham, M. (1996). London ambulance service computer-aided despatch system. International Journal of Project Management, 14, 103-110. Howcroft, D. & Wilson, M. (2003). Paradoxes of participatory practices: The Janus role of the systems developer. Information and Organization, 13, 1-24. Jamieson, K. & Hyland, P. (2006). Good intuition or fear and uncertainty: The effects of bias on information systems selection decisions. Informing Science Journal, 9, 49-69. Jiang, J.J., Klein, G., Balloun, J.L. & Crampton, S.M. (1999). System analysts’ orientations and perceptions of system failure. Information and Software Technology, 41, 101-106. Kahneman, D. & Tversky, A. (1979). Prospect theory: An analysis of decision under risk. Econometrica, 47, 263-291. Kappleman, L., Mckeeman, R., & Zhang, L. (2006). Early warning sign of IT project failure: The dominant dozen. Information Systems Management, 23, 31-36. Keil, M. (1995). Pulling the plug: Software project management and the problem of project escalation. MIS Quarterly, 19, 421 – 447. Keil, M. & Mann, J. (1997). Understanding the nature and extent of IS project escalation: Results from a survey of IS audit and control professionals. Proceedings of the Thirteenth Annual Hawaii International Conference, 1-11. Keil, M., Bernard, C.Y., Wei, K. K., Saarinen, T., Tuunainen, V. &Wassenaar, A. (2000).A cross- cultural study on escalation of commitment behavior in software projects. MIS Quarterly, 24, 299-325. Keil, M., Li, L., Mathiassen, L., & Zheng, G. (2006). The influence of checklists and roles on software practitioner risk perception and decision making. Proceedings of the 39th Hawaii International Conference on System Success, Hawaii, USA. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 19 Kerr, D. V. & Houghton, Luke. (2010). Just in Time or Just in Case: A Case Study on the Impact of Context in ERP Implementations. Australasian Journal of Information Systems, 16, 5-16. Kim, H., Iijima, J., & Ho, S. (2005). A framework for analysis of system failure in information system integration. Industrial Engineering & Management Systems, 4, 207-217 Kim, E., Park, Y. (2006). An exploratory study of risks in information system development projects: Using association rule mining. International Journal of Technology Intelligence and Planning,2, 404-417. Klein, H., & Myers, M. (1999). A set of principles for conducting and evaluating interpretive field studies in information systems. MIS Quarterly, 23, 67-93. Krigsman, M. (2008). Billion-dollar IT failure at Census Bureau [online]. Available: http://www.zdnet.com/blog/projectfailures/billion-dollar-it-failure-at-census- bureau/660 [Access on 27 May 2014] Kroon, M., Hart, P. & Van Kreveld, D. (1991). Managing group decision making processes: Individual versus collective accountability and groupthink. International Journal of Conflict Management, 2, 91-115. Kumar, R.L. (2002). Managing risks in IT projects: An options perspective. Information & Management, 40, 63-74. Kutsch, E., Denyer, D., Hall, M. & Lee-Kelly, E. (2013). Does risk matter? Disengaging from risk management practices in information projects. European Journal of Information Systems, 22, 637-649 Land, F. (1982). Adapting to changing user requirements. Information & Management, 5, 59- 75. Larsen, M. & Myers, M. (1998). When success turns into failure: A package driven process re- engineering project in the financial services industry. Journal of Strategic Information Systems, 8, 395–417. Lauesen, S. & Vinter, O. (2001). Preventing requirement defects: An experiment in process improvement. Requirements Engineering, 6, 37-50. Lee, J., Cuellar, M., Keil, M., & Johnson, R. (2014). The role of a bad news reporter in information technology project escalation: A deaf effect perspective. ACM SIGMIS Database, 45, 8-29. Leonard, J. (2012). A Model of Project and Organisational Dynamics. Australasian Journal of Information Systems, 17, 5-22. Lincoln, Y. & Guba, E. (1985). Naturalistic inquiry, Beverly Hills, Sage. Liu, J., Chen, H.G., Chen, C. & Sheu, T.S. (2011). Relationships among interpersonal conflict, requirements uncertainty, and software project performance. International Journal of Project Management, 29, 547-556. Lyytinen, K. & Robey, D. (1999). Learning failure in information systems development. Information Systems Journal, 9, 85-101. Mähring, M. & Keil, M. (2008). Information technology project escalation: A process model. Decision Sciences, 39, 239-272. McAlister, C.A. (2006). Requirements determination of information systems User and developer perceptions of factors contributing to misunderstandings. Capella University. McLeod, L., MacDonell, S. & Doolin, B. (2007). User participation in contemporary IS development: An IS management perspective. Australian Journal of Information Systems, 15, 113-136. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 20 McLeod, L. & MacDonell, S. (2011). Factors that affect software systems development project outcomes: A survey of research. ACM Computing Surveys, 43, Article 24. McManus, J. & Wood-Harper, T. (2007). Understanding the sources of information systems project failure. Management Services, 51, 38–43. Meglino, B. & Korsgaard, A. (2004). Considering rational self-interest as a disposition: Organizational implications of other orientation. Journal of Applied Psychology, 89, 946-959. Montealegre, R. & Keil, M. (2000). De-escalating information technology projects: Lessons from the Denver international airport. MIS Quarterly, 24, 417-447. Morrison , Z., Robertson, A., Cresswell, K. , Crowe, S. & Sheikh, A. (2011). Understanding contrasting approaches to nationwide implementations of electronic health record systems: England, the USA and Australia. Journal of Healthcare Engineering, 2, 25-41. Nandhakumar, J. (1996). Design for success?: Critical success factors in executive information systems development. European Journal of Information Systems, 5, 62–72. Newman, M. & Sabherwal, R. (1996). Determinants of Commitment to Information Systems Development: A Longitudinal Investigation. MIS Quarterly, 20, 23-54. Nisbett, R. & Ross, L. (1980). Human inference: Strategies and shortcomings of social judgement, Englewood Cliffs, Prentice-Hall. Northcraft, G. & Wolf, G. (1984). Dollars, sense, and sunk costs: a life cycle model of resource allocation decisions. Academy of Management Review, 9, 225-234. Pan, S., Pan, G. Newman, M. & Flynn, D. (2006). Escalation and de-escalation of commitment to information systems projects: Insights from a project evaluation model. European Journal of Operational Research, 173, 1139-1160. Pan, G., Pan, S. & Newman, M. (2009). Managing information technology project escalation and de-escalation: An approach-avoidance perspective. IEEE Transactions on Engineering Management, 56, 76-94. Pankratz, O. & Basten, D. (2013). Eliminating Failure by learning from it – Systematic review of IS project failure. Proceeding of 34th International Conference on Information Systems, Milan, Italy. Pender, S. (2001). Managing incomplete knowledge: why risk management is not sufficient. International Journal of Project Management, 19, 79-87. Peterson, D., Kim, C., Kim, J. & Tamura, T. (2002). The perceptions of information systems designers from the United States, Japan, and Korea on success and failure factors. International Journal of Information Management, 22, 421-439. Petter, S., DeLone, W. & McLean, E. (2013). Information Systems Success: The quest for the independent variables. Journal of Management Information Systems, 29, 7-62. Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide) (Fifth Ed.). Newtown Square, PA: Project Management Institute. PM Solutions. (2011). Strategies for project recovery. [online] http://www.pmsolutions.com/collateral/research/Strategies for Project Recovery 2011.pdf [accessed23 July 2014] Robey, D. &. Keil, M. (2001). Blowing the whistle on troubled software projects. Communications of the ACM, 44, 87-93. Robinson, W., Pawlowski, S. & Volkov, V. (2003). Requirement interaction management. ACM Computing Surveys, 35, 132-190. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 21 Ross, J. & Staw, B. (1986). Expo 86: An escalation prototype. Administrative Science Quarterly, 31, 274-297. Rozenes, S. (2011). The impact of project management methodologies on project performance. International Journal of Information Technology Project Management, 2, 64-73. Rutledge, R. (1994). Escalation of commitment in groups and the moderating effects of information framing. Management Research News, 17, 12-24. Sauer, C. (1993). Understanding Support - Lessons from a Case Study. Australasian Journal of Information Systems, 1, 63-74. Schmidt, R., Lyytinen, K., Keil, M. & Cule, P. (2001). Identifying software project risks: An international Delphi study. Journal of Management Information Systems, 17, 5-36. Seligman, M. (1975). Helplessness: On Depression, Development, and Death. San Francisco, W. H. Freeman. Sharma, R. & Yetton, P. (2011). Top management support and IS implementation: Further support for the moderating role of task interdependence. European Journal of Information Systems, 20, 703-712l Sherer, S. (1992). Software failure risk: Measurement and management. New York, Plenum Press. Silverman, D. (2006). Interpreting qualitative data, Thousand Oaks, Sage. Smith, H. & Keil, M. (2003). The reluctance to report bad news on troubled software projects: a theoretical model. Information Systems Journal, 13, 69-95. Smith, H., Keil, M., & Gordon, D. (2001). Keeping mum as the project goes under: Toward an explanatory model. Journal of Management Information Systems, 18, 189-228. Stake, R. (1995). The art of case study research, Thousand Oaks, Sage. Staw, B. (1976). Keep-deep in the big muddy: a study of escalating commitment to a chosen course of action. Organizational Behavior and Human Performance, 16, 27-44. Staw, B. (1981). The escalation of commitment to a course of action. Academy of Management Review, 6, 577-587. Staw, B. & Ross, J. (1987). Behavior in escalation situations: Antecedents, prototypes, and solutions. Research in Organizational Behavior, 9, 39-78. Sumner, M. (2000). Risk factors in enterprise wide information management systems projects. Proceeding of ACM SIGCPR Conference on Computer Personnel Research, Chicago, US, 180–187. Talukder, M. & Quazi, A. (2010). Exploring the factors affecting employees’ adoption and use of innovation. Australasian Journal of Information Systems, 16, 1-30. Teller, J. (2013). Portfolio risk management and its contribution to project portfolio success: An investigation of organization, process, and culture. Project Management Journal, 44, 36-51. Tiwana, A. & Keil, M. (2004). The one-minute risk assessment tool. Communications of the ACM, 47, 73–77. Wallace, L., Keil, M. & Rai, A. (2004). How software project risk affects project performance: an investigation of the dimensions of risk and exploratory model, Decision Science, 35, 289-321. Wilton, D. (2005). A tale of two projects: Why it projects fail (and why they sometimes actually succeed). Australian Journal of Information Systems, 12, 134-146. Australasian Journal of Information Systems Lin & Parinyavuttichai 2015, vol. 19, pp. 1-22 Project Risks as Emergent Phenomena 22 Winch, G. (2008). Towards a theory of escalation in major project organising. [online] https://phps.portals.mbs.ac.uk/Portals/49/docs/Escalation on Major Projects.pdf [access on 05 June 2014] Wright, M. & Capps III, C. (2010). Runaway information technology projects: A punctual equilibrium analysis. International Journal of Information Technology Project Management, 1, 53-79. Yeo, K.T. (2002). Critical failure factors in information systems projects. International Journal of Project Management, 20, 241-246. Yin, R. (2009). Case study research: Design and methods. Thousand Oaks, Sage. Copyright: © 2015 Lin & Parinyavuttichai. This is an open-access article distributed under the terms of the Creative Commons Attribution-NonCommercial 3.0 Australia License, which permits non-commercial use, distribution, and reproduction in any medium, provided the original author and AJIS are credited.