Software Development Failures [Electronic resources] : Anatomy of Abandoned Projects نسخه متنی

chapters 4 through 6. The results discussed here are broadly adapted from the responses of fifty-seven senior IS executives (labeled top computer executives or TCEs) and twenty-five systems managers (labeled SYS) who reported abandoned software projects in their organizations. Interested readers should consult Ewusi-Mensah and Przasnyski 1995 for further details of the study. The central issues raised in the study are "whether organizations keep records of abandoned IS projects and what, if anything, do they do with those records" (p. 5). The results discussed here, as in the article, are based on the TCE group, whenever necessary contrasted with the responses from the systems managers group. I only report the results of the study in this section. I defer the drawing of inferences from the results to the next section.

As table 8.1 shows, approximately half of the TCE respondents indicated that "sometimes" the organizations undertake a formal postmortem appraisal to ascertain the reasons for project abandonment, while one-third indicated that no such analysis was undertaken. Another 19 percent of the TCE respondents indicated that "formal post-mortems were ‘usually’ carried out with respect to the abandoned projects." The responses from the systems group were fairly similar. But as table 8.2 reveals, almost half of the TCE respondents indicated that the circumstances of project abandonment were never documented for future reference anywhere in the organization, with approximately 40 percent of the systems managers expressing similar views.

Table 8.3 shows that more than 60 percent of the TCEs and approximately two-thirds of the systems managers indicated that more than one project had been abandoned "for more or less the same reasons" in their organizations. Table 8.4 provides a detailed breakdown of the number of projects abandoned "for more or less the same reasons." According to the detailed breakdown of the data, 45 percent of the TCE group reported that three to five projects were abandoned for the same reasons. An additional 20 percent indicated that six to ten projects in their organizations were abandoned for essentially the same reasons. Only a quarter of the TCEs reported that one to two projects were abandoned for the same reasons. More than 60 percent of the systems managers group said that three to five projects were abandoned for the same reasons. But slightly over a quarter reported only one to two projects, and about 10 percent reported six to ten projects, being abandoned for similar reasons. Finally, when the issue of record keeping of abandoned projects is raised, just over a quarter of the TCEs indicated that records of these projects were kept, while more than 70 percent stated that no records were maintained. The figures from the systems managers are comparable, as summarized in table 8.5.

In the rest of the questionnaire, respondents were asked what the abandoned-project records were used for and what lessons, if any, the organizations derived from examining those records. This part of the analysis is based only on data from the respondents who indicated that records of abandoned projects were kept in their organizations. As table 8.6 shows, the TCEs indicated that all the IS management have access to those records, together with 80 percent of the systems developers, 50 percent of both senior management and new-project leaders, and 40 percent of management in other departments as well as of programmers. The responses from the systems managers group show that 75 percent of systems developers and new-project leaders, but only 50 percent of IS managers, have access to the records of the abandoned projects in their organizations. Only 25 percent of senior management and 25 percent of management in other departments have access to the abandoned projects' records.

Table 8.7 indicates that 80 percent and 70 percent of the IS managers and systems developers respectively "actually consult" the abandoned-project records, according to the TCE respondents. But only 30 percent of new-project leaders and 10 percent of senior management, management in other departments, and programmers actually consult those records. The systems managers group indicated that about two-thirds of IS management, systems developers, and new-project leaders—compared with only a third of senior management—consult the abandoned-project records. Table 8.8 deals with the length of time abandoned-project records were kept, with more than 40 percent of the TCE respondents indicating a maximum of more than six years and one-third of the respondents indicating a minimum of about two years. The systems managers group indicated that 25 percent of records were kept in some cases for more than six years, and in others for two, four, and five years, respectively.

When the organizations were asked why those abandoned-project records were kept, about one-third of the TCEs indicated the records were "usually" utilized to minimize the chances of repeating problems that led to the project's abandonment, with the remaining two-thirds indicating that "sometimes" the records were used for the purpose just stated (see table 8.9). The breakdown of the data from the systems managers group regarding whether the abandoned projects are used to minimize repetition of the problems leading to the projects' abandonment, as summarized in table 8.9, is as follows: 50 percent "usually," 25 percent "sometimes," and the remaining 25 percent "never." In contrast, table 8.10 summarizes the responses dealing with use of the abandoned-project records to plan and manage new projects better and to ensure their successful completion. Only one-third of the TCEs said that the records were "usually" employed for that purpose, with the remaining two-thirds indicating that this was "sometimes" the case. The figures show a proactive use of the information derived from the abandoned projects to improve the planning and management of subsequent projects, as confirmed also by the responses from the systems managers group. However, a quarter of the latter group indicated that the records were "never" used to better plan or manage new projects.

The next two tables, 8.11 and 8.12, focus on whether the abandoned-project records were judged "beneficial in establishing management procedure for new projects" and on what the respondents thought these records contributed to the eventual success of new projects. As table 8.11 shows, the TCE group indicated that about one-third of the abandoned-project records were "usually" beneficial in managing new projects, and the remaining two-thirds felt that this was "sometimes" the case. About half of the systems managers group felt the records were "sometimes" beneficial and another quarter found the records "usually" beneficial, with the remaining one-quarter stating that the records were "never" beneficial. Table 8.12 indicates that the overwhelming majority (nearly 90%) of the TCEs felt the abandoned-project records were "somewhat beneficial" in contributing to the successful completion of new projects. Half of the systems managers group considered the abandoned-project records "somewhat beneficial" and another 25 percent found them "highly beneficial." However, another 25 percent indicated the records were "not beneficial."

Finally, box 8.1 summarizes the respondents' own descriptions of how abandoned-project records are used in their organizations. Analysis of the responses shows the records are used for the following four main reasons:

To avoid future repetition of errors

For learning purposes and as an aid in planning new projects

To improve performance on future projects

For historical review and analysis of what went wrong

In the next section we consider the implications of these findings and their relevance to the crisis in software project developments.

Discussion of Survey Results

What do organizations collectively learn about the causes and circumstances of project failures? How is such information obtained and communicated in the organization? In the preceding paragraphs we have presented data based on the perceptions of a number of top computer executives and systems managers in Fortune 500 companies. A review of the data suggests that although most respondents indicated that postmortems are undertaken in their organizations to understand what went wrong and why (see table 8.1), a disturbing half of all the TCE respondents indicated that the circumstances of the abandoned projects are "never" documented (see table 8.2). It is therefore not surprising that more than 60 percent of the same respondents indicated that more than one project has been abandoned for more or less the same reasons (see tables 8.3 and 8.4). Even more disturbing is the fact that more than 70 percent of the TCEs said their organizations do not keep records of abandoned projects (see table 8.5).

Respondent's statements of how abandoned projects records are used in organization or IS Department^[*]

Records make it possible to review what was done previously.

Documentation accumulated during project development life is retained for possible future use.

Records help prevent future failed projects.

Records are used to compare with new project requests to see if some research can be used; they are used in statistical reports to management to justify management involvement in systems planning.

They are utilized for historical reference only.

Records can be helpful as part of the software development life-cycle process. They are used as lessons learned to improve the process and as baseline measurements (function points) to give indicators on current projects.

Abandoned = project records are filed with other project records; they are looked at if there is a possibility of reopening the original project or a related project.

If a user group that has had a project abandoned requests a new project, the abandoned project's postmortem is reviewed in IS and then discussed with the user group.

Records provide information on projects and end users that were unsuccessful and why; they are used as a test for starting new projects.

Project records usually contain detailed descriptions of current business functions, requirements, and aspects of the organization. Subsequent maintenance, enhancement, or even partial new development projects could save time and money by using the past work.

The picture that emerges from the data is one of organizations "cursed to repeat past mistakes" because no effort is made to understand what went wrong or to learn from the past mistakes. The failure of organizations to document their project failures and to use that information to avoid a repetition of similar problems, perhaps more than any other single fact, attests to the continuing problem of project abandonment in organizations. As Hedberg (1981, 3) points out, "Organizations increase their understanding of reality [e.g., of software development projects] by observing the results of their acts," and these are often experimental. When such organizational learning is lacking, the result is a dearth of viable formal mechanisms for "detection and correction of errors" and a failure to engage in "repeated testing, construction and reconstruction of knowledge" in those organizations (Hedberg 1981, 7). It is therefore not surprising, as Lyytinen (1987, 9) claims, that "IS development is fraught with recurrent problems caused by poor, undisciplined and incomplete development practices."

In short, organizations that operate under such circumstances are, indeed, more likely to repeat past mistakes, especially as members come and go and leadership changes take place. There will be no organizational memory to warn against the behaviors, procedures, operating practices, and standards that may be at the root of the project failures. Thus the likelihood of repeating the same problems looms large, especially if new personnel are assigned to new projects. The data clearly support Boddie's (1987, 77) assertion that "we talk about software engineering but reject one of the most basic engineering practices: identifying and learning from our mistakes." As a result, it is not surprising that "errors made while building one system appear in the next one." The failure to keep records on the abandoned projects robs the organization and its future leadership of an opportunity to learn about the mistakes of the past, thus creating organizational memory loss for the long term. It is apparent that in most of these organizations, management treats project failures as "embarrassing moments to be quickly forgotten," not as opportunities for a concerted effort to uncover the causes of the failure, nor as opportunities to acquire new knowledge and discard obsolete information or practices (Boddle 1987, 82; Abdel-Hamid and Madnick 1990; Hedberg 1981).

For the respondents who indicated that records of abandoned projects are kept by their organizations, the picture that emerges is neither encouraging nor hopeful for the future of software project development practices. For example, even though table 8.6 indicates that quite a wide range of individuals have access to the abandoned-project records, only the systems developers and IS management generally consult those records (see table 8.7). New-project leaders (only 30%), senior management, management in other departments, and programmers (10% each) do not make as much use of the records as might be expected (based on the TCEs' responses). Thus, although the records are kept in some instances for as long as six years or more, little use is made of them (see table 8.8).

As pointed out earlier, the data also indicate that organizations experienced project abandonment for more or less the same reasons (see tables 8.3 and 8.4). Therefore, in an effort to avoid these pitfalls, some organizations took the prudent step of evaluating the abandoned projects. They probably undertook the evaluations primarily to ensure that the underlying factors or reasons for the abandonment of the projects were clearly understood and communicated with project developers. The results also suggest that some organizations chose to evaluate their abandoned projects to account fully for the expenditure of resources on the project, and to learn from the variety of interacting factors. For example, factors such as a lack of well-defined project goals, poor project-team composition, inadequate technical infrastructure, a shortage of technical know-how on the part of the project team, poor project management and control, a lack of end-user participation, and inadequate senior management support have the potential to negatively affect the project's outcome if they are not properly understood and dealt with in the project development process.

When the respondents were asked to indicate the benefits derived from the stored records, the majority of both TCEs and systems managers cited the potential to avoid repeating past problems or errors and improve performance on future projects through better planning and management (see tables 8.9 through 8.11). While these objectives are commendable, they are unlikely to be realized if a majority of the responding organizations do not routinely keep project records, much less consult them on a regular basis (see table 8.5). This singular "failure to learn from mistakes has been a major obstacle to improving software project management," as Abdel-Hamid and Madnick (1990, 39) charge. We are, therefore, doomed to "continue to produce too many project failures, marked by cost overruns, late deliveries, poor reliability and user dissatisfaction" (Abdel-Hamid and Madnick 1990, 39).

In contrast, respondents who indicated using the abandoned-project records overwhelmingly expressed the view that the records were beneficial in establishing management procedures in new projects as well as contributing to the success of the new projects (see tables 8.11 and 8.12). The problem of software project failure is therefore presumably not an intractable technical issue but rather one of failure on the part of both senior management and software/IS management to institute enforceable guidelines and procedures for undertaking postmortems of failed or abandoned projects and making proper use of the lessons learned from those experiences in subsequent projects.

^[*]Statements lightly edited