Information Systems (IS) Failure Case study and Synthesis

University Degree Business and Administrative studies

Executive Summary –

This paper discusses the concept of Information Systems (IS) failure as a whole. Also discussed are the various types of IS failures and the factors that differentiate an IS success or failure. The paper also deals with the Critical Success Factors (CSF) and Critical Failure Factors (CFF) associated with IS failures and an attempt is also made to correlate CSF and CFF. A detailed study of three cases related to IS failures are also undertaken and an attempt is made to synthesis and analyse the failure reasons based on the three cases. The lessons learnt from the cases are also looked into in detail. The paper concludes with a brief advise to managers/IT managers on the how to reduce the probability of an information systems failure.

Introduction –

An information system is a combination of computer hardware, communication technology and software designed to handle information related to one or more business processes. Organisations today need to handle a vast amount of information and rely on information systems for day to day activities. The dependence on Information Systems is so vital that it can make or break an organisation.

An effective information system serves to actively coordinate the work of many different organisational functions, from the basic administration support, to a company’s strategic management tool. It encapsulates and integrates a number of areas of business with an aim to increase efficiency and effectiveness of business practices. Hence importance must be given to designing, developing and maintaining the correct type of information system for a particular organisation which very much aligns with its business strategy.

Over the years Information Systems have evolved to an extent that it influences and manages an organisation’s business processes all across its departments or sub-units. Hence for such an investment to take place, there need to be a redevelopment and overall a partial or most likely a complete redefinition in the business practice. Any change in information system implementation thereby needs to bring about change all across the business structure to harness the benefits of such an investment.

Information systems are now far more sophisticated and that any failure in its development or implementation can further complicate the infrastructure and business as a whole as there are so many ways that they may occur. Each year companies lose millions of dollars on information system projects that fail and more are lost due to malfunctions of systems that have progressed beyond the implementation stage. Since information systems are complex and have many aspects attributed to each, failure (and success) can be manifested in many ways. A detailed view in this regard is given in subsequent topics in this paper.

Concept of Information Systems Failure –

Information Systems (IS) today are far more complex and revolves around so many factors that the nature of information systems failure is multi-faceted.

Over the last couple of decades a number of studies have been done in the field of IS failure, of which two approaches have come into prominence. One is Lyytinen and Hirschheim’s (1987) concept of Expectation Failure and the other is Sauer’s (1993) concept of Termination Failure.

According to Lyytinen and Hirschheim (1987), there are four main theoretical categories of IS failure:

Correspondence failure – Happens when there is a difference in the performance of the IS against the objective.
Process failure – Happens when development process cannot produce a system that works or produces a system that is over the planned budget in terms of factors like time, cost etc.
Interaction failure – Happens when IS is hardly ever used or the users have issue using the system.
Expectation failure - Lyytinen and Hirschheim (1987) defines this type of IS failure as containing all the above three types of IS failure. They also add that expectation failure is a very broad and detailed approach to IS failure and defines failure as the inability to satisfy the stake holder’s interest.

To broaden this analysis Lyytinen(1988) distinguished between development failure and use failure. Where the former is concerned about failure to mould the IS to the stakeholders interest and the latter talks about the failure to align the IS development to address stake holder's concerns.

But this model is heavily debated by Sauer (1993), who argues that an IS should be labelled failure only if all interest in progressing the IS project have ceased. He also states that all IS have flaws but the important aspect is the availability of support to correct the flaws. Otherwise the flaws can add up to generate a much bigger problem so as to abandon the project. The flaw concept clearly helps Sauer (1993) to distinguish termination failure from expectation failure.

The above concepts are a theoretical way of differentiating IS failure and success. Some of the empirical investigations methods of IS failure are explained briefly below.

Anecdotal evidence - Harel (1980) calls this as folk theorem and relies heavily on the validity of the anecdotal evidences.
Case studies - In Benbasat et al. (1987) views that this type of approach is more valid in problems where research and theory are still at an early stage. Since IS failures are multi faceted the case study approach is gaining importance as it gives a much clearer view of all details.
Survey research - Two notable studies under this concept was that of Lucas (1975) and Lyytinen (1988). Though Lucas (1975) based his study on a number of general hypotheses on IS failure, the data was not sufficient to explain all aspects of IS failures. While Lyytinen (1988) looked at IS failure from the perception of a systems analyst.

A clear distinction between IS project abandonment and IS failure was done by Ewusi-Mensah and Przasnyski (1994). They argued that IS failure is purely based on the failure to use the IS, while IS project abandonment is more to do with IS development process. This is very much in line with the development and use failure concept of Lyytinen (1988).

Through their study they concluded that the main factors that decided the success or failure of an IS was the organisational factors, particularly the involvement of senior management and extend to which end users are involved in the IS project development. Even though there has been considerable study in the field of factors contributing to IS success and failure now, much research has been done on finding a relationship among those factors. Fowler, Jeremy J. & Horan, Pat. (2007) identified six risk factors that are associated with IS failure, which can be defined as the Critical Failure Factors (CFF) and can be summarised as given below:

Lack of effective project management skills/involvement (e.g., Beynon-Davies, 1999; Doherty & King, 2001; Jiang, Klein, & Discenza, 2002; McGrath 2002; Wallace, Keil, & Rai, 2004),
Lack of adequate user involvement (e.g., Al-Mashari & Al- Mudimigh, 2003; Chung & Peterson, 2000,2001; Wallace et al., 2004),
Lack of top-management commitment to the project (e.g., Irani, Sharif, & Love, 2001; Koenig, 2003; Standish Group, 1999),
Lack of required knowledge/ skills in the project personnel (e.g., Jiang et al. 2002; Oz & Sozik, 2000; ),
Poor/inadequate user training (e.g., Das, 1999; Taylor, 2000), and
Lack of cooperation from users (e.g., Baskerville, Pawlowski, & McLean, 2000; Roberts, Leigh, & Purvis, 2000).

It is important now to look in detail at the Critical Success Factors (CSF) that contributes to the effective development of Information Systems.

Rockart and DeLong in (1988) listed eight areas which formed critical to the IS success. Each of which are briefly explained below:

Committed and informed executive sponsor
Operating sponsor
Appropriate IS staff
Appropriate technology
Management of data
Clear link to business objectives
Management of organizational resistance
Management of system evolution and spread
Evolutionary development methodology(or prototyping)
Carefully defined information and system requirements

Based on the six risk factors (CFF) that is associated with IS failure Fowler, Jeremy J. & Horan, Pat. (2007) studied a large Internet-based financial transaction service that was implemented in May of 2003 by a leading regional Australian based organization. They then tried to interview the participants in the project to list the factors that influenced the success of the project. Of the ten CSF (Rockart and DeLong (1988)) five were mentioned multiple times. Hence, Fowler, Jeremy J. & Horan, Pat. (2007) took these five success factors and analysed in greater detail which are as given below:

This is a preview of the whole essay

Top-Management Commitment
Project Team Commitment
Effective Project Management
Project Personnel Knowledge/ Skills
Enlisting of External Contractors

Fowler, Jeremy J. & Horan, Pat. (2007) then tried to match these success factors to the six risk factors that is associated with IS failure. They found that even though more research needed to be done in this respect, it was evident that the factors that are critical to the success of an IS are comparable to those referred in numerous journals as factors that are associated with IS failure. In short the study by Fowler, Jeremy J. & Horan, Pat. (2007) is significant considering the fact that the two main factors that led to the overall success of the implementation were the commitment from both top-management and project team which reconfirms Ewusi-Mensah and Przasnyski (1994) claim earlier on in this paper.

They also concluded that major IS success factors are closely related to the factors that most influence IS failure. Also of the five factors that contributed to the success of the IS, three directly relates to IS failure factors. Of the five factors project team commitment and enlisting of external contractors failed to show any relation to the previously discussed IS failure factors. But in one way they are not of relevance as they appear seldom in being a major influencing factor in IS success.

Hence overall we can conclude that overall Information System Critical Success Factors and Critical Failure Factors analysis might be complex in nature but almost all factors that govern the CFF are correlated with those that are associated with CSF.

Information Systems Failure Case Studies –

3.0.1 Case Study 1: Semiconductor Manufacturing - Thai Subsidiary (SMTL) –

Semiconductor Manufacturing Thailand Ltd. (SMTL) was set up as a manufacturing subsidiary of Semiconductor Manufacturing (SMHK). Semiconductor Manufacturing (SM) is a world leader in manufacturing of a wide range of electronic equipments and their expertise include design, development and delivery of products. The plant in Thailand was designed in such a way that it will house all the manufacturing process under one roof.

By 1997 the SMTL had grown to 1500 employees under the guidance of Jack Fung, Managing Director (MD) of SMTL. The top management in Semiconductor Manufacturing knew the huge potential for growth and invested heavily.

The Management Information Systems (MIS) department at SMTL was in charge of the whole IT infrastructure. But Jack Fung, took all major decisions of the IS planning and implementation. Jack wanted an IS very much similar to the one in use in SMHK and hence acquired IBM minicomputer AS/400 (B series) and selected modules of BMS (a UK-based business applications software package). A local VAR (value-added reseller), TGSystems was selected by him for the delivery of the software as well as in the training and implementation. But at the time of delivery what SMTL acquired from IBM was the D series IBM AS/400 as it had more capacity. Furthermore at the time of purchase of the BMS module, since a 50% discount was being offered Jack purchased every module of BMS, which was more than what was earlier planned to be implemented. The purchased modules included Financial, Distribution, Manufacturing and Information Human Resource Management (IHRM).

The implementation started with the Payroll and as agreed in the contract TGSystems, helped in the process of implementation and training. But few months into the implementation process SMTL found that the payroll system was complex and not flexible to their desired reports. Hence, Carol who was the senior most member of the MIS came up with the idea of implementing FoxPro for payroll management, which in the end was found to be more successful in terms of usability and functionality.

Also during the Financial and Distribution modules training sessions which were conducted by the TGSystems and EDP personnel from Hong Kong EDP, there was a significant amount of turnover of BMS experts from TGSystems. This led to many complaints from employees of SMTL and in turn accounted for turnover of employees toward the training sessions. The eventual result was the delaying of BMS module implementation by over a year. Since the functionality of each module depended on other modules, there was delay in implementation of dependent modules too.

Along the same time MIS on their part started to set up Local Area Network (LAN) in SMTL from fund received from management. This coupled with almost 50 % turnover of employees forced them to hire young programmers to develop and enhance critical IS in SMTL. But overall they were able to implement Inventory Management (IN) and by early 1996 General Ledger (GL), Cash Management (CM), and Accounts Payable (AP) were integrated. Also by the end of the same year the Purchasing Management (PM) module was implemented and was successfully integrated to Accounts Payable (AP) module. The communication facility like Lotus Notes was implemented in early 1996 with help from Hong Kong EDP.

Next the MIS staff of SMTL started the deployment of manufacturing modules of BMS, but it soon became clear that the module would not fit with the existing manufacturing business processes in SMTL. The options were, to purchase the source code and customise it, or to copy the same from SMHK. The former would cost huge amount of money and also MIS did not have the expertise to customise the code. The latter plan was also rejected as SMHK informed them that the existing manufacturing module was not performing as intended and that a lot of human resource was being used. Hence an in-house MRP software was developed as a temporary solution. Eventually the originally expected plans never materialised.

Failure Reasons – Looking back at the whole implementation process in SMTL it becomes evident that there was lots of factors that led to the failure of the implementation process. Some of the failure reasons as explained by Sarkar, Suprateek & Sarkar, Saonee (2000) are listed below.

Lack of leader ship and culture issues
Poor communication and coordination
Poor Human Resource management in dealing with employee issues
Inefficient IT Infrastructure to support the Information Systems

Overall the IS implementation failure in SMTL was mainly due to the management taking all decisions and not consulting with the IT team. Also the communication between the management and IT implementation team was also a cause. This along with the improper planning of the implementation added on to the cause of IS failure. Adding on to this was the cultural differences within the company.

3.0.2 Case Study 2: ElectroCo –

ElectroCo, an electronic component producing company was formed in the year 1991 in Singapore as a sister concern of its Japanese corporation. In 1998 the procurement department of the company started the implementation of electronic procurement system, called E-PRO. The objective of the implementation was to make the procurement process paperless and more effective, but in the end the whole process turned out to work against the company as their relationship with their relatively small supplier turned worse.

Even before the start of the implementation there was strong opposition from both IS manager and the users of the system. The former was because of the scale and complexity involved in the implementation and the latter was because the users were concerned about losing their job due to the automation. Most of all the suppliers in this case were not informed about the project. But the project went ahead because of the sole interest of the procurement manager as he had a strong backing from the managing director.

The project started in January 1999 with an initial budget of S$200000 and the duration for completion was for 1 year. As mentioned before due to the reservation of the users, the project had difficulties obtaining the procurement procedures from them and most of the information they got where of conflicting in nature. But the issue was solved by transferring a few employees and giving warning to the rest, which was clearly an unethical way.

It was only after five months into the development that the suppliers were informed about the implementation of the new system. The suppliers had concerns like:

Hidden costs, and
Low profit margin they got from ElectroCo was not enough to invest in new equipments.

But none were given an ear to by the procurement manager which eventually led to rumours among the suppliers that they will eventually be replaced by other competitors. Hence secret meetings were held among suppliers to make ElectroCo stop the implementation of E-PRO.

The only person who was sympathetic towards the suppliers concerns was the IS manager. Meanwhile the suppliers met the managing director and raised their concern. Even though, initially the project manager was sceptical about the new development but after meeting with the procurement manager and eventually after the IS manager speaking in favour of the suppliers, decided to abandon the project.

Failure Reasons – Some of the failure reasons pointed by Pan, Gary S.C. (2005) in his case study are as follows.

Inefficiency in identifying the stakeholder.
Improper coalition identification analysis to identify threat to the interest of the stake holders.
Huge gap between stakeholder’s expectations and project goal.
Conflict of roles among the stakeholders which deteriorated the existing relationship between personals involved in the project.

In the above case the failure reasons are the improper identification of the stakeholders and lack of interest in the top management to address their concerns at the correct time. Also the lack of interaction of the procurement manager and the IS manager aggravated the problems which ultimately pushed the company to abandon of the project.

3.0.3 Case Study 3: SafeCo –

Safeco (founded in 1923 as General Insurance Company of America) is one of the largest diversified financial corporations in the United States, engaging in life and health insurance, real estate management and investment, commercial credit, surety and asset management, with property and casualty insurance as being its largest operations.

The case study below discusses the redesign of a fundamental business process (Personal Lines Insurance) at Safeco Corporation. The Information Systems and Services (ISS) department was given the charge of the implementation since they spear head the Personal Lines Systems (PLS) that support the business. The PLS provided information technology (IT) support for the Personal Lines Insurance business.

The reasons why Safeco decided to re-engineer the PLS was due to:

increased competition in the core business.
increased IT cost coupled with no substantial return on investment.
implement an enterprise-wide information sharing arrangement.

Thereby able to:

better service customer’s needs.
reduce the cycle time for rate change.
create an atmosphere of confidence for further projects to be implemented.

The PLS redesign started in 1995, with representation from the key partners (customers) involved, leadership positions, PLS analysts, and PLS experts forming the steering team. The steering team was in charge of:

Providing clear focus and direction to BPR implementation.
Making Business Process Reengineering (BPR) happen by facilitating and charting of the process improvement teams (PIT)
Being the coordinator and counsellor to PIT.
Analysing the PIT performance and redirecting their activities when necessary.
Identifying obstacles to the success of BPR.

In short the PIT was to do the implementation and the steering committee was to facilitate them. But the owner ship of the implementation, which the steering committee believed lied with the PIT.

In their analysis of the case, Paper, David. (1999) divided the project into five sections and then analysed each section with what was the objective of each, the expectation and the desired change. Each of these sections is discussed below.

Automation Strategy – With the automation process the company tried to

provide consistent input/ output forms to all agents.
make it easier to change quickly with market condition.
project a “One Company” image.
work effectively with new products, and
create ownership.

But the whole initiative failed since there was no cross functional support for the project. The management was also reluctant to overcome this roadblock.

BPR Methodology – The redesign methodology involved investigation, redesign and implementation. After which the PIT was entrusted to implement the best solution after prototyping but the PIT was not too well versed with the redesigning and neither was any effort made in that direction. Also PIT had to depend on the BPR material in the SafeCo library for enhancing the knowledge skill. Hence the PIT was incapable of handle the project alone.
Process Management and Support – The steering team and the vice president took the major decisions and was then pushed done to the PIT level. PIT was entrusted with the ultimate success of the project and hence needed to analyse and meet the target. Hence we find that the company structure is not flat. This kind of organisational setup put heavy burned on the BPR projects since the management was not involved directly to overcome any issues related to cross functional changes.
PIT – Even though the PIT was in charge of the whole project and was responsible for its success. But the management approved all changes only once they were convinced that the change was for the better and that their position was not compromised in the company. This issue was not addressed since the management did not directly involve with the project.
IT – SafeCo understood the importance of IT as an enabler of change. But since the BPR process was handled by the ISS and since there was very little active support from this top management it became difficult to remove cross-functional issues when implementing BPR projects.

Failure Reasons – This case study looks at internal organisational factors that influence the success or failure of IS projects. The main factors in the above case that led to the failure are the organisational structure and lack of involvement in the project by the top management which could have cleared the issues relating to cross functional changes and thereby creating a much easier way for the implementation team. Also the issues that the PIT faced were not communicated effectively to the top management. The PLS project has since ceased to exist and is concentrating on other projects.

4.0 Analysis of Case Studies –

4.0.1 Causes of Information Systems Failure –

Even though the intended objective of each of the IS implementation were different for each company we find similar pattern emerging in terms of the factors that led to the ultimate abandonment or failure of the Information Systems implementation.

Some of the notable reasons for failure from the above three cases are –

Lack of Leadership –

Case 1: SMTL - Jack had the necessary knowledge and skill but the delegation of the job was not properly done.

Case 2: ElectroCo – The IT manager was sceptical about the project but never raised his concerns. He was more concerned about losing his job than let know of his concerns which later turned true.

Case 3: SafeCo – Even though the management knew the importance of the implementation but took no responsibility of the project assuming that the PIT was the sole owner of the project.

Inadequate Project Planning –

Case 1: SMTL - Jack believed so much in his abilities that he single handily dealt with the project plan and IT procurement.

Case 2: ElectroCo – The Project was planned without discussing the stakeholders involved, which later turned out to be the main cause for the project to be abandoned.

Case 3: SafeCo – Even though there was a detailed analysis of the project, the management did not do much of a thought to the roadblock in the cross functional aspect.

Lack of Effective Communication –

Case 1: SMTL – The language used in communicating was in English, and while many of the employees were Thais they could not understand the point put forward by the management, nor were they able to express their views.

Case 2: ElectroCo – The communication gap existed because of the lack of importance given by the procurement manager towards informing the suppliers (major stake holders in this case) about the new initiatives from the company and how it can mutually benefit the business.

Case 3: SafeCo – Due to the laxity of the management in addressing cross departmental communication the ultimate goal of implementation across departments could not be achieved.

Poor Stake Holder Involvement –

Case 1: SMTL – Due to the ineffective communication and poor project planning large employee turnovers were reported which affected the project badly.

Case 2: ElectroCo – The management failed to understand that the suppliers were the main stakeholders and that they should be involved in the project throughout the implementation so as to acquire their confidence and the ultimate success of the project.

Case 3: SafeCo – Since the implementation was across the organisation the stakeholders were not cooperative to function beyond their departments to ensure the success of the project.

Lack of Project Knowledge or Skill –

Case 1: SMTL – The training given by the TGSystems staffs were insufficient to enhance employee skills. Even though the project was implemented with alternative solutions to an extent, the employee’s skills were insufficient to sustain the system.

Case 2: ElectroCo – The IS manager was concerned about the magnitude and the technical complexity of the project but never raised those issues.

Case 3: SafeCo – The employees were not trained properly. They had to depend on company library for enhancing their project knowledge.

Lack of Coordination between Management and IT Personnel –

Case 1: SMTL – The management took the decisions themselves regarding planning and procurement without consulting with IT manager.

Case 2: ElectroCo – The IT manager was cautious about the magnitude and complexity of the project but never raise them to the management fearing his position nor was the procurement manager concerned about discussing issues with the IT manager.

Case 3: SafeCo – The IT manager did not raise the issues arising due to the roadblocks in the cross functional aspect with the top management and hence had to face lot of barriers during the implementation phase.

Lack of Management Commitment –

Case 1: SMTL – The issue was of over commitment of the management. The management took the decisions themselves and the jobs were not delegated effectively.

Case 2: ElectroCo – The management delegated the job to the procurement manager but was never involved in the project.

Case 3: SafeCo – The PIT was given the charge of the project but they could not handle the cross functional roadblock of the project. As the management was not so committed to the project these hurdles were not effectively managed at the first place.

Lessons Learnt from the Cases –

From the above discussed reasons for IS failure we can find quite a few key lessons which can help remove IS failures and ensure success in future. Some of them are discussed below.

Effective Leadership – Though all IS implementations are sanctioned from the management, the jobs must be delegated to appropriate IS managers or IT professional after consulting with the IS manager. Equally important is that authorised personnel should take responsibility for the job and work in an ethical manner.
Proper Project Planning – The project planning must be done thoroughly with active participation from all stake holders involved.
Effective Communication – Effective project management requires good communication skills (Avison & Fitzgerald, 2003). This includes effective two way communication between project manager and management.
Stake Holder Involvement – One of the key success factors of any IS implementation process is the involvement of the stakeholders. The stakeholder expectations must be met to ensure IS project success.
Project Knowledge or Skill – IS implementation require a lot of knowledge and skill on the part of the implementation team. They should be aware of the new technology as well as take into consideration the possible technical hurdles they might encounter during the implementation.
Effective Coordination between Management and IT Personnel – This is one of the most important factor that can make or break an IS implementation. IS implementation is a continuous process and many changes and alterations can happen along the way. Hence the IT manager should always be in continuous touch with the top management so as make the job of the IT team effective.
Management Commitment – The top management should be actively involved at each and every stage of the implementation so that the confidence and commitment of the project team during the implementation is kept high. Also any organisational hurdles in the implementation can be resolved at the first instance.

If all the above lessons were kept in mind during the IS implementation a majority of the failures could have been avoided.

5.0 Advice to Manager/IT Manager to Reduce IS Failure –

Along the paper we have seen a number of causes for the failure of IS and the implication it has had on the company. One at this point of time is forced to understand that IS failures will occur but a majority of these failures are avoidable. Organisations these days understand the need of Information systems in an organisation and the benefits associated with the implementation. But still a huge percentage of projects fail due to many reasons. Some of which have been discussed in detail in the paper.

Looking forward one finds quite clear that with very little difference between organisations and since each is looking for a competitive edge, and with organisations depending on growing amount of information, information systems play an important role in the future of any organisation. Hence managers and IT managers need to eliminate IS failures for nurturing and sustaining the business goals.

Given the influence that information systems have on the business edge, managers and IT managers must take into consideration quite a lot of factors before, during and after implementation of a IS project. One must understand the importance of planning the implementation since a lot of decisive decisions are made at this juncture. Planning should include requirement gathering, feasibility study, proper estimation and defining the scope clearly. The importance of planning lies in the fact that if any of the aspects are not taken into account seriously then any issue that might happen will surface only at a later part during the implementation by which time lot of efforts and capital would have been invested. Once the planning is completed the information has to be sent to all stake holders directly and indirectly involved with the project. The management should also play an active role during the implementation so as to overcome any organisational roadblocks. For this there should be effective communication between the management and the IT manager and both should take equal responsibility to maintain the communication.

Once the planning and communication is set up, the focus should then be on the management of the project. Project management should involve close monitoring on a periodic basis to identify any potential problems. The problems can be encountered in the form of deficiencies in knowledge or skills in the project personnel or organisational factors like organisational politics or departmental issues. These issues have to be addressed at the first place and for which the communication between the manager and IT manager plays the critical role. If not attended to then it can affect the confident the project personnel have on the project and delay the project to a considerable extent.

Since the business needs of organisation keeps on changing coupled with the changes in information technology, the managers and IT managers should not only have a long term goal but also taken into consideration the long and continuous process of information systems implementation. Failures can happen along the way but the important factor is learning the lessons from those failures and making sure that those mistakes are documented for future reference and are not repeated again.

6.0 Conclusion –

In this paper we discussed the concept of Information Systems (IS) failure as a whole. Also discussed were the various types of IS failures and the factors that differentiate an IS success from failure. The paper also dealt with the Critical Success Factors (CSF) and Critical Failure Factors (CFF) associated with IS failures and an attempt was also made to correlate critical success and failure factors. A detailed study of a particular case related to IS failures was also undertaken and an attempt was made to synthesis and analyse the failure reasons based on the case. The information gathered from the case was also looked into in detail. Then a detailed comparison of the CSF and CFF was done with regard to existing literatures in IS failures and the case. From the comparison of CSF and CFF we concluded that the analysis of CSF and CFF might be of complex nature but almost all factors that govern the CFF are correlated with those that are associated with CSF.

In the paper we also looked into three different cases involving IS failures and analysed the apparent reasons for IS failures and the vital lessons learnt from those failures. From the analysis we found that of all factors that contributed to IS failure three factors stand out among all. These are the commitment of the top management toward the project and the involvement of the project team and users involved in the project along with effective communication between the management and the project stake holders.

From the analysis of IS failures we can conclude that there are many factors that decide the ultimate fate of IS implementation but of all top management commitment, stake holder involvement and effective communication during the implementation are critical to the success of the IS project. This argument is also well supported by existing literatures on IS failures and as also sees in the cases analysed. Hence managers and IT managers should take into account these factors much more seriously along with the other factors to ensure that the information system implementation is a success. It is also advised in the paper to the managers and IT managers of any organisation, that IS failures can happen even after much analyses and effort but the important point is to learn the lessons from those failures and in making sure that those mistakes are not committed again.

Reference List –

[1] Al-Mashari, M., & Al-Mudimigh, A. (2003). ERP implementation: Lessons from a case study. Information Technology & People, 16(1), 21-33.

[2] Avison, D., & Fitzgerald, G. (2003). Information systems development: Methodologies, techniques and tools (3rd ed.). Berkshire: Mc-Graw-Hill.

[3] Baskerville, R., Pawlowski, S., & McLean, E. (2000). Enterprise resource planning and organizational knowledge: Patterns of convergence and divergence. In S. Ang, H. Krcmar, W. Orlikowski & P. Weill (Eds.), In Proceedings of the Twenty First International Conference on Information Systems, 396- 406. Atlanta, GA: Association for Information Systems.

[4] Benbasat I, I., Goldstein, D.K., Mead, M., (1987). The case research strategy in studies of information systems, MIS Quarterly, Sept.

[5] Beynon-Davies, Paul. (1999). Human error and information systems failure: The case of the London Ambulance Service computer-aided despatch system project. Interacting with Computers, 11, 699-720. ¶

[6] Chung, K.S., & Peterson, D.K. (2000,2001). Developers perceptions of information systems success factors. Journal of Computer Information Systems, 41(2), 29-35.

[7] Das, S. (1999, May 6). E-tag chaos hits toll way opening. The Age, p. 1-2.

[8] Doherty, N.F., & King, M. (2001). An investigation of the factors affecting the successful treatment of organizational issues in systems development projects. European Journal of Information Systems, 10(3), 147.

[9] Ewusi-Mensah, K., Przasnyski, Z.H. (1994). Factors contributing to the abandonment of information systems development projects, Journal of Information Technology, 9, 185–201.

[10] Fowler, Jeremy J. & Horan, Pat. (2007). Are information systems’ success and failure factors related?. Journal of Organizational and End User Computing, 19(2), April-June, pp. 1-22. ¶

[11] Harel, D., On fold theorems, CACM 23 (7) (1980) 379–389.

[12] Irani, Z., Sharif, A.M., & Love, P.E.D. (2001). Transforming failure into success through organizational learning: An analysis of a manufacturing information system. European Journal of Information Systems, 10, 55-66.

[13] Jiang, J.J., Klein, G., & Discenza, R. (2002). Pre-project partnering impact on an information system project, project team and project manager. European Journal of Information Systems, 11(2), 86-97.

[14] Koenig, M. (2003). Knowledge management, user education and librarianship. Library Review, 52(1-2), 10-17.

[15] Lucas, H.C (1975). Why Information Systems Fail, Columbia University Press, New York.

[16] Lyytinen, K., & Hirschheim, R. (1987). Information systems failures—a survey and classification of the empirical literature. In P. Zorkoczy (Ed.), Oxford surveys of information technology, 4, 257–309. Oxford: Oxford University Press.

[17] Lyytinen, K. (1988). The expectation failure concept and systems analysts view of information systems failures: results of an exploratory study, Information and Management, 14, 45–55.

[18] McGrath, K. (2002). The golden circle: A way of arguing and acting about technology in the London ambulance service. European Journal of Information Systems, 11(4), 17-26.

[19] Pan, Gary S.C. (2005). Information systems project abandonment: A stakeholder analysis. International Journal of Information Management, 25(2), pp. 173-184. ¶

[20] Paper, David. (1999). Reinventing business processes through automation: A case study. Annals of Cases on Information Technology Applications and Management in Organizations, 1, 97-107.

[21] Rockart, J.F., DeLong, D.W., (1988). Executive Support Systems The Emergence of Top Management Computer Use, Dow Jones-Irwin, Homewood, IL.

[22] Roberts, T.L., Leigh, W., & Purvis, R.L. (2000). Perceptions on stakeholder involvement in the implementation of system development methodologies. The Journal of Computer Information Systems, 10(1), 78-83.

[23] Sarkar, Suprateek & Sarkar, Saonee. (2000). Implementation failure of an integrated software package: A case study from the Far East. Annals of Cases on Information Technology Applications and Management in Organizations, Idea Group Publishing, 2, 169-186.

[24] Sauer, C., Why Information Systems Fail: A Case Study Approach, Alfred Waller, Henley-On-Thames, 1993.

[25] Standish Group (1999). Project resolution: The 5-year view. Retrieved November 30,2006,from http://www.standishgroup.com/sample_research/PDFpages/chaos1999.pdf.

[26] Wallace, L., Keil, M., & Rai, A. (2004). How software project risk affects project performance: An investigation of the dimensions of risk and an exploratory model. Decision Sciences, 35(2), 289-321.

| Page