1 Introduction

The world of information systems (IS) in organizations provides numerous examples of successful IS implementation providing benefits for both organizations and the employees working for them. These benefits include improved profitability and improved organizational performance (e.g. Devaraj and Kohli 2003; Hendricks et al. 2007; Melville et al. 2004; Sabherwal et al. 2006), as well as efficient and effective business processes or working routines on an individual level (e.g. Burton-Jones and Gallivan 2007; Gable et al. 2008; Igbaria and Tan 1997).

Nonetheless, numerous examples of IS implementation failures are reported (Nelson 2007) leading to negative consequences for the organizations in terms of financial losses and other risks (Bruque et al. 2008; Laumer et al. 2012; Maier et al. 2013). High-profile examples of IS implementation failures are Hewlett-Packard’s (HP) failure in 2004 that had a financial impact of $160 million (Koch 2007), Nike’s failure in 2000 that cost $100 million in sales and resulted in a 20 % drop in stock price (Koch 2004), and Hershey Foods failure that caused the stock to decrease by 8 % (Koch 2002). In the public sector, numerous examples of IS failures are also reported: for example, more than 27,000 students at the University of Massachusetts (as well as Stanford and Indiana University) had to deal with malfunctioning portals and ERP applications that left them at best unable to find their classes and at worst unable to collect their financial aid checks (Wailgum 2005). One consequence of IS failure is often a dispute between software vendors and their customers about the reasons and responsibility for the huge financial loses thereby incurred. For example, the garbage-disposal firm Waste Management is embroiled in a $100 million legal battle with SAP over an 18-month installation of its ERP software. Waste Management complained that SAP executives participated in a fraudulent sales scheme that resulted in the massive failure, whereas SAP claimed that Waste Management failed to define its business requirements accurately, and to provide sufficient, knowledgeable, decision-empowered users and managers to work on the project (Wailgum 2009).

These examples show that the reasons for a successful or failed IS implementation are complex and contested, as different stakeholders and perspectives are involved. Therefore, it is the objective of this paper to discuss and debate reasons for the success or failure of IS in organizations and to provide some directions for future research. Despite the rich body of research knowledge on IS failure, the rate of failure has not notably abated and failed projects continue to occur (Nelson 2007). This paper will highlight current debates on IS success and failure. It is based on the Panel discussion entitled “The Information Technology Paradox: Why Some Companies Succeed and Some Fail?” which took place at the 2013 conference of IFIP WG8.6 in Bangalore. The Panel reflected on different perspectives and directions for future research on IS success and failure in organization.

The reminder of the paper is as follows. In the next section, existing research on IS success and failure will be summarized. Afterwards, the different statements of the Bangalore panelists are presented each discussing IS success and failure from a different perspective. These diverse ideas and viewpoints are then brought together, and directions for future research are outlined.

2 Debate in existing literature

In general, “failure” and “success” are tricky but well-known words in the IS field; they are hard to define, but extensively researched. IS research has focused for decades on both outcomes providing several explanations regarding IS failure and success in organizations. The following section focuses on this debate in the existing literature highlighting the most common explanation for the varying fortunes of IS initiatives.

2.1 Information systems success

IS success is one of the oldest research traditions in IS research. At the first ICIS conference (International Conference on Information Systems) in 1980 questions regarding what is and what determines IS success were raised (Petter et al. 2013). The seminal paper by DeLone and McLean suggested that IS success should be the preeminent dependent variable for the IS field (DeLone and McLean 1992). They proposed a taxonomy of six interrelated variables to define IS success: System Quality, Information Quality, Use, User Satisfaction, Individual Impact, and Organizational Impact. Since the original publication of their model in 1992, researchers have investigated, modified, or extended the concept of IS success (Dwivedi et al. 2013a; Larsen 2003; Petter et al. 2008, 2013; Rana et al. 2013a; Seddon 1997; Seddon et al. 1999; Urbach et al. 2009). One of the major extensions is the service quality dimension of information technology (IT) departments (Petter et al. 2013), incorporated in an updated model published in 2003 (Delone and McLean 2003). The original and revised models are among the most cited frameworks in IS research (Lowry et al. 2007) and have been validated by numerous studies as good predictors of IS success (e.g. Iivari 2005; Kulkarni et al. 2007; McKinney et al. 2002; Petter et al. 2013; Rai et al. 2002; Seddon 1997).

Several literature reviews have supported the explanatory power of the IS success model (Petter et al. 2013). Petter et al. (2013) identify 43 determinants that have been posited to affect one or more of the IS success variables. These 43 success factors are organized into three dimensions: tasks, people, and structure. Table 1 (based on Petter et al. 2013) provides an overview of those factors which have been evaluated as significant for at least one of the six variables used to define IS success. These determinants, and the different dimensions of IS success as proposed by Delone and McLean (2003), can be described as the state-of-the art of IS success research.

Table 1 IS Success (Petter et al. 2013)
Full size table

2.2 Information systems failure

Studies focusing on IS failure, rather than success, have also been prominent over the last four decades. Such studies focus on the shortfall between actual and required performance (Bignell and Fortune 1984). IS failure can be defined as “either the implemented system not meeting the user expectations or inability of creating working or a functioning system” (Ewusi-Mensah 2003). In this context, the need to learn from failures has been discussed when implementing IS in organizations (Scott and Vessey 2000). Nonetheless, many case studies of IS failure are described and discussed in the literature, and different causes and consequences of IS failure have been proposed (e.g. Avison and Wilson 2002, Barker and Frolick 2003, Beynon-Davies 1995, 1999; Bussen and Myers 1997; Fitzgerald and Russo 2005; McGrath 2002; Nelson 2007; Pan et al. 2008; Scott and Vessey 2000). The resulting reasons for IS failure are as divergent as the projects themselves.

Based on the analyses of different studies, several concepts have been proposed to describe the concept of IS failure and its determinants. Early approaches include Lucas (1975), Lyytinen and Hirschheim (1988), and Sauer (1993). These authors discuss IS failure largely from a social and organizational point of view. For example, Lyytinen and Hirschheim (1988) highlight the importance of correspondence, process, and interaction factors, and Sauer (1993) of termination factors causing IS failures (see Table 2).

Table 2 IS Failure
Full size table

These early concepts of IS failure have been extended during the last couple of decades with a stronger focus on an IS project, or project management, perspective. Nelson (2007) analyzed 99 IS projects and identified 36 classic mistakes which determine the likelihood that an IS fails. He categorized these mistakes into four categories: process, people, product, and technology. The first category “process” focuses on IT project management factors, including both the management process and technical project management methodologies. The “people” category summarizes factors related to the people involved in a project, and the “product” category represents the characteristics of the project itself (such as size and urgency, but also its goals such as performance, robustness, and reliability). The final category “technology” summarizes those factors leading to IS failures which are based on the use and misuse of modern technology. Table 2 provides an overview of the four categories and the 36 classic mistakes as highlighted by Nelson (2007).

Additional approaches (e.g. Al-Ahmad et al. 2009; Barclay 2008; Dwivedi et al. 2013b; Kappelman et al. 2006; Schmidt et al. 2001; Wallace et al. 2004; Yeo 2002) have provided alternative perspectives on common causes of IS project failure, for example the concept of “project escalation” (Keil et al. 1998). Strong and Volkoff (2010) provide a technology focused categorization of enterprise system failure in organizations, proposing the concept of “organization-enterprise system misfit” to explain IS failure. They conclude that a misfit in functionality, data, usability, role, control, and organizational culture can all contribute to the risk of failure.

Furthermore, there is a corpus of research focusing on developing countries. High failure rates have been reported in developing countries fore-government initiatives and “ICT for development” projects. For example. Heeks’ (2002, 2006) model of design-actuality gaps seeks to explain such high rates of failure. It identifies various archetypes, such as country-context gaps, hard-soft gaps, public-private sector gaps, all affecting IS outcomes.

Research on user resistance is also an important strand in the literature on IS failure (Bhattacherjee and Hikmet 2007; Hirschheim and Newman 1988; Laumer and Eckhardt 2012). This stream of research focuses on the sources of resistance in end-users and on behavioral manifestations of resistance, such as non-compliance, non-usage, or sabotage (Gibson 2003). For example, Klaus and Blanton (2010) identified several sources of user resistance; they highlighted the importance of individual, system, organizational, and process issues of user resistance causing IS failure in organizations. For non-organizational IS, such as social networking sites (e.g. Maier et al. 2012, 2014), the causes and consequences of negative user perceptions are also discussed.

In summary, research investigating IS failure proposes different perspective on this phenomenon as summarized by Table 2. Taken together, Tables 1 and 2 generate a wide range of explanatory factors for the differing fortunes of IS developments. Similar factors appear in both tables, and broadly fall into three overall areas of explanation: people, organization and technology, with process as the underlying driver of the three. Some factors relate to the development process, whereas others relate to the implementation and evaluation stage of IS in the organization. The temporal dimension has been found to play a central role in the understanding of the explanatory factors of IS success and failure in an organizational context (Alter 2013; Pettigrew et al. 2001).

The strength of having a set of explanatory factors is that it helps identifying common characteristics across cases. Such “factor research” (Mohr 1982) has, however, been widely discussed and criticized in IS research (for a recent discussion see Orlikowski 2010). The major criticism is that it “black-boxes” categories of explanations. The Bangalore Panel provided an opportunity for the research community along with practitioners to open the black-box and discuss the issue of success and failure of IS from a range of perspectives, highlighting some shortcomings of prior research and pointing out some directions for future research.

3 Panelist contributions

The following sections discuss reasons for the success and failure of IS in organizations from the different perspectives of the Bangalore panelists. We invited each panelist to set out their position in up to 1000 words. Their various statements are compiled here in largely unedited form, expressed directly as they were set out. This creates some unevenness in the logical flow, but captures the distinctive orientations of the panelists and their recommendations for the development of the field.

3.1 Developer, top-management, and user perspectives on IS success and failure (Amany Elbanna)

The topic of IS success and failure has received the attention of researchers and practitioners over decades. However there are diverse perspectives regarding the definitions of IS success and failure and their measurement (Glass 2005; Linberg 1999). Different organizational groups define success and failure differently. Hence, success and failure could be seen from software developers, project management, top management, users, and client vs. supplier perspectives. Researchers have identified success in the IS context in different ways. A few of these perspectives are presented below.

3.1.1 System development perspective

System developers might hold a very different perspective on what constitute a successful project than project managers. The classic study of Linberg (1999) showed that while the project was a failure from a project management perspective, developers held a view of it being one of the ‘most successful’ projects. From a project management perspective, the project was 193 % over schedule, 419 % over budget, and 130 % over scope. However, from developers’ point of view, they found the project to be a triumph since the resulting software “worked the way it was intended to work” despite the technical challenges and complexity the developers had faced. Developers also valued their team work experience and considered their team performance to be high (Linberg 1999, p. 191). They tended to focus on the technical validity of the system in terms of execution, operation and evolution. Qualities such as security, maintainability, scalability, stability, availability among others are considered to be signs of development success. This engineering-orientated perspective considers the technical quality of the system and overlooks the organizational impact of the system.

3.1.2 Project management perspective

Project management tends to focus on resource consumption. Hence delivering projects on budget and on time are considered the main aspects of successful project management, and the lack of them is considered failure. The prime focuses is thus on process. Although product success in terms of actual use, user satisfaction and organizational benefits are inter-linked with project management, the causal relationship between them is weak (Van Der Westhuizen and Fitzgerald 2005). Therefore, the project management perspective on success seems to be rather distanced from models of IS success such as DeLone and McLean and Seddon (Delone and McLean 2003; Petter et al. 2008; Seddon 1997).

3.1.3 Top management perspective

The value of IT is an issue of great importance to Executives. They are typically concerned with measuring the value of the IT outcomes. Financial measures such as Return on Investment (ROI), net present value (NPV) and internal rate of return (IRR) are what executives expect to achieve for any corporate investment. However, research has shown that these financial measures might be suited to early generations of IT application, such as transaction processing and office automation (Martinsons et al. 1999), but are not well suited for evaluating later generations of IS, such as knowledge management systems, customer relationship management and social media. Accounting for intangible benefits, and achieving a quantitative representation of the value and benefits of IS to satisfy top management, continues to be problematic.

3.1.4 Users perspectives

Use of the system is considered a sign of its success. It is incorporated in most IS success models (Petter et al. 2008) (Delone and McLean 2003; Seddon 1997). Due to its importance, scholars have invested significant effort trying to predict the influence of information technology on usage (Adams et al. 1992; Benbasat and Barki 2007; Gefen and Straub 2000). Research has shown that the technical quality of systems does not guarantee their use, which is impacted by social, political and institutional factors (Brown 1998; Elbanna 2007; Jasperson et al. 2002; Markus 1983). A large body of research has been dedicated to examine user satisfaction. It shows the complexity of users satisfaction to the extent that even in the same organizations, some groups of users might be more or less enthusiastic than others to use the system (Cerpa and Verner 2009; Elbanna 2007).

3.2 A change management perspective on IS success and failure (Deborah Bunker)

Systems success and failure is a direct consequence of the effectiveness of collaborative development and change management processes to mitigate the disruptive effects of systems adoption in organizations. This takes place, almost always, in a complex business and/or social environment (Bunker et al. 2013). IS development approaches have evolved since the early days of computerized business systems, in an attempt to facilitate better systems outcomes, but failure to adopt IS effectively regularly occurs in spite of these efforts (Bunker et al. 2007).

Historically, IS have been developed with a fixed specification in mind and are built by highly skilled ICT personnel using pre-determined steps and approaches. Requirements gathering, systems development, testing and implementation are all regular patterns of activity that underpin the creation, adoption and use of an IS (Kroenke et al. 2012). More recently “agile” systems development methods have been applied to this task in order to better facilitate collaboration and change management (Qumer Gill and Bunker 2011), but nevertheless the end result is to work towards a “common” organizational view of what the system is and what it should do.

Recent research conducted by Bunker et al. (2013) in the development of IS to support dynamic operating pictures (DoP) for disaster management, highlights the problems associated with the use of pre-specified systems development approaches for the creation and adoption of dynamic emergent systems which must be designed to accommodate multiple views of an event or scenario. Disaster management systems are scenario driven and emergent (i.e. self-organizing and self-reinforcing) and they have many different and changing users “and therefore are generally applied to one-off courses of action. Disasters also move through many different phases … which require IS to be used in many different and flexible ways, i.e. preventing and preparing for a crisis as well as responding and recovering from it” (Bunker et al. 2013). As a result they also tend, however, to be poorly defined and structured.

In order to ensure the successful creation, adoption and diffusion of disaster management systems, or indeed any other scenario driven and emergent IS, we must re-examine our IS development approaches to encompass the:

  1. 1.

    Identification of key issues that form a barrier to multiple and diverse stakeholder involvement and collaboration in systems development. How do we ensure that everyone who has critical input into the design of the IS is able to have their input considered? If a business system fails, the consequences can be tragic enough, but when an emergent system (like those used for disaster management) fails, death and destruction can be a direct consequence.

  2. 2.

    Development and use of methods, frameworks and approaches to mitigate these barriers and encourage collaboration and change management both within and between organizations who must create, adopt and use IS in emergent scenarios. How can we ensure that the systems development approaches we use will ensure that effective collaboration and change management processes occur?

  3. 3.

    Understanding and development of approaches that help to counter human resistance to change (short versus long term views) as emergent systems necessitate change management processes which are ongoing and dynamic in nature. In order for these types of system to succeed in their objectives, a process of continuous change management is crucial due to their emergent and dynamic nature.

  4. 4.

    Understanding of the “cost of collaboration” and thinking differently about the areas of IS development, controls, user training, architectures and teams. Cost attributes are difficult to estimate utilizing normal accounting practices and therefore must be evaluated in other more relevant ways. The development of such systems may be part of a societal infrastructure, and the true nature and value of the investment in such emergent systems may not be realized until many years after they are established.

  5. 5.

    Specialization and mastery of broad systems skills for the development of appropriate IS for scenario management purposes. This may require retraining from a specialist systems building skills perspective to one that is more “boundary spanning” in nature.

The domain of disaster management systems is just one example of systems development, adoption and diffusion, which requires a re-think of how we successfully deliver emergent and scenario driven IS. Approaches based on an agreed systems specification are not relevant to these systems types which may also explain systems failures in other related domains i.e. financial systems, health system, political systems etc.

3.3 An IS implementation perspective (Michael D. Myers)

3.3.1 The conventional wisdom about implementing IT

In the relatively short history of the IS discipline we have learnt a lot about implementing information technology in organizations. Some of this knowledge about IT implementation has become what might be called common knowledge – this is the conventional wisdom about implementing IT that is taught in all our textbooks and reinforced in many research articles at regular intervals. This conventional wisdom can be summarized as follows.

First, it is important to get top management support. This is probably the most common injunction for the successful implementation of IT in both the IS research and practitioner literature. This injunction has been given for more than three decades (Markus 1983) and continues to be given today (Elbanna 2012). Second, it is important to have a project champion. Without a project champion, any reasonable-sized IT project is unlikely to succeed (Kirsch et al. 2002). Third, it is important to get buy-in from users. Much IS research has focused on user participation and user involvement (Barki and Hartwick 1994). A similar related injunction is that it is important to identify the problem before proposing a solution, and to understand user requirements before designing the system. This is considered to be one part of the general approach to problem solving (Bergman et al. 2002) and is a regular step in the IS development lifecycle. Fifth, in order to compare the claims of various vendors appropriately, it is a good idea to obtain “independent” advice from a consultant (Pollock and Williams 2009).

While the previous five injunctions have been given for over 20 years, over the past decade a few newer injunctions have appeared. Following on from the failure of business process reengineering, there is a recognized need to improve business processes before, or at the same time as implementing IT (Lee et al. 2008). Related injunctions are to adopt world’s best practice (Volkoff et al. 2007), and to aim for systems integration by standardizing systems, consolidating data warehouses and so forth (Lee and Myers 2004).

I believe that the above mentioned injunctions are widely accepted as common knowledge amongst both IS researchers and practitioners. While there may be some that I have not mentioned, these eight are amongst those that I would classify as the conventional wisdom about implementing IT.

3.3.2 The current score card: Re-thinking IT implementation

Despite the conventional wisdom about implementing IT, it seems that our batting average on the score card of IT implementation success is still not good. The failure rate of IT project continues to be high (Dwivedi et al. 2013c), just as it has been for many years (Ginzberg 1981). Hence my claim is that, while the conventional wisdom is useful, it does not guarantee success. The conventional wisdom might be necessary, but it is not sufficient. Maybe it is time to re-think IT implementation.

The conventional wisdom is derived from what I would call a positivist way of thinking. That is, the aim of positivist research is to try to discover some general laws about IT implementation that apply to all situations in all places and at all times. In other words, if we can discover some correlation between a particular input (e.g. top management support) and a particular output (IT implementation success), then ideally no matter what type of system, and with no concern for context, we have a guaranteed recipe for success.

I believe that this attempt to discover general laws about IT implementation success is useful and can provide some guidance for practitioners. However, it can never guarantee success, and in fact to rely on such knowledge is misguided. This is because, from an interpretive perspective, every IT implementation is slightly different, and no two contexts can ever be exactly the same (Klein and Myers 1999). Hence I think we need to re-think what we are doing when we are implementing IT.

A key point is, we are not just implementing a new technical system, but along with this new system we are potentially changing organizational structures and culture – the way people think and work. A new system also has political implications: as structuration theory has taught us, IT has the potential to enable some things and constrain others; some people win, and some people lose (Orlikowski and Robey 1991). Many of the key issues in IT implementation are thus related to politics, culture and people (Markus et al. 2000; Soh et al. 2000). In this volatile mix of ingredients, telling someone that they need top management support is sort of helpful, but in reality almost irrelevant. Much of my own research on IT implementation has focused on situations where almost all of the recommended injunctions for IT implementation success were faithfully followed, but the project was still a failure (Bussen and Myers 1997; Lee and Myers 2004; Myers 1994).

3.3.3 Future directions

Given this state of affairs, I suggest we need a more professional approach to implementing IT. A more professional approach means being aware of the conventional wisdom and the lessons that come from positivist research, but it also requires those implementing systems to be highly aware of the context. No set of injunctions will apply every time. Someone implementing IT needs to know which levers to pull, in which context, and at what time. Figuring out which ones to pull, in which context, and at what time is the next challenge for IS researchers.

3.4 An e-government perspective (Shirish C. Srivastava)

Assessing success and/or failures of information technology (IT) projects is a challenging task. Managers are often concerned with whether their IT investments are yielding appropriate returns. Nonetheless, substantial research on the subject has delineated interesting insights focused on resolving this apparent productivity paradox. Yet, most research examining the relationship between IT and productivity has focused on business enterprises, where the intended objectives are generally related to profitability and creating shareholder value. On the other hand, IT investments by the government, in the form of e-government initiatives, have multiple, nebulous and often competing objectives (Srivastava 2011). This apparent ambiguity in objectives poses additional challenges in assessing the productivity of such initiatives.

Recent e-government research acknowledges the challenges in assessing the failure and success of e-government initiatives. Based on prior research on the subject, in the following section, I will describe four key action points for governments and policy makers to consider when assessing the performance of any e-government initiative. These four action points can also serve as a guide around which future research on the subject can be conceptualized.

3.4.1 Define e-government project success/failure

More often than not, e-government initiatives are conceptualized in a manner similar to IT projects in business enterprises. This may have limited utility, as often the objectives of e-government initiatives are not related to profitability or creating shareholder value. For example, simply facilitating use of IT by the citizens may be the objective of a particular e-government project, as in the case of passenger reservation system (PRS) implementation by Indian Railways (Srivastava et al. 2007a). Using PRS by citizens did not create additional revenue for the Indian Railways but enhanced the convenience for the passengers. Other objectives may be related to just organizing and digitizing data, or even imbuing greater transparency in government functioning (Caseley 2004; Srivastava et al. 2007b). Whatever the case, it is essential to define the objectives of the e-government project upfront very clearly and unambiguously, and then measure the performance of the project against the conceived objectives.

3.4.2 Explicate the key measurement variables

Before starting the e-government project, it is not only essential to define the meaning of the project but it is also imperative to specify the key variables on which the performance needs to be monitored. These variables are highly contextualized and the same e-government initiative can have different objective variables in different countries, or even different regions within the same country. Hence, it is essential to explicate the key measurement variables in the specific project context (see Bamberger 2008; Johns 2006). This will help in better assessment of project performance.

3.4.3 Specify the level of analysis for the impact

Despite having few laid down objectives, because of their ubiquity, e-government initiatives have multiple intended and unintended impacts at different levels of analysis: individual, corporate, state, or country. Hence for any e-government initiative, it needs to be clearly specified the level of analysis at which the impact will be assessed. For example, an e-government initiative can impact individuals (e.g. Teo et al. 2008; Srivastava and Teo 2009), nations (e.g. Srivastava and Teo 2008), corporates (e.g. Srivastava and Teo 2010, 2011), regions (e.g. Madon 2005) or the government itself (e.g. Srivastava and Teo 2007). To avoid ambiguity, and enhance objectivity, in assessing the success and/or failure of any e-government project, the level of analysis for the impact needs to be clearly specified.

3.4.4 Identify the key stakeholders impacted

In the proposal for any e-government initiative, it is essential to specify the key stakeholders that will be impacted, either favorably or unfavorably. As e-government implementations impact multiple stakeholders simultaneously, more often than not there are intentional and/or unintentional tradeoffs amongst different stakeholder groups. Hence, it is not only essential to identify the key stakeholders to be impacted, but it is also important to specify that the impact will be measured from the perspective of which stakeholder group. It has been observed that even for simple IT project implementations by the government, different stakeholder groups may have different, competing objectives (Srivastava et al. 2007a, 2009).

In summary, owing to the complexity of the context in which e-government projects operate, it is a real challenge to assess their performance. Nonetheless, recent research has attempted to explicate frameworks specifying the different variables that need to be acknowledged for assessing e-government initiatives effectively (e.g. Srivastava 2011). The present section has summarized four key action points for governments and policy makers involved with e-government project implementation. Moreover, these action points can also serve as a guide for any future research examining the impacts of e-government initiatives.

3.5 ICT projects: An institutional reforms perspective (Ravishankar M.N.)

There is enough evidence now that we are indeed ‘making a better world with ICTs’ (Walsham 2012). However, it is equally true that many ICT projects fail to translate their noble aspirations into reality. In this brief note, I highlight one significant stumbling block facing ICT projects. Although I mainly draw on my experience of studying initiatives in India, I would argue that the problem outlined here is not unique to the Indian context. The broader issues it raises resonate more globally and could open up new research opportunities for the IS community. To contribute meaningfully to some of these emerging debates, however, IS scholarship needs to improve its interdisciplinary awareness and sensibilities.

Rapid advancements in ICT have made it possible to conceptualize and implement complex and ambitious projects. But for such initiatives to have a meaningful impact on the lives of a large number of people, the good health of other important institutions in a society is imperative. In the absence of a robust and reliable institutional infrastructure, many ICT projects can be termed as successful only in a very narrow sense of the term (Ravishankar 2013). India’s unique identification project (UID), which aims to allocate a unique 12-digit number to every resident of the country, provides a good illustration of this problem. The project has already assigned unique numbers to more than 400 million people. Considering the complex challenges of ICT design and implementation, logistics and private-public partnerships that the project presents, this is clearly a noteworthy achievement. The implementation team might claim, justifiably so, that they have succeeded in their mission.

But for the project to deliver on its bigger promises (e.g., improved access to essential services, especially for the underprivileged and excluded sections of the society) a host of other institutions need to get their act together quickly. If key institutions of governance such as banking, finance, law, legislature and bureaucracy do not become more efficient, reliable and accountable, the outcomes of the UID project are very likely to be underwhelming. The long-term goals of the project require these institutions to function in an ethical and transparent manner. At this stage, however, there is a growing perception that the systemic weaknesses in such important institutions could render the technologically advanced UID project toothless for quite some time. In other words, it would seem that the ICT infrastructure underpinning the project is way ahead of the surrounding institutions’ competence and commitment to the project.

A second interesting example that exemplifies the problem of a weak institutional infrastructure is www.ipaidabribe.com, a novel and popular ICT initiative launched by Janaagraha, a non-profit organization based in Bangalore. On this website, citizens upload information about bribes they pay to government officials. It is customary for people to upload vivid details of their bribe giving experience. Often, officials who demand bribes are named and shamed, their addresses and designations noted and the amount of money involved specified. Even if we assume that some of these stories are false, one would expect a serious investigation of these claims and some punitive action against those found guilty. Yet, because the institutions that are meant to purposively fight corruption are weak and mostly embroiled in petty political intrigues of their own, this fascinating ICT initiative’s role in curtailing corruption seems very limited at the moment. The ICT infrastructure, in this case, has helped generate very detailed information about a serious and governance-crippling form of corruption. Evidently, the project has tremendous informational value. But almost always, important institutional mechanisms are neither activated nor any action taken in response to the information made available through the project.

These two examples suggest that the scope and reach of many ICT projects, regardless of the sophistication of the technologies involved, depend on whether broader institutions of governance are well-prepared, ready and willing to act on the informational outcomes of the projects. Thus, while the rapid expansion of the global ICT infrastructure presents numerous possibilities to make a better world, policy designers can find it frustrating that institutions of governance cannot be reformed and fixed at the same pace.

What are the implications of these problems for the IS research community? They provide many opportunities for IS scholars to engage deeply with issues at the intersection of ICT and broader societal institutions. As a community that is committed to studying ICT and its relationship with society and organizations, the IS discipline is ideally placed to play a leading role in developing critical scholarship in this area. Such an endeavour would, of course, take many of us outside our comfort zones into disciplines like sociology, anthropology and public administration. Yet, it is precisely such a deeper inter-disciplinary awareness that will strengthen the impact that IS can have as a coherent academic discipline. In his keynote address to the conference, Geoff Walsham spoke of the researcher who was focused on ‘ICT and development’ research, but had never heard of the name Amartya Sen! The dangers of building walls around the IS discipline and adopting very narrow approaches in IS research are well-documented. In my view, we have an obligation to analyse, examine and explain the bigger problems surrounding ICT projects, and not restrict ourselves to studying such projects as self-contained units of analysis.

I conclude by suggesting two broad areas, where IS scholarship can make a bigger contribution to our understanding of ICT projects and their nexus with institutional arrangements. First, power and status asymmetries are often implicated in stories of ICT projects, more so when such projects have explicit social goals. Where do these power asymmetries come from? How do institutional ‘circuits of power’ (Clegg 1989) influence outcomes of ICT projects? Much of extant research has shied away from addressing these crucial questions. In my opinion, this is one important area for future IS research. Secondly, we need more longitudinal studies that document and explain the processes by which misalignments between ICT projects and institutional practices are resolved. Such process studies can help answer several vital questions: under what conditions do institutional infrastructures catch up with rapidly growing ICT infrastructures? How are conflicting institutional logics managed? Who are the key actors and what kinds of ‘institutional work’ (Lawrence and Suddaby 2006) do they undertake?

4 Discussion and recommendations for future research

Having set out the positions of the Panelists, we now discuss the spectrum of relevant views and opportunities for future research based on their contributions. We begin by noting that whereas some firms have experienced phenomenal success due to their technology investments, others continue to struggle. Indeed, in some situations, the mismanagement of IT has led to the bankruptcy of some firms. Further research is clearly needed to extend the understanding of IS success and failure, and it is against this interesting backdrop that we pose the question: “Why do some companies succeed and some fail?” We believe the answer to this question is multi-faceted, and that insights can be obtained by examining it through various lenses. One clear conclusion is that context matters when researching IS implementation outcome. For example, the results might be different reflecting the type of IS technology, be it ERP (Klaus 2000), enterprise content management (Laumer et al. 2013), or e-government (Dwivedi et al. 2011; Rana et al. 2013b, c; Shareef et al. 2011; Srivastava 2011). The way the IS is implemented will also be relevant (Sherer et al. 2003), as well as the different cultural or educational background of employees (Heeks 2006; Garrity 2001), or other pertinent factors that define the context of the implementation.

First, as Amany stresses, success and failure is a question of judgment, representing the different points of views of particular groups in an organization. While software developers might evaluate an IS project as a success, other groups (such as users or top management) might attribute it as a failure. This shows the potential chasm between different groups, within or indeed outside an organization (Garrity 2001; Laumer et al. 2010). In this context, we argue that it is only through crossing this chasm that a collective view of IS requirements and roles could emerge in order to avoid failures, and achieve greater success in implementing IS. This multi-perspectively view on IS development requires future research to examine the different views of stakeholders involved in the implementation process (e.g. Garrity 2001).

Second, as Bunker argues, IS success (and failure) is a direct consequence of the effectiveness of collaboration and change management processes to mitigate the disruptive effects of IS implementation (see also Sherer et al. 2003). Hence, the respective change management methods used might explain why some implementations are a success, whereas others fail. Effectiveness of collaboration and change management is dependent on identifying key issues that impede multiple (and often diverse) organizational stakeholder engagement. The development of methods, frameworks and approaches to mitigate these barriers is needed to facilitate more effective collaboration and change management. Such a change management perspective has been relatively neglected in both the success and failure stream of IS research. IS failure research in particular has focused on a project management, neglecting the various facets of implementing change. To redress an overly technical bias, Markus (2004) introduced the concept of “techno change”, and Alter (2008, 2013) proposed his concept of the “work system”. We concur with these authors that IS development should be theorized in future research within a broader view of the dynamics of organizational change in a complex business environment.

In a similar vein, Myers argues that implementing IS is more than just getting an IT artifact to run. The key argument from this perspective is that implementing IS in organizations changes the way employees work and think. As such, it always has political implications as some people win, and some lose (Orlikowski and Robey 1991). Simply following normative success factors might still result in IS failure (Bussen and Myers 1997; Lee and Myers 2004; Myers 1994) as the political context of an IS implementation is neglected. This is consistent with the ideas proposed by Strong and Volkoff (2010) and the general philosophical stance of critical realism (e.g. Volkoff and Strong 2013; Zachariadis et al. 2013). Therefore, we encourage future research to extent the body of knowledge by further investigating the political context of IS implementation, and how local contingencies affect the likelihood of success and failure, modulating the playing out of generic “laws”.

Fourth, Srivastava stresses the need to broaden our research horizons to devote more attention to the public sector. The moral imperatives are strong, but the challenges are likely to be tougher given the inherent complexity of the public sphere. It is argued that assessing success and failure of e-government initiatives is a challenge, as the definition of outcomes is ambiguous especially in relation to the divergent interests of different stakeholder groups.

Finally, Ravishankar uses the example of public IT projects (especially in an Indian context) to draw attention to power asymmetries, status differences and self-serving institutional agendas. Achieving change in IT infrastructure is easy by comparison with institutional reform. Furthermore, managers overestimate their own capabilities and competence to manage the trajectory of IT initiatives. Again, the argument is underlined of not treating IS as technical artifacts, but rather as work systems (Alter 2003). This will enable a better integration of institutional forces into the discussion of why IS fail or succeed as well as stressing the need for IS research to focus more on the alignment of IS with organizational processes, in line with concept of organization-enterprise system misfit (Strong and Volkoff 2010; Volkoff et al. 2007).

This paper has highlighted the rich traditions and nuances of IS research on success and failure, and has provided several promising proposals for the future direction of research. Open questions remain, such as the inherent contradictions of the success/failure dichotomy. This challenges simplistic definitions that see these outcomes as two sides of the same coin. For example, Glass (2005) pertinently asks “How can one categorize a project that is functionally brilliant but misses its cost or schedule targets by 10 %? Literalists would call it a failure, realists a success” (Glass 2005). Are failure factors simply the reverse of success factors, as the coin metaphor suggests? Are relationships between “independent and dependent variables” crudely linear: does more top management support, for instance, mean a commensurately greater likelihood of success? What contingencies bear on the complex pattern of causality in particular contexts? As our literature analysis and debate have shown, a myriad of factors are important in determining whether IS projects succeed or fail, and in the causal attributions made by different actors. In this paper, we have argued for different and new perspectives for extending research on IS success and failure, and given what we hope are some useful pointers for developing this agenda.