لطفا منتظر باشید ...
Postabandonment Review Triangulation Process
In an earlier work I proposed a three-pronged strategy for investigating software development failures resulting in abandonment (Ewusi-Mensah 1991). The three approaches consist of survey questionnaires, structured open-ended interviews, and archival data. I believe that this is an appropriate way of dealing with the several dimensions of the software project abandonment issue in organizations. Every postabandonment review must be approached as a case study of the failed project. Thus the inquiry must strive to "minimize bias, maximize accuracy, and report impartially, believing that ‘inaccuracy and bias are unacceptable in any case study’" (Patton 2002, 93). The design strategy advocated is triangulation, which will enable the project investigators to take advantage of the strengths and minimize the deficiencies associated with each approach to data collection. The purpose of this triangulation approach is to make it possible for the inquiry to "test for consistency" of the information obtained in the study: "Different kinds of data may yield somewhat different results because different types of inquiry are sensitive to different real-world nuances" (Patton 2002, 248). This is particularly important with respect to software development because of its inherent abstraction and the levels of complexity that are encountered in the process of translating the organization's real-world information requirements into an implemented software artifact (Lehman 1989). The two parts to the triangulation strategy are as follows: Methodological triangulation (Denzin 1978; Patton 1987) will allow the investigators to use the methods of structured interviews, questionnaires, and documents to study and evaluate the abandoned software project. Data triangulation (Denzin 1978; Patton 1987) will enable the investigators to collect data from the different stakeholder groups on their perceptions and retrospective analysis of the development process for the abandoned project. Denzin (1978, 28) makes the plausible point that for this sort of evaluation research "no single method ever adequately solves the problem of rival causal factors. Because each method reveals different aspects of empirical reality, multiple methods of observation must be employed."I now discuss the details of how the two strategies (i.e., methodological and data triangulation) can be applied in practice to determine what happened with respect to the abandoned project, why it happened, and how it happened in an effort to prevent recurrence in future software projects.
Methodological Triangulation
This part of the triangulation strategy involves several approaches to data gathering.Questionnaire Like Collier, DeMarco, and Fearey (1996), I suggest that a survey questionnaire be designed and used in the investigation to collect data on the abandoned project. The questionnaire should be appropriately designed to reflect the type of project and its characteristics. It should be widely distributed to all the participants in the project team from all the stakeholder groups. The purpose of the questionnaire, especially in a very large project with large numbers of participants, is to enable the investigators to gather diverse opinions and perceptions from the different stakeholder groups and to aggregate them for statistical analysis in order to identify any general trends or broad patterns relating to the abandoned project. Over time, the historical record from such collections will enable the organization to assess its progress with respect to its performance in project development. However, it is important to note that the questionnaire is not intended to obtain in-depth information from individual project participants on any aspect of the abandoned project. That task is the focus of the structured-interview part of the data collection.Structured Interviews The structured, open-ended interviews will enable the investigators to get more qualitative in-depth information about the major events and issues surrounding the abandoned project. From the information thus gathered one may be able to surmise from the stakeholders' viewpoints which of the varied issues and events that transpired might have contributed to the project's termination. The data collection must therefore not be constrained by the predetermined categories of analysis that the questionnaire approach forces on the investigators (Patton 1987). More important, this strategy offers the investigators the only viable means of obtaining a wealth of data for this purpose. I especially agree with Lyytinen (1987, 37) that "IS problems are often confidential, and not easily disclosed as, for example, in questionnaires." My colleague and I have found this to be the case in our own work (Ewusi-Mensah 1997; Ewusi-Mensah and Przasnyski 1995). I therefore believe this qualitative approach will give free reign to the stakeholders to open up to a "neutral" person, preferably from outside the organization, or at least outside the project team, and reveal some of the frustrations as well as the excitement experienced in the course of the project development.Archival Data Although the previous two approaches will provide the investigators with satisfactory data, the need to corroborate the results should lead the investigators to pursue this third approach. In today's business environment, voluminous records are almost always kept of all major undertakings, including software development projects. Moreover, people's memories fade over time, and hence archival data will be extremely useful in helping the investigators reconstruct the facts of the project's development. All documentary evidence generated in the course of the project from its inception to its cancellation such as memorandums, project notes, minutes of project meetings, and any other records and documents providing basic information on the project must be requested and examined for their relevance. The wealth of information that can be gleaned from an analysis of such project records and documents has been shown to be invaluable in getting to the "hidden" agenda that may be at the root of some of the failed development projects in organizations (Markus 1983).The three approaches to data gathering advocated here will offer the investigators a unique opportunity to collect a wealth of data of both a quantitative and a qualitative nature. The broad and diverse data generated by the quantitative method as well as data of sufficient depth and detail available through the qualitative method will give insights into the underlying "causes" or factors at play in the software development process environment with respect to the abandoned project. These two types of data can be richly supplemented by following the trail of documents generated in the course of the project in question.
Data Triangulation (Stakeholder Groups)
chapter 7 illustrated. However, user involvement results in a significant reduction in risk of abandonment for some projects (Ewusi-Mensah 1998). What the investigators must diligently try to determine is whether the lack of active user involvement contributed to the demise of the project. The investigators must learn from this stakeholder group the level of involvement they were encouraged to have in the development process. For instance, were their views actively solicited on issues of potential interest to them at critical stages of the development, or were they simply informed of decisions after the fact without prior consultation? What role did they play in the abandonment decision, or was the decision made without their input? This stakeholder group should offer the investigators a unique chance to "prove" a negative corollary to the standard prescription that user involvement is essential to the success of software development, because the investigators can compare the level of participation of users in different abandoned projects in the organization over time (De Young 1996).The data collection from the three stakeholder groups, using the methods described, will provide sufficient data to the investigators for subsequent analysis to determine the multiplicity of factors that may have contributed to the abandoned project. Later we will see how the results of the analysis can be used to influence software development practices in the organization.
