Interpreting Key Issues in IS/IT Benefits Management - Semantic Scholar

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Interpreting key issues in IS/IT benefits management Gurpreet Dhillon College of Business, Box 456009 University of Nevada Las Vegas Las Vegas, NV, 89154, USA Email: [email protected] 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 management aspects through two information system implementation case studies.

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 [9]. 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 [12]; [21]). Nearly a decade ago the Index Systems poll of 240 senior information systems (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 and Connolly, 1988). A survey of UK businesses by Ward et al [21] 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 gaining 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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1


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 [3]; [1]). Benjamin and Levinson [1] 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 bringing IT to the organization. Dhillon and Backhouse [7] also stress on consideration being given to the informal softer issues if risk of failure is to be avoided.

Johnston and Yetton [10] 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 [8]; [4]). 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 [17]; [1]; [15]), a study by McGolpin and Ward [14] 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.

Formal training/education program Some benefits can be linked to formal training and education programs

IT System Has few benefits on its own

Organizational environment The informal organizational environment affords the business changes where most benefits are embedded

Figure 1. A high level view of benefits dependency

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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2


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 [11]; [6]; [2]). 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 figure 1).

realization and IS/IT evaluation (e.g. [16]; [18]; [13]; [5]). Findings presented in this paper are drawn form casework carried out during 1995-98. The conduct of the case studies was informed by the Walsham’s notion of interpretive research (see [20]; [19]). Data was 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.

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 figure 1. However, the majority of real benefits will come from changes within the business itself.

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 anticipated benefits. It further suggests that benefits, tangible and intangible, often reside in an organizations internal and immediate context.

Figure 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 figure 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.

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 exists 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.

3. Empirical study This section presents two case studies. Case one focuses on a British hospital for people with learning disabilities where an IT system was being developed for supporting organizational processes. Case two 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 the previous section, 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

3.1. Case of the hospital information system

3.1.1. The organizational environment

Given that the hospital exclusively looks after psychiatrist 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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3


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 is done by a multidisciplinary team made up from 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 to 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. Although they agreed with the importance placed on managing the information, they were unsure if an allencompassing 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 however 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 healthcare 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 SSADM - Structured Systems Analysis and Design Methodology). 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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4


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.

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 computerbased solution may seem to promise substantial benefits, these can not 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. The 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 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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5


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.

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, there 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 systems’ use in other departments. Unsatisfactory use of the system carried on for nearly two 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.

3.2.3. Systems Design

4.1. Drivers

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 the previous section, 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 ESLs business world forced a particular way of working on the 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".

When considering key drivers necessary for a successful IS/IT investment, the following issues emerge:

Implementation was carried out through Oracle. The completed system reflected the 'world-view' of the systems developers. It took nearly fifteen months to complete the project. The physical implementation and

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 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 ESLs 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

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6


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 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 a number of drivers that were operating, such as the move from specialists to generalists, the models of systematic monitoring, single line of command, and integrated structure, 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. For example 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 healthcare scene at the hospital and the business operations at ESL.

4.2 Analysis and Planning of Benefit Types The analysis of the two case studies suggests that prior to any IT based application development, there is a needs 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 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 the choosing 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.

4.3.

Organizational Context

An understanding of organizational context in relation to successful IT based solutions can not 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 the 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 introduction 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.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7


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 suggests 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:

• The Types of Benefits being sought and where they will appear • 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, and • charting the changes at all levels necessary to get the benefits. • conversely since things do change when people work differently some assessment must be made of unexpected and unwelcome outcomes.

5. Conclusion

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.

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 analyses benefit drivers; benefit types; and the organizational context especially stakeholders’ expectations and roles. It follows that for IS/IT success that the enabled benefits and the associated changes should be the focus of any IS/IT developmental activity.

In the interests of achieving success significant attention should be paid before any systems method work commences to three factors in the wider environment. These are: • The Drivers which lead to the IT investment being contemplated in the first place

The hospital information systems and customer service information systems case has 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

Success of an IS/IT implementation will be experienced and defined by the stakeholders within the wider (informal) environment of the systems work. It will not be encountered or defined from within the IT system itself nor from within the formal system which the IT system supports.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8


were interested in improving the level of their services, the manner in which change was introduced was somewhat dubious. There were apparently a number 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.

based on escalation theory. Journal of Management Information Systems, 1995. 11(3): p. 67-87. 12. Keil, M. and D. Robey, Turning around troubled software projects: an exploratory study of the deescalation of commitment to failing courses of action. Journal of Management Information Systems, 1999. 15(4): p. 63-87.

6. References

13. McGolpin, P. An examination of the inter-related factors and issues affecting the degree of success with strategic information systems: throughout the application lifecycle. Unpublished PhD Thesis. Cranfield University School of Management, UK, 1996.

1. Benjamin, R.I. and E. Levinson, A framework for managing IT-enabled change. Sloan Management Review, 1993(Summer): p. 23-33.

14. McGolpin, P. and J.M. Ward, Factors influencing the success of Strategic Information Systems, in Information systems: an emerging discipline, J. Mingers and F. Stowell, Editors. 1997, McGraw Hill.

2. Blonkvist, C.L. and S.C. Goble, Re-engineering isn't the only answer. Manufacturing Systems, 1994(February): p. 52-56.

15. McKersie, R.B. and R.E. Walton, Organizational Change, in The corporation of the 1990's, M.S. Scott Morton, Editor. 1991, OUP. p. 244-277.

3. Brynjolfsson, E. and L.M. Hitt, Beyond the productivity paradox. Communications of the ACM, 1998. 41(8): p. 49-55.

16. Miller, K. and D. Dunn, A framework for postimplementation evaluation aimed at promoting organizational learning: a case of looking into the past to solve problems of the future, in Managing information technology resources in organizations in the next millennium, M. Khosrowpour, Editor. 1999, Idea Group Publishing: Hershey. p. 411-418.

4. Burn, J. and C. Szeto, Effective management of information technology: closing the strategic divide, in Business Information Technology Management: closing the international divide, P. Banerjee, et al., Editors. 1998, Har-Anand: New Delhi. p. 522-536. 5. Canevet, S. The role of information systems evaluation across an extended system life cycle. Unpublished PhD Thesis. University of London, 1996. 6. Dhillon, G. Complex managerial situations and the development of computer-based information systems. in BIT '95. 1995. Manchester Metropolitan University, UK. 7. Dhillon, G. and J. Backhouse, Risks in the use of information technology within organizations. International Journal of Information Management, 1996. 16(1): p. 65-74. 8. Henderson, J.C. and N. Venkatraman, Strategic alignment: leveraging information technology for transforming organizations. IBM Systems Journal, 1993. 32(1): p. 4-16. 9. Johnson, J., Chaos: the dollar drain of IT project failures. Application Development Trends, 1995. 2(1): p. 44-47.

17. Prager, P.P. and M.H. Ovenholt, How to create a changed organization. Information Systems Management, 1994(Summer): p. 64-70. 18. Serafeimidis, V. and S. Smithson, The management of change for information systems evaluation practice: experiences from a case study. International Journal of Information Management, 1996. 16(3): p. 205-218. 19. Walsham, G., Interpreting information systems in organizations. 1993, Chichester: John Wiley & Sons. 20. Walsham, G., Interpretive case studies in IS research: nature and method. European Journal of Information Systems, 1995. 4(2): p. 74-81. 21. Ward, J., P. Taylor, and P. Bond, Evaluation and realization of IS/IT benefits: an empirical study of current practice. European Journal of Information Systems, 1996(4): p. 214-225.

10. Johnston, K. and P. Yetton. Integrating IT divisions in a bank merger: fit, compatibility and models of change. in 4th European Conference on Information Systems. 1996. Lisbon, Portugal, July 2-4. 11. Keil, M., et al., Understanding runaway information technology projects: results from an international program

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

9