The aim of the Failures Method is to investigate some identified failure to learn what aspects of the situation may have led to the failure occurring. The investigation consists of comparing “ideal” models against the real-life failure situation. This comparison is expected to reveal discrepancies between the two, highlighting areas of concern. These discrepancies can then be interpreted in relation to the failure situation and conclusions can be drawn. (West, 1998) Investigating whether failures can be avoided, or reduced by some degree, is certainly a worthwhile effort. Studies suggest that most IS project disasters are avoidable (Heerkens, 2002). Many times, warning signals occur long before an information systems project has begun to fail. History has shown that software projects are far more likely to be successful if they are highly focused and built upon well-understood technology (Heerkens, 2002). There are many writers who tell us why projects fail. For instance, (Field, 1997) tells us that “projects fail too often because the project scope was not fully appreciated and/or user needs not fully understood.” (Hulme, 1997) tells us that “MIS projects and associated procurements take place in an environment characterized by the following: Lack of management continuity and an incentive system that encourages overly optimistic estimates of the benefits that can be attained from doing the project.” And (Leicht, 1999) tells us that high user expectations can actually be the cause of project failure. (Hoffman, 2003) tells that projects fail because of poor alignment between IT departments and business users. Project managers too often act as “process cops and report compilers and loose sight of what they're supposed to be doing - to make sure projects are running effectively”. Hodgson (2002). Tells us “projects fail - that's the fact of life. Too many fail because the average project is like an iceberg - 9/10ths of it lay hidden from view”. All of these writers are correct. However, none of these authors are reporting systematic research of the mechanisms that cause project success or failure. In addition, none of them provides insight into the rate of project failures. According to an article in the Journal of Systems and Software (Lingberg, 1999), struggle and challenge are part of the learning process. Failure of ISDP (Information system development project) is not breaking news today, however the study of these projects reveals new factors for analysis. Historically IS projects have been characterized by high failure rate. A recent report collected results of five different surveys from different years, i.e., 2001, 1997 & 1995 and concluded that:
An IT project is more likely to be unsuccessful than successful About 1 out of 5 IT projects is likely to bring full satisfaction The larger the project the more likely the failure
40 % of the projects failed to achieve their business case within one year of going live According to Heeks (1999) conducted an investigation of e-government projects in developing countries. The results of his survey show an extremely disappointing position: 35% projects are total failures, 50% projects are partial failures, 15% projects are successes The IS failure in developing countries poses more importance for learning and investigation of failure causes, as it not only wastes the allocated resources but also discourages further investment. The opportunity costs are certainly high in developing countries because of the more limited availability of resources such as capital and skilled work force. “The failures keep developing countries on the wrong side of the digital divide, turning ICTs into a technology of global inequality” (Richard, 2002). For these types of reasons, a failure in development of IS in developing country poses a significantly important area of study. It is evident from literature that a substantial portion of total IS...