Your SlideShare is downloading. ×
Benefits Of Is It Implementations
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Benefits Of Is It Implementations


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. ARTICLE IN PRESS International Journal of Information Management 25 (2005) 502–515 Gaining benefits from IS/IT implementation: Interpretations from case studies Gurpreet Dhillonà Information Systems Department, Virginia Commonwealth University, 1015 Floyd Avenue, Richmond, VA 23284-4000, USA Abstract This paper examines those contextual issues that determine the success of a computer-based information system. It shows that a narrow technology-focused orientation in systems development is a limiting factor in realizing benefits. In doing so it argues that real benefits reside not within the IT domain but instead in the changes in the organizational activities that the IT system has enabled. The paper reviews such benefits through two information system implementation case studies. r 2005 Elsevier Ltd. All rights reserved. Keywords: IT benefits management; Interpretive study; Case study; Qualitative research 1. Introduction Over the years organizations have been striving to realize benefits of information systems (IS) and information technology (IT) investments. Indeed a phenomenal amount of money is lost because of inability of the organizations to realize IS/IT benefits. Figures coming from the US suggest nearly $59 million being spent in cost overruns and some $81 million in cancelled IS/IT projects (Johnson, 1995). Losses of this magnitude have often been attributed to the inability of organizations to carry out adequate IS/IT-related benefits management (e.g., see Keil & Robey, 1999; Ward, Taylor, & Bond, 1996). Nearly two decades ago, the Index Systems poll of 240 senior ÃTel.: +1 804 828 3183; fax: +1 804 828 3199. E-mail address: 0268-4012/$ - see front matter r 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.ijinfomgt.2005.08.004
  • 2. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 503 IS executives found that although 90% did not know how to measure the benefits of IT, more than 50% believed that IT investments were enhancing their performance (as reported in Computerworld, 1988; Connolly, 1988). A survey of UK businesses by Ward et al. (1996) found 86% of the respondents as saying that it was not possible to anticipate benefits. The main reason that benefits are identified and quantified seems to be in order to gain project approval. The survey returns indicated that in 47% of the cases, project justification methods overstated the benefits to get expenditure approval. However, once this ‘hurdle’ has been overcome, little further attention is paid to benefits, and most effort is expended on technical implementation. The findings of the surveys reported above reflect a degree of complacency on part of IS/IT users. One UK building society manager, when asked how IT investments were justified, was quoted as saying, ‘‘In larger projects, we mostly go by gut feel. If the project is small, we try for a return-on- investment’’ (Financial Times, 13 June 1989). As Symons (1991) notes: ‘‘the greater the expense and strategic importance of an information system, the less likely it is to be evaluated using a formal methodology’’. With respect to the use of formal methodologies, the Ward et al. (1996) survey found that only 50% of the organizations had a formal methodology (i.e., systems development, project management, or investment appraisal) and only 20% had implemented all three methodologies. Only a minority of organizations believed that these methodologies were effective in ensuring success. Given the above background, this paper seeks to provide insight into some factors that will ensure the delivery of benefits from IS/IT investments. The paper argues that although the choice of an appropriate methodology is important in ensuring project success, it is not the only factor. It is equally, if not more, important to examine the organizational context that the information system is being developed for. The paper further suggests that organizations will have successful IS/IT applications only when the drivers for investing in IT, the expected benefit set and the organizational mode of working have been carefully considered. These three aspects need to be integrated into a benefits management approach. The argument of this paper is conducted by evaluating a hospital information system and a customer service information system. 2. Understanding benefits management It is useful to have an understanding about the notion of ‘benefits management’ in the context of IS/IT. One means of doing this is to consider the ‘outcomes’, in that the benefits which are sought are the outcome of business changes, which have been brought about by the introduction and use of IT. The ‘benefits’ are then the difference between the desired outcome and the current situation. For instance, the outcome of an IT system implementation may be a staff reduction— the benefit is a cost saving. However, to be able to realize this benefit, it will be necessary to make changes in the way that the work is hitherto done. It will not be sufficient to merely install the IT application and hope for the savings. At the very least, some training will be required, and probably changes in tasks, roles and responsibilities (e.g., see Benjamin & Levinson, 1993; Brynjolfsson & Hitt, 1998). Benjamin and Levinson (1993) claim that the benefits of IT are often not realized because investment is biased towards technology and not towards managing change in process, organizational structure and culture. They conclude that managing change enabled by IT is at least as important as
  • 3. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 504 bringing IT to the organization. Dhillon and Backhouse (1996) also stress on consideration being given to the informal softer issues if risk of failure is to be avoided. Johnston and Yetton (1996) bring out another interesting issue regarding benefits management and business change. Their notion of fit and compatibility suggests that the IT configuration of an organization should match the organizational structures. Although the main focus of their paper is on integrating IT divisions during a merger, the concepts seem to be equally relevant within an organizational context. Similar arguments have been proposed by other researchers as well, particularly those who have focused on strategic alignment (e.g., see Burn & Szeto, 1998; Henderson & Venkatraman, 1993). Thus it can be suggested that the notion of IS/IT success (i.e. the management into existence of desired benefits) be fundamentally linked to changes within the business. Although the importance of having an approach to business change has been recognized in the literature (e.g., see Benjamin & Levinson, 1993; McKersie & Walton, 1991; Prager & Ovenholt, 1994), a study by McGolpin and Ward (1997) found that in addition to institutionalized change management practices, a well-defined benefits management process was the most significant factor in the success of IS/IT implementation. In general, it can be stated that the proposed benefits from an IT investment project must link in some way into the objectives of the business itself. Expenditure proposals should take the form of a business case with an explicit statement of how the system will contribute towards business objectives, goals or critical success factors via the changes in the business it will facilitate/support. The contribution should also be measurable—or at least observable—in terms of the business objective. If this is not achieved then there is significant risk that the project will be off-target in a business sense, will consequently not be owned by affected stakeholders, then subsequently slide into being merely technology implementation with an over-emphasis on technical functionality at the expense of business improvements. Findings from the literature support this assertion (e.g., see Blonkvist & Goble, 1994; Dhillon, 1995; Keil et al., 1995). Failure to engage with the truly important business objectives effectively restricts the contribution to low-level orders of benefit (e.g., small improvements in task efficiency). For success, there must be a clear dependency linkage from IT features which enable sets of changes in working practices to occur, that in turn leverage useful business changes which themselves contribute to a desired business goal. The linkage is best described in terms of the ‘fried egg’ analogy (see Fig. 1). The high-level view of stages of benefits dependence is a useful means to understand how benefits come from changes within the business. The technology component of an IT project is typically the focus for most of the project effort. The linkage mentioned above is often addressed merely through the adding-on of a training component to the project plan. This generally results in some benefits at the formal system level as shown in Fig. 1. However, the majority of real benefits will come from changes within the business itself. Fig. 1 also illustrates the issues of project scope and managerial responsibilities. For full benefits, both IT management and business management must be involved in the project, with clearly defined roles for the latter in the area of change. The ‘training’ component of a project is usually solely concerned with basic hands-on training in how to operate the new IT system. However, as Fig. 1 indicates, ‘education’ is also necessary in order that stakeholders understand why the IT investment is being made, what benefits they and the overall business will obtain, the necessary changes required and their role in achieving them. Such has been found to be an important factor in exploiting the full business potential of IT.
  • 4. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 505 Formal training/education program Some benefits can be linked to formal training and education programs Organizational IT System environment Has few benefits The informal organizational on its own environment affords the business changes where most benefits are embedded Fig. 1. A high-level view of benefits dependency. 3. Case studies This section presents two case studies. Case 1 focuses on a British hospital for people with learning disabilities where an IT system was being developed for supporting organizational processes. Case 2 relates to the implementation of a customer service information system in a computer manufacturing organization. The purpose of the case studies is to develop an understanding of deep-seated organizational issues related to IT benefits realization. As has been noted in Section 2, although there are a number of studies focusing on IS/IT success and IS/IT- related organizational change, there is a dearth of interpretative case studies focusing on realizing IT investment payoffs. The findings presented in this paper will add to the existing research in benefits realization and IS/IT evaluation (e.g., Canevet, 1996; McGolpin, 1996; Miller & Dunn, 1999; Serafeimidis & Smithson, 1996). Findings presented in this paper are drawn form casework carried out during 1996–2000. The conduct of the case studies was informed by Walsham’s notion of interpretive research (see Walsham, 1993, 1995). Data were collected from both primary and secondary sources. Primary sources covered various IS/IT project stakeholders and major decision-makers. Topic guides were prepared for each in-depth interview. Numerous probing questions were used to identify underlying patterns. Secondary sources were related to internal memos, publications and government reports. 3.1. Case of the hospital information system This case shows that an IT-based solution on its own adds little value to the organization. Substantial gains can only be achieved if there are commensurate business changes. The case illustrates that just an elegant systems design and implementation falls short of realizing the
  • 5. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 506 anticipated benefits. It further suggests that benefits, tangible and intangible, often reside in an organizations internal and immediate context. 3.1.1. Organizational environment The case study hospital provides services to people with learning disabilities through a number of sites. In line with the national initiative, service provision takes the form of a single line of command and an integrated structure. The hospital is dominated by a number of specialisms. Although formal communication lines exist among various functions, the day-to-day running of the hospital depends much on the informal communication among specialisms to coordinate work. The success of a diagnosis or a treatment plan of a patient, therefore, is largely dependent upon the ability of the specialists to adapt to each other. Given that the hospital exclusively looks after psychiatric patients, the hospital managers have a dominant belief that such patients can be best served by moving them into a natural community setting. Such a belief stems from the philosophy advocated by the central administrators. As a consequence, the health care delivery process within the hospital is viewed as a dynamic system where people with mental health problems enter the hospital, are offered treatment and discharged back into the community. All along the process, the emphasis is to encourage patients to stay in the community. The hospital administrators consider a two-fold advantage of such a system. First, patients with learning disabilities will be able to experience and live in a natural environment. Second, with patients moving out into the community, overhead cost of running a hospital will be substantially reduced. Hence, patients would only be admitted to the hospital if their condition deteriorates or when they need urgent specialist medical attention. Health care within the hospital is provided through a service specification, which is made up of a number of elements called care packages. Hence, for any patient there would be a number of relevant care packages. The individual mix of care packages would constitute a service specification. The purpose of defining care packages is to establish the cost of the service being provided. When a patient is referred to the hospital, a need assessment is done and an individual care plan is developed. The need assessment and the subsequent care plan implementation are done by a multidisciplinary team made up of nurses, physiotherapists, dieticians, doctors, etc. The hospital model for service planning considers multidisciplinary teams as central to the success of the health care delivery process. A key issue with the health care delivery process at the hospital is the need for timely availability of many sets of information, and a computer-based information system was seen as a means of filling the need. It was thought that such a system would not only help the hospital provide precise information on its activities, but also add value to the health care delivery process. It would also overcome certain current shortcomings such as the inability to perform audits and assess the effectiveness of resources used. Significantly, it was to embrace the care planning function mentioned above. 3.1.2. Towards an IT-based solution With respect to the need for an IT-based solution, interviews with members of the three professional groups (doctors, nurses and administrators) revealed conflicting ideologies—both organizational and professional. The doctors and nurses believed in the profession and its norms.
  • 6. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 507 Although they agreed with the importance placed on managing the information, they were unsure if an all-encompassing computer-based system was the ideal solution. They saw the new system as enforcing new goals and objectives onto the hospital environment. The managers, on the other hand, wanted to derive business value out of the health care delivery process. Though the nurses and doctors agreed with this in principle, they had their own ideas as to how it could be achieved. The main point of contention for the doctors and nurses was the nature of the management system designed by the managers (described above). The doctors felt that at a clinical level, the systems could not be utilized effectively largely because they did not reflect the very nature of clinical work. Even though the hospital focused attention on moving patients out into the community, the computer-based system was essentially geared to the needs of the residential patients, i.e., the long-stay patients in the hospital. In this respect, the objective of the clinical system was clearly out of touch with the new organizational policy of moving patients out into the community. The managers, however, did not agree with this objection raised by the doctors and the nurses. Further investigations revealed a lack of communication between the managers and the system analysts involved in carrying out requirement analysis. It became clear that the system analysts had only sampled those aspects of the hospital that were primarily residential in nature. It also became clear from the interviews with different members of the organization that there was a clear mismatch between the formally designed information system and the actual practices. Therefore, the IT system may neither contribute to productivity nor effectiveness of the organization. Furthermore, there was an inherent weakness in the informal organizational norms. This resulted in the clinical and business objectives not supporting each other. Since the various groups within the organization disagreed with the manner in which the information system was conceptualized, analyzed and designed, they felt that the computer-based system would impose unrealistic groupings onto members of the organization. Therefore, there was a risk that the information system would not be used. 3.1.3. Systems design The hospital information system project team and system developers regarded health care provision as an input–output process with patients coming into the hospital, being treated and then discharged into the community. This conception dominated the modeling activities of systems developers. Insufficient consideration was given to the impact of the system on the users. Having purportedly identified the problems and bottlenecks that slowed down the input–output process, the designers developed the logical view of the system (using structured systems analysis and design methodology—SSADM). The logical view was so heavily focused on the input–output process idea that it lacked a representation of the real operations. The IT-based system embodied the output of the above design process and formed an integral part of the health care delivery process. A key aspect of the system was the design of individual care plans for each patient. Since the health care delivery process and the related individual care plans did not represent the reality, the needs of the doctors were not met. The clash of logical input–output model vs. doctors’ ways of working shows itself dramatically in that the system as designed saw the various ward rounds that doctors made being decided by the care plan—whereas doctors would formulate care plans as a result of doing ward rounds. In fact, the doctors saw care plans and ward rounds as one evolving process not the hierarchy envisaged in the system.
  • 7. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 508 3.2. Case of ESL’s customer service information system This case illustrates the shortcomings of an IT-based solution that gives little credence to organizational change issues. The case study shows that although a computer-based solution may seem to promise substantial benefits, these cannot be realized unless the organizational context is understood. Following the argument presented in the previous case study, this case also identifies the inadequacies of structured methods in systems design. The case is set in Electronic Systems Limited (ESL), an organization involved in the manufacture, sales and marketing of PC clones and peripherals. 3.2.1. Organizational environment This section describes the customer service function of ESL, a manufacturer of PC clones and various peripherals. At the time of the study, ESL had been in business for some 15 years. The organizational and manufacturing processes were mature. The company boasted of selling PCs and various peripherals at very competitive prices. Because of the nature of the business, the company laid a lot of emphasis on sales and marketing. In order to stay in business, it was important for the company to bundle free software and services along with the sale of a given PC. It also meant that the company was in a position to respond to the needs and expectations of the customers. Most of the time, the customer service component of the sale dealt with honoring the warranties and annual maintenance contracts. The success of maintaining the existing customer base and attracting new ones largely depended upon satisfying the current ESL customers. Since the very existence of ESL was based on increased sales volume, the company often ignored the ‘customer service’ component of the sales. Providing customer service was also a significant challenge for ESL. This was because most of the components (e.g., motherboards, memory chips, etc.) were procured at the lowest available price from numerous manufacturers in Taiwan and South Korea. Although a given batch of machines would have some level of standardization, it was very difficult to keep track of the details. This meant that whenever there was a problem with a machine at customer site, the service engineer was often opening a ‘black box’, not knowing what to expect. This meant that, more often than not, the particular component had to be removed and brought back to factory premises. The customers would be happy if customer service turn around time was reasonable and if ESL was in a position to identify the status of their complaint/service request. However, this was often not the case because the maintenance engineers were usually as baffled as the service engineers. This was because of two reasons. First, the maintenance department did not have any clue of the nature and type of parts used in the machines (e.g., the layout of motherboards for every batch of machines, etc.). Second, their competence was limited to card-level repair (i.e., if they diagnosed a fault in a particular card, it would be replaced by a new/alternative one). The combination of these two factors meant that customer complaints could not be addressed since the maintenance and customer service departments did not know the details of each of the parts used in the production of a PC. As a consequence, they were unable to maintain an inventory of cards and other parts that went into the production of each batch of PCs. Clearly, there were problems in the communication between various functional areas of ESL. To begin with, the materials and procurement department had to document the details for each batch. The production department had to maintain a strict discipline in maintaining the standards
  • 8. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 509 for each batch. Furthermore, the configuration of each production batch had to be communicated to maintenance and customer service departments. ESL recognized this problem and the management systems department was entrusted with the responsibility to provide an integrated computer-based system to support all necessary functions so as to increase the level of ESL’s customer service. 3.2.2. Towards an IT-based solution In assessing the nature and scope of the problem at ESL, interviews were conducted with prominent stakeholders in each of the concerned functional areas, viz. materials and procurement, production, maintenance, customer service and management systems. Discussions revealed conflicting viewpoints. The maintenance and customer service departments felt that they did not need a massive integrated computer-based system. They felt that it would be too laborious and time consuming to build such a system. All they wanted was a sufficient inventory of cards and parts that were used in each production batch. Managers in materials and procurement were not concerned with customer service. For them, the firm profited because of their ability to source components in a very cost-effective manner. They had a manual system that logged the details of each purchase. The production manager, on the other hand, did not communicate with materials and procurement. He worked on production schedules based on reports from the sales and marketing department. The management systems department managers felt that all departments had the right kind of information that is necessary to develop a good customer service information system, all that had to be done was integrate the individual systems. In developing a computer-based solution, the management systems department felt that they had to develop a huge database of all parts/components coming into ESL and linking them to machine numbers and production batches. They felt that by developing such a database, they would be able to provide the right kind of information necessary to provide better customer service. The production and materials and procurement departments disagreed with this approach. They felt that the development of a new computer-based system would radically change their existing business processes. They were unwilling to change. This would also have a knock-on effect on the marketing department since they usually focused on promising a lot to the retailers and then asked the production department to meet their deadlines. The management department conveniently ignored these concerns since it had the blessings of the CEO. 3.2.3. Systems design In realizing their mission to develop an all-encompassing IT-based solution, outside consultants were hired to carry out the systems analysis and design exercise. As in the case of the hospital information system discussed in Section 3.1, the management systems project team and the system development consultants considered the customer support problem domain as an input–output process. They viewed the cards and components coming into ESL, being put together by the production department and a finished product being sold by the sales and marketing department. The outside consultants had a limited understanding of the nature of the business, hence the input–output conception dominated their ‘world-view’. Using the Jackson Systems Development method, a logical view of the business was prepared through the use of Jackson diagrams. Clearly, the needs and expectations of dominant user groups within ESL were ignored. Furthermore, the mechanistic representation of ESL’s business world forced a particular way of working on the
  • 9. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 510 departments, hence failing to extract a part of the complex business process that needed automation. As one materials manager pointed out, ‘‘they are trying to do too much and change a lot of unnecessary tasks’’. Implementation was carried out through Oracle. The completed system reflected the ‘world- view’ of the systems developers. It took nearly 15 months to complete the project. The physical implementation and the later use of the information system was not without problems. Undoubtedly, the new customer service information system had much broader a scope than the original intent. Once the system went live, there were very few takers. Since the whole process began at the materials and procurement department, their buy-in was very critical to the success of the system, since it was radically changing material and procurement department’s ways of working. However, there was a limited use of the system in that department. This had a knock-on effect on the system’s use in other departments. Unsatisfactory use of the system carried on for nearly 2 years, eventually it had to be abandoned. 4. Summary and discussion This section presents a summary and discussion of the key emergent themes from the two case studies. First, the drivers for managing benefits are presented. Second, various planning issues related to kinds of benefits types are analyzed. Third, the importance of organizational context in the success of IT-based solutions is discussed. Finally, a list of key lessons from the case studies is presented. 4.1. Drivers When considering key drivers necessary for a successful IS/IT investment, the following issues emerge: Incompleteness of driver analysis: In both the cases, an unbalanced and unquestioning view of the drivers was taken. Both in the case of hospital information system and ESL’s information system, the system developers felt that a full and rigorous implementation of the respective systems would be the main driver and underscore the definition of success. In the case of the hospital, this system was nothing more than an administrators’ tool for establishing control and would not in itself deliver benefits. These should have come from the implementation of an improved health care delivery process. ESL presented a similar situation. This meant that certain broader contextual changes had to be put in place. Somehow, the information system and the changes became synonymous—thus ‘hows’ and ‘whats’ mingled to the point where the benefit to the whole organization became obscured by benefits to a lower level task set. Ignored drivers: The drivers for successful IS/IT application operating in the professional medical stakeholder groups and ESL’s functional departments were largely ignored—the system analysts fell short of seeking or recognizing the stakeholder groups definition of success. In the case of the hospital information system, a move towards community care was the key driver resulting in a ‘better health care system’ (a key benefit). However, the actual system ignored this driver and all system development efforts were aimed towards long-stay patients within the hospital. Similarly in the case of ESL’s system, the main problem was of maintaining a proper
  • 10. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 511 inventory of the right kind of spare parts within the maintenance department; this necessarily did not mean that the whole value chain of the business had to be redefined. In case of both the organizations, no attempt was made to get behind the number of drivers that were operating, such as, the move from specialists to generalists, the models of systematic monitoring, single line of command integrated structure and communication between different functional areas. Even if these are to be taken as ‘givens’ by the project team, they are capable of being interpreted in more than one way. Method drivers: Both in the case of the hospital information system and the customer service information system, the system developers placed too much faith in the structured methods. They believed that the methodologies were robust and capable enough to deal with the kind of issues addressed in this paper. Clearly, a number of early steps were missed and the mechanics of the method were applied too soon. Undoubtedly, it was important to understand the nature and scope of various business change issues and the total benefit, let alone the needs, expectations and buy-in by various stakeholders. Consequently, the project started as a technology project being done in the dark and stayed there. Value set drivers: The total driver set within the two case study organizations was a complex mixture of political, organizational and operational factors in which all parties had value sets that operated strongly, e.g., the government’s belief that the internal market strategy was very suitable for the National Health Service situation in case of the hospital information system; the hospital administration’s beliefs in ‘running things like a business’ and the value of accountability as measured by certain parameters; in ESL the management system department’s belief that all parts had to be tracked to the final destination; and finally the project team’s view in both organizations that an input–output process model was a suitable description of the whole health care scene at the hospital and the business operations at ESL. 4.2. Analysis and planning of benefit types Analysis of the two case studies suggests that prior to any IT-based application development, there is a need to consider the total ‘benefits set’, their location within an organization and related change management. Whenever an organization considers an IT-based solution, it is important to consider the nature and scope of various kinds of benefits. This means that planners need to identify and choose a particular benefits set. There could be some efficiency benefits that are realized through certain control activities. There could also be certain effectiveness benefits, such as improved customer care proffered by health care packages and service specifications. An organization would be better placed to deal with the benefits management if it can identify and choose a particular set of benefits. Both in the case of the hospital information system and the customer service information system, there was significant confusion as to the purpose of IS/IT investment. Investment payoff in such cases is minimal since no one understands the nature and scope of the benefits. The second aspect that needs to be considered is benefits location. This means asking the question that are the benefits intended to occur because of tighter control and hence the efficiency or are they going to be located at a managerial level emerging out of effective business processes? It is important to pinpoint benefit location since this sets the scene for benefits planning and change management initiatives. Benefits planning and change management initiatives focus on choosing
  • 11. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 512 the right kind of benefits vis-a-vis the investment objective and in instituting the necessary business changes. In both the case studies presented above, there was clearly a lack of emphasis on benefits planning and change management since there was a dominant belief that the new process would be so good and so different that there would be no difficulty in switching from the old ways of working to the new ones. 4.3. Organizational context An understanding of organizational context in relation to successful IT-based solutions cannot be understated. One of the main arguments of this paper has been that adequate technological benefits can only be realized if commensurate changes are instituted in the business. Based on analysis of the two case studies presented above, it becomes clear that little or no consideration was given to the context within which the IT-based solution was implemented. This resulted in laying little emphasis on the investment objective. Moreover, the systems (both at the hospital and ESL) aspired to ‘over-formalize’ modes of working. In fact, in the case of the hospital, the information system acquired a Trojan horse attribute, i.e., it was thought that its introduc- tion would force the formal way of working onto a predominantly informal environment. Whilst it might have worked in a low-level task situation, it demonstrably did not induce the desired changes higher up—which could only occur through careful change planning and management. Another important aspect of any IT-based solution is to consider the viewpoints of various stakeholders. Clearly, in both case study situations, an insufficiently wide group of stakeholders was consulted leading amongst other things to misunderstandings about the nature and scope of business processes and work practices. Inability to recognize various stakeholder viewpoints led to significant confusion. In the hospital information system case, lack of recognition (or avoidance of it) of the hierarchical split—clinicians vs. managers—and the weakness of the informal linkage between them was not thought through properly, even though the new care planning system was going to insist on new role definitions. In the case of ESL’s information system, exclusive focus on cost containment on part of the material and procurement department was not given significant attention while designing the new information system and hence the new business process. Clearly, the survival and profitability of ESL was dependent on procuring components at a very competitive price. In both cases, an organizational context factor was being addressed as a system element as though it were a process entity or some such, and again a solution to an issue in the wider environment was being sought at the formal system level. 4.4. Summary of key learning points The analysis of the case study and an evaluation of the benefits management issue suggest a number of key learning points. Although these are specific to the two case studies presented above, nevertheless, they suggest the growing importance of having a benefits focus in order to realize IS/IT investment payoffs. The key learning points can be enumerated as follows: Success of an IS/IT implementation will be experienced and defined by the stakeholders within the wider (informal) environment of the system. It will be encountered or defined neither from within the IT system itself nor from within the formal system which the IT system supports.
  • 12. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 513 The use of a systems methodology cannot define or generate success. The role of a methodology should instead be understood to be a means of ‘raising the safety net’ during systems development through the avoidance of known traps that have occurred in IS/IT projects. In the interest of achieving success, before any systems method work commences, significant attention should be paid to three factors in the wider environment. These are: the drivers which lead to the IT investment being contemplated in the first place, the types of benefits being sought and where they will appear and the organizational context—especially the roles and responsibilities of the stakeholders. The results of considering the above should be factored into a benefits realization plan within which the systems development plan is located. As a step towards avoiding failure, it is wise to analyze and then manage the perceptions and expectations of all stakeholders. Importantly, the impact on the stakeholders should be openly discussed and dealt with, as should their involvement in the changes that are needed to drive out the potential benefits of IS/IT. This is especially true for those who will experience disbenefits ‘for the greater good’. Since nothing improves until people start doing things differently, all IS/IT implementations can be regarded as change programs and the mechanisms and responsibilities for change become elements in the benefits plan. As part of the change management processes, some dependency linkages need to be established between the high-level objectives set in the wider environment through the formal system and on into the IT system as a means of: linking IT investment to business objectives, charting the changes at all levels necessary to get the benefits and conversely, since things do change when people work differently, some assessment must be made of unexpected and unwelcome outcomes. 5. Conclusion This paper has examined the various contextual features that determine the success of a technology-based system. It highlights that a narrow technology-focused orientation in systems development is a limiting factor in realizing benefits. Real benefits reside not within the IT domain but instead in the changes in the organizational activities that the IT system has enabled. Furthermore, these changes can be identified and planned for using an approach that analyzes benefit drivers, benefit types and the organizational context, especially stakeholders’ expectations and roles. It follows that for IS/IT success, the enabled benefits and associated changes should be the focus of any IS/IT developmental activity. The hospital information system and customer service information system case have provided a useful means to explicitly bring out the constraints in achieving benefits from IS/IT investments and has helped in conducting the argument. An analysis of the stakeholders in the hospital and ESL shows that although all concerned were interested in improving the level of their services, the manner in which change was introduced was somewhat dubious. There were apparently a number
  • 13. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 514 of hidden agendas that were being pursued by different members of the organizations. With such conflicting objectives, the success of any change initiative and the possibility of realizing any benefits are remote. Although this paper presents an analysis based on just two case studies, the findings form the basis for further work to enable generalization and wider applicability. References Benjamin, R. I., Levinson, E. (1993). A framework for managing IT-enabled change. Sloan Management Review (Summer), 23–33. Blonkvist, C. L., Goble, S. C. (1994). Re-engineering isn’t the only answer. Manufacturing Systems(February), 52–56. Brynjolfsson, E., Hitt, L. M. (1998). Beyond the productivity paradox. Communications of the ACM, 41(8), 49–55. Burn, J., Szeto, C. (1998). Effective management of information technology: Closing the strategic divide. In P. Banerjee, et al. (Eds.), Business information technology management: Closing the international divide (pp. 522–536). New Delhi: Har-Anand. Canevet, S. (1996). The role of information systems evaluation across an extended system life cycle. Ph.D. thesis, University of London, unpublished. Computerworld (1988). Editorial-The perception. Computerworld December 5. Connolly, J. (1988). Study: spending up; Stress on strategy. Computerworld November 28. Dhillon, G. (1995). Complex managerial situations and the development of computer-based information systems. In: R. Hackney (Ed.), BIT’95. Manchester Metropolitan University, UK. Dhillon, G., Backhouse, J. (1996). Risks in the use of information technology within organizations. International Journal of Information Management, 16(1), 65–74. Henderson, J. C., Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 32(1), 4–16. Johnson, J. (1995). Chaos: The dollar drain of IT project failures. Application Development Trends, 2(1), 44–47. Johnston, K., Yetton, P. (1996). Integrating IT divisions in a bank merger: Fit, compatibility and models of change. In Proceedings of the 4th European conference on Information Systems. 2–4 July, Lisbon, Portugal. Keil, M., Robey, D. (1999). Turning around troubled software projects: An exploratory study of the deescalation of commitment to failing courses of action. Journal of Management Information Systems, 15(4), 63–87. Keil, M., R Mixon, R., Saarinen, T., Tuunainen, V. (1995). Understanding runaway information technology projects: Results from an international program based on escalation theory. Journal of Management Information Systems, 11(3), 67–87. McGolpin, P. (1996). An examination of the inter-related factors and issues affecting the degree of success with strategic information systems: Throughout the application lifecycle. Ph.D. thesis, Cranfield University School of Management, UK, unpublished. McGolpin, P., Ward, J. M. (1997). Factors influencing the success of strategic information systems. In J. Mingers, F. Stowell (Eds.), Information systems: An emerging discipline. New York: McGraw-Hill. McKersie, R. B., Walton, R. E. (1991). Organizational change. In M. S. Scott Morton (Ed.), The corporation of the 1990’s (pp. 244–277). Oxford: Oxford University Press. Miller, K., Dunn, D. (1999). A framework for post-implementation evaluation aimed at promoting organizational learning: A case of looking into the past to solve problems of the future. In M. Khosrowpour (Ed.), Managing information technology resources in organizations in the next millennium (pp. 411–418). Hershey: Idea Group Publishing. Prager, P. P., Ovenholt, M. H. (1994). How to create a changed organization. Information Systems Management (Summer), 64–70. Serafeimidis, V., Smithson, S. (1996). The management of change for information systems evaluation practice: Experiences from a case study. International Journal of Information Management, 16(3), 205–218. Symons, V. (1991). A review of information systems evaluation: Content, context and process. European Journal of Information Systems, 1(3), 205–212.
  • 14. ARTICLE IN PRESS G. Dhillon / International Journal of Information Management 25 (2005) 502–515 515 Walsham, G. (1993). Interpreting information systems in organizations. Chichester: Wiley. Walsham, G. (1995). Interpretive case studies in IS research: Nature and method. European Journal of Information Systems, 4(2), 74–81. Ward, J., Taylor, P., Bond, P. (1996). Evaluation and realization of IS/IT benefits: An empirical study of current practice. European Journal of Information Systems(4), 214–225. Gurpreet Dhillon is a Professor of Information Systems in the School of Business, Virginia Commonwealth University, Richmond, USA. He holds a Ph.D. from the London School of Economics and Political Science, UK. His research interests include management of information security, ethical and legal implications of information technology. His research has been published in several journals including Information Systems Research, Information Management, Communications of the ACM, Computers Security, European Journal of Information Systems, Information Systems Journal, and International Journal of Information Management among others.