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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Kweku Ewusi-Mensah

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Conclusion

In the preceding pages we have analyzed the failure of a software development project—CODIS—from the perspectives of the users who were an integral part of the development process. The case-study analysis produced a set of hypotheses outlining the factors that may have contributed to the failure of the project. We have presented a stakeholder-interaction model stressing the need for communication among the three groups involved in the software project development in order to minimize the chances of minor problems evolving into bigger ones and thus threatening the viability of the project. The case also adds to the evidence discussed in the preceding chapters showing that software project failures are often the consequence of the failure of several interacting multidimensional factors, the most common of which are managerial and organizational.

The evidence generated from interviewing the four users has been organized in the form of contributing factors in an effort to understand, from the users' perspectives, the main issues that played a role in the decision to cancel or "suspend" the project. There are several lessons to be derived from this case study in spite of the prevailing "code of silence" among companies that have experienced abandoned projects. However, the limitations of the study should caution against broader generalizations of the results than is warranted by the facts of the project development environment. First, the lessons are based on the views of only four users associated with the project, though they were active participants in the process from the very beginning. Second, the users' views may have been colored by the passage of time and/or by their unanimous feelings of frustration and dismay about the whole experience. Third, the timing of the data collection, coming in the midst of a currently successful, and even more comprehensive, system being developed by a new set of IS staff with a new vice president of MIS, may have had a potentially negative influence on their perceptions of the previous IS staff's performance. Be that as it may, the lessons from the case appear worthy of further discussion.

Taking the particular circumstances and conditions of the company into consideration, a significant number of the factors discussed in this chapter may be at the root of most abandoned IS development projects. Despite the industry-accepted fact that a large number of development projects are often over budget and/or behind schedule, not all abandoned projects fall in to this category (see Ewusi-Mensah and Przasnyski 1991). The project was not abandoned for lack of resources and financing, even though it was getting further and further behind schedule. User involvement, which is widely regarded as crucial to successful systems development, may be necessary but is not a sufficient criterion for systems completion or implementation success. The data suggest that the project failed largely due to the lack of technical competence of the technical members of the team and due to the failure of senior management to actively monitor and manage the progress of the development team. Project success thus undoubtedly depends on the full participation of all three stakeholder groups, and anything less from any one of them may have potentially damaging effects on the project's outcome. Their joint effort should significantly contribute to two-way learning among all three groups—users, IS staff, and senior management—in order to minimize potential misunderstandings, conflicts, and the politics of the process. At all costs, the garbage-can approach to new-systems development should be resisted. There is, therefore, an unequivocal need to separate systems maintenance activities from new-systems development efforts. This distinction should particularly be insisted on when the technical competence, experience, and/or expertise of the IS staff are suspect. The use of a formal systems development methodology should be fundamental to the development of any particularly complex project. The clear management guidelines of such a methodology make it easy to monitor progress and uncover problems at various stages of the systems development process. This should prove quite beneficial, especially in inexperienced development environments.

We have shown through the views of the users that user involvement in IS development projects is a necessary but not a sufficient criterion for project development success and that there is still a significant risk of project failure if there is not equally active involvement from the IS staff and from senior management. For successful IS project development, the involvement of the users must be assured, the IS staff must be competent and committed to the project, and senior management must actively participate in the project as an equal component of the development team. Communication between the users group and the IS staff—often taken for granted—is extremely critical to successful development. In addition, collaboration among the stakeholders, in particular between the users and the IS groups, must be standard practice in all development environments if project success is to be achieved. Coordination within and between the users and IS groups is recognized as one of the critical facets of successful systems development. Software development is quintessentially a collaborative process. However, the collaboration is often erroneously perceived as only being required among the development staff. Collaboration that fails to involve all the interested stakeholders, in particular the users, only creates an environment in which minor issues can fester and contribute to project failure. Thus project development success is the joint responsibility of all three stakeholder groups. The process of IS project development may therefore be compared to the three legs of a tripod: a shortening of one or more legs will affect the stability of the entire tripod and may cause it to collagse. In a similar way, lack of full participation by any one of the three stakeholder groups in the systems development process may contribute to the eventual failure of the project.

/ 92