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

The CODIS Study

The study describes the history of the IS development project, from the perspective of the users. I will refer to this project as CODIS (not its real acronym, as noted earlier). The case focused on the users group that played such a pivotal role in the development process, tracing the evolution of the project from its inception in the requirements stage to the time at which the decision was made to cancel it. The study was based on interviews with four users who were part of the original project team. Five thematic topics—project goals, project-team composition, project management and control, project financing, and project cancellation decision—formed a basis for examining the views and perceptions of the users group in the systems development process. Successful systems development projects, in general, are able to reach consensus on project goals or objectives, have knowledgeable project leaders capable of molding the project team and setting achievable targets and strategies for attaining them, have satisfactory management and control of the project development process, and, finally, have active senior management involvement in the work of the team to convey both interest and commitment to a successful outcome of the project. What follows is the story of the CODIS development as told from the perspectives of the users group, without all the technical details typically provided by software professionals. The responses are based on interview notes the users reviewed, commented on, and edited for accuracy.

Project Goals

It is generally accepted that an IS must satisfy the specific information needs of the organization for which it is intended. Davis and Olson (1985, 6), for example, define an IS as "an integrated system designed to provide information in support of the operations, management and decision-making functions in an organization." Thus it is reasonable to expect a new IS project to have a set of well-articulated goals and objectives that the IS is intended to satisfy.

The data suggest that although there was general agreement in the organization on the need for a new IS, there was no clear enunciation of what the new system's goals and objectives were to be in order to address the specific information requirements the company had. This is a sample of what some users interviewed had to say on the subject of project goals:

VPM There were no firm established goals and moreover no real consensus on what those goals should be. They [i.e., the group] had real conflicting agendas. If a consensus existed it was "the realization that the company was functioning with brute force—good people working very hard with little computing or information technology support."

VPSP There was no established consensus on the project goals. People had divergent views of what the project needed.

DCA The goal was to provide "a paperless order entry sales and customer service support system for the company." The goal was partly based on the need to improve the efficiency and the productivity of the business operations brought about by growth in the company's business volume.

MD In essence, there were no established goals for the project besides the fact that senior management asked them [i.e., the users] as a group to come up with the design of a new system to replace the old [i.e., current] system. The employees constantly complained to senior management about the old system's deficiencies in helping them do their job well.

There is a general consensus, as can be surmised from the above responses, that the project had rather vague goals and lacked clear objectives as to the specific information requirements the new IS was expected to satisfy. The sense of frustration and exasperation the group felt was succinctly expressed by MD, who later commented that the group had the impression "they were being set up to fail" so they would quit complaining about the deficiencies of the old system. Analysis of the above responses leads us to the following contributing factor:

Factor G Lack of consensus on the specifics of a new IS—that is, on its goals and objectives—is likely to have contributed to a vague set of systems requirements (which may lead to problems in later stages of systems development).

Project-Team Composition

The development of any IS project is the work of a team of individuals drawn from the following three stakeholder groups: the senior management, who are expected to provide the leadership, support, and resources needed to carry out the task; the user groups, which are expected to provide the operational and decision-making perspectives of the system to be developed; and the IS staff, who must handle the technical aspects of the task from requirements analysis and specification to design and implementation. Thus, the composition of the team is a crucial step in the process of new-systems development. Equally essential in the effort is a leader responsible for organizing and directing the activities of the team.

The absence of a project team leader definitely compounded the problem of a lack of specific project goals to create a disorganized and dysfunctional project environment. The "conflicting agendas" and the "divergent views" pointed to by VPM and VPSP, respectively, attest to the fact that there was no common identifiable organizational purpose to guide the deliberations of the team. Consequently, the team meetings became nothing more than regular office meetings. This is what users said on the question of project team leader:

VPM George [i.e., senior VP of marketing] was "the leader" of the group, but since he did not stay involved, in essence "the team had no captain." What usually happened was that "the team would meet and discuss a few things and try to come to some decision. No structure existed for the organization of the project." The composition of the team remained relatively stable for some time.

VPSP Pete [i.e., the VP of MIS] was not very much involved with the project; he did not attend any of the meetings. Pete was later replaced on the team by Mike, who joined the company as director of MIS. The team remained relatively stable through the duration of the project.

DCA The VP of MIS was the one in charge of the project; the last VP was Mike. However, there were about two or three changes in the VP position. The last manager [i.e., Mike] stayed with the project until it was canceled.

MD There was no official leader of the group; perhaps Pete was supposed to be the team leader but he never really participated much in the work of the group after the first meeting. They [i.e., the users] all acted as surrogate leaders. There were no turnovers on the team.

Adding to the problem of lack of leadership was the fact that there was also a dearth of structure and organizational purpose to the team's efforts. The lack of formal documentation of the minutes of the meeting confirms the view that the formal requirements of information gathering in determining the systems requirements were not seriously observed. In essence, there was no sense of direction or purpose to the discussions on what the new systems requirements ought to be at the meetings. The stability of the team, coupled with the fact that it was mostly a marketing group (for example, as MD commented, "they had worked together for quite sometime and felt comfortable in relating to each other on that basis"), should have helped in making some progress in the requirements phase of the project. However, the lack of project team leader may be partly responsible for the lack of visible progress made on the project. The following contributing factor seems appropriate, based on analysis of the above data:

Factor T1 Lack of an active, official project leader, with responsibilities for the project's successful completion, is likely to have contributed to fragmented efforts and loss of direction or purpose on the part of the team.

The project was initiated and orchestrated by the marketing department, although it had implications for the entire company. The IS group was only superficially involved in a subordinate role as advisors or consultants without any real decision-making authority or responsibilities. The first VP of MIS did not help matters by failing to stay involved and offer the necessary technical leadership that a project of that magnitude needed. The lack of active senior management involvement, other than the professed support provided, was also a major contributor in that it created a somewhat erroneous impression on the part of some team members that setting up the team was an attempt to silence those within the organization who were criticizing the inadequacies of the current system. This is what the users said:

VPM "Marketing was really pushing the automation and MIS was expected to deliver the product." The MIS group existing in the company at the time was a lower-level organization and had no involvement with the team.

VPSP The team consisted mostly of people from marketing; there were no team members from accounting.

DCA Not quite sure how many of the IS staff were directly involved with the project. [He thought the number quite large but had no facts to substantiate his claim. It is worth pointing out that DCA was not part of the corporate staff during most of the time the project was in progress. Thus his perspective on some issues tends to reflect that of an outsider at the division level.]

MD The team was made up of six to seven people mostly from marketing, with one MIS person. There were, however, no persons on the project team from accounting, operations, or warehouse.

The peripheral involvement of the IS staff in the systems requirements phase is clearly a matter of concern. Although the users group had a sense of what their systems needs were, lack of formal participation on an equal basis and regularly by the IS group in the deliberations deprived the team of the benefits of the technical advice the IS group could offer to guide the discussions along a more fruitful and feasible path. Thus the role of the user in conceptualizing the system and as "an associate [together with the IS personnel] in the development of the requirements specification" (Sage and Palmer 1990, 89) was sacrificed or lost in the team arrangement set up to handle the project. This view is partly supported by the fact that there was general agreement among the users that the project lacked consensus on what its goals were for the organization. The data from the interview lead to the second contributing factor on project-team composition:

Factor T2 Lack of active interaction between the users group and the IS staff in the project development is likely to have contributed to communication and other problems in later phases of the systems development process.

Project Management and Control

The technical dimension of any IS development project demands that some structure be imposed on the development effort to help guide the system to successful completion. Several variants of the systems development life-cycle methodology are widely available and used in practice (see Boehm 1981; Modha, Gwinnett, and Bruce 1990; Olle et al. 1991; Sage and Palmer 1990; Pressman 1992). The most obvious advantage of using a phased life-cycle approach to new-systems development is to help the project team to realize what the deliverables for each stage are and to know whether they have been satisfied before proceeding to the next stage. The iterative nature of systems development notwithstanding, the phased sequential life-cycle approach has been instrumental in helping to manage and control the development of large complex systems successfully (Sage and Palmer 1990; Pressman 1992).

The users were interviewed for their perspectives on the development methodology used in the project and on how the project was managed, after being shown a sample of a systems development life-cycle model. Each of the users indicated on seeing an illustration of the systems development life-cycle model that no such formal guideline was provided by the IS group to guide or direct the development efforts. Their responses are summarized in the discussion below:

VPM The project "never moved beyond the level of what we wanted to do and could the computer do it." VPM explained this failure as due in part to the lack of planning on the part of both the company and the head of MIS. The situation unfortunately did not change when the head of MIS was replaced. VPM further explains that the project's surrogate leader, Bob, "did the best he could under the circumstances, given the lack of direction" from senior management.

VPSP All we had at the end of the two years was a "lot of paper documentation" to show for our efforts. Lots of equipment was purchased but nothing concrete was provided of the systems they requested during the meetings, just "a lot of paperwork." The MIS group always talked about the capabilities of the new system as having "the ability to do what [the users] wanted [it] to do."

MD "The team was able to generate different [computer] screens," which they felt they needed and would help them with their job. No tangible progress was made beyond that stage in terms of real systems design and implementation.

The views and experiences of the users reported above are supported by Sage and Palmer (1990, 50), who state that "the use of an appropriate life cycle model for software development is far better than development with no management organization or control at all." Saarinen (1990, 185), in a study of systems development methodology and its impact on project success, recommended that "the larger the project, the greater the need for formal planning and management control." The data on the CODIS project leaves no doubt that it was indeed a large and important project intended to support the operations, management, and decision-making functions of the company. The above narrative leads us to propose the following contributing factor:

Factor MC1 Lack of a formal systems development methodology to guide the new systems development effort is likely to have contributed to the project's failure to progress beyond the requirements phase, or to its treatment as just another systems maintenance problem.

Because no formal systems development life-cycle model was used to guide the project, it became apparent that either the developers were not aware of the need for such a systems development methodology or else they considered the new systems requirements as just another continued effort in the evolution of the current system. It was clear from the responses of all the users that what the IS department was engaged in was essentially continued maintenance of the current system. Here are some of their remarks:

VPM "From day one, the group [i.e., the users] sensed there was a problem. It was always as [they] started, nothing was getting accomplished." Nevertheless, they persisted in their efforts, partly due to the entrepreneurial spirit of the team members and to a desire to get something done.

VPSP The MIS group used a lot of technical jargon to impress the users about what they [i.e., the IS staff] were doing with the new system. The meetings were typically a rehash of things in the documentation that the users group had requested. There was a lot of going back and forth between the MIS group and the users on what the users wanted and what the MIS group felt could be accomplished system-wise. "The MIS group was working on the old [i.e., current] system and trying to improve on its functional capabilities instead of trying to develop a new system from scratch."

DCA There was no effort made, in general, by the IS personnel to discuss with the users how the users' requests could be addressed by the systems development efforts except for the occasional phone call. In retrospect, "the complexity of the whole problem was beyond the capability and expertise of the people who were involved with the project at that time."

The users' views expressed above were later confirmed by the new IS personnel hired to reactivate the project. For example, the current project director, in commenting on the remnants of the IS group associated with the abandoned project, said that "the major contributing factor was that most of the people hired to work on the project had no real prior experience [emphasis added] or knowledge of new systems development activities. Most of their experience had been with maintenance-related activities. There was a general lack of know-how on basic, indeed fundamental, activities like writing memos, taking minutes at meetings on user information requirements and providing formal guidelines on how new systems development activities should be conducted or carried out." The following contributing factor seems relevant:

Factor MC2 Lack of technical know-how in a new systems development effort is likely to have contributed to continued maintenance of the current system as a substitute for the new system.

Systems maintenance in the form of enhancements to an implemented system is generally accepted as a beneficial way for an organization to extend the life of a current system. Thus major expenditures on new systems development can be deferred to a later time. However, at some point in the life of an implemented system, continued maintenance in the form of further enhancements becomes counterproductive, in that the cost of systems breakdowns and its concomitant effects on the operations of the organization far outweigh any benefits expected to be gained from the postponement of the new system. This was a recurring theme echoed by all the users interviewed.

VPM "The frequent systems failures resulted in the computers being down sometimes for a whole day …"

VPSP During that time [i.e., of new systems development] there were a number of system downtimes experienced due to frequent attempts to add new features to the old [i.e., current] system. "The situation got to be so bad that changes to the system were eventually halted and Mike [i.e., the then-new director of MIS] was asked to ‘take the company back to the old system,’ so new features to the system were temporarily put on hold."

DCA "What they [i.e., the MIS group] were doing was causing severe impact on the business. It was crazy; the computer was a piece of junk; work was slow and it was not getting better but worse; and what they were doing had no direct relation to the functionality of the business." He later learned through the grapevine that the president of the company had demanded the IS group "take us back where we were and for them to get their act together." [Again, later in the interview, in discussing the decision to cancel the project, DCA further remarked that] the constant fixes to the system had made it so complex that "any change attempted had an unforeseen ripple effect on some other parts of the system; that was how messy and complex things had gotten in the old [i.e., current] system."

The third contributing factor is based on the above user experiences with the performance of the system and its impact on their work:

Factor MC3 Further enhancement of a system that had reached the maturation point is likely to have contributed to significant further deterioration of the system's performance.

In assessing the costs and benefits of systems development, if the cost of new systems development efforts is not accompanied by a comparable return on the investment that senior management believe is justified, their likely reaction is to carry out wholesale dismissals of those they consider the potential source of the problem—that is, the IS staff, including the head of the department, if necessary. Such a drastic move is especially likely under the following conditions: when senior executives are convinced of the importance of the new system to the future of the company (there is general consensus among all the interviewees on the importance of the CODIS project to the company); when all the financial resources needed to acquire the technology that the new system is expected to bring to the organization are made available (again, there is agreement that this was done in this case); or when senior management perceive—rightly or wrongly—that the lack of progress on the new systems development is the fault of the IS leadership and personnel.

VPM "From day one, [the group—i.e., the users] sensed there was a problem. It was always as [they] started, nothing was getting accomplished." Most of the MIS group were fired at the time because it was perceived in the company that they could not get the job done.

VPSP The project changed leadership when it was approximately halfway to completion. A new director of MIS (Mike) was brought in to replace Pete. But when it became obvious after some time that the new director also could not deliver the new system, he too was let go together with a number of the IS personnel he hired to work on the project. Problems on the project first came to VPSP's attention when some colleagues in the IS group began to discuss the low-morale problem in the department due to lack of progress on the project. The situation, he felt, got so bad that some of the IS staff individually expected they "would be set up to be the fall guy for the problems of the group."

The other users essentially expressed similar views. For example, DCA indicated that the problems on the project surfaced when he learned "everybody associated with the project had either been terminated or resigned." The inference can thus be made that no amount of political maneuverings or gamesmanship would be tolerated by senior management for failing to deliver a new system that they considered crucial to the company's survival. As VPSP remarked, "Mike was so consumed with his desire to become VP of MIS that his actions on the project were politically motivated to please top management. He was more interested in ‘creating an image in the boardroom’ on what a good job he was doing on the project than he was in getting anything of substance accomplished." The pattern of behavior observed by VPSP seems to fit the conflict and political models of Newman and Noble (1990) quite well with respect to the nature of the users' interaction with the IS group. The evidence provided by all the interviewees supports the following factor:

Factor MC4 Senior management's displeasure at the lack of tangible progress in a systems development considered crucial to the company is likely to have contributed to summary dismissals of most of the IS personnel associated with the project.

The failure of senior management to request and enforce regularly scheduled management review meetings to monitor progress on the project was a major issue raised by all the interviewees. The consequences of this failure were as follows: senior management had no way of knowing what stage in the systems development process the project was at any given time, much less when the project would be completed: the IS personnel failed to come up with a formal systems development methodology to guide the project to successful completion or at least to monitor its progress (see, for example, factor MC1); the new systems development project was treated essentially as another series of "fixes" to the current system to satisfy the identified needs of the organization; and far more organizational resources were expended on the project than could be justified before senior management realized the project could not be delivered as expected (e.g., VPSP—more equipment was purchased and "at least fifty new programmers were hired to work on the project").

VPM There was no planning developed for the project; no meetings were held to discuss technical issues on how to satisfy the computing needs; no management review meetings were held to discuss systems development efforts; and the project "never moved beyond the level of what we wanted to do and could the computer do it."

VPSP Although lots of equipment was purchased and new IS personnel were hired, still nothing concrete was provided of the systems requested. All this was going on in spite of the fact that Mike (director of MIS) met with the senior management team "almost daily on a regular basis to inform them on the progress of the project."

Unfortunately, senior management never realized what was going on until very late, when performance of the current system had deteriorated to the point where the only alternative left was to force closure on the project by demanding the IS group "take us back where we were and for them to get their act together," a comment DCA said was purported to have been made by the company president.

DM No formal reports were made to management or requested by them. Some senior management personnel occasionally dropped in on the meetings to inquire about their progress, but it was more on an ad hoc basis than in any formal or systematic manner.

DCA The project meetings were random and aperiodic with the "users groups (at the divisional level) being told little, if anything, about the goings-on of the project by the MIS people." The project management, especially when Pete was in charge, was "very directorial." There was virtually no communication or interaction with the users groups; "everything had to be done Pete's way and if Pete disapproved then it could not be done."

This virtual lack of communication or interaction between the users group and senior management helped to conceal the problems experienced by the IS group from the rest of the company. There were problems that an individual like VPSP only became aware of later when he became "friendly" with some of the IS people on the team. It is indeed desirable for senior management to be supportive toward a project and to provide the resources needed to carry it out. However, if senior management fail to become actively involved in monitoring progress on the project or otherwise to inform themselves of what is going on with the project on a regular basis, it is likely that small unresolved problems may become magnified over time. This may eventually contribute to the project's termination (Brooks [1975] 1995). As observed by one of the IS personnel holdovers on the project, "The scope of the project kept changing all the time; the team could never show management how and what progress was being made on the project at any point in time." The evidence summarized above from the users interviewed lends support to the following factor:

Factor MC5 Lack of active involvement by senior management in monitoring the progress of the project may have contributed to concealment of the problems experienced on the project by the IS personnel associated with it.

Project Financing

As noted earlier, it is common knowledge in the computer industry that projects are still over budget and behind schedule in far more cases than IS professionals and management find acceptable. Often projects seriously over budget and behind schedule end up being abandoned (Glaser 1984; McFarlan 1981; Brooks [1975] 1995). This made the financing of the abandoned projects a logical area of investigation. Admittedly, in most instances users may not be the right people to be questioned on this issue; however, the facts suggest that in this case they were fully informed about finances—in particular, because the project was initiated by them and they had much to gain from its successful completion.

All the interviewees unanimously agreed that money was never an issue on the project. The MIS department was treated as a capital expenditure without its own separate budget at the time. They generally felt that senior management of the company were prepared to spend whatever funds were needed to get the project completed. This is because the company realized the importance of the project to its future survival and growth. It will also be recalled that when the new director of MIS (Mike) was hired and placed in charge of the project, he was able to hire new employees and purchase new hardware that he presumably felt were needed to complete the project. It is possible that his lack of new-systems development technical know-how contributed to his failure to realize from the beginning the magnitude and complexity of the project and the resources that were required to get it completed. For example, despite his lack of experience, he still failed to bring in outside consultants with the expertise and experience to help the IS group tackle the project successfully.

Part of the "blame" should be leveled at senior management for hiring someone of the director's caliber and for failing to stay fully engaged with the project as necessary to monitor its progress. Indeed, MD noted as a concern "the inability of senior management to recognize they had a problem and delayed decision on it for so long. Pete should have been let go sooner and the MIS area should have been reorganized to deal with the project and its related problems earlier." Here is a sampling of their comments on the issue of project financing:

VPM Money was not a big issue. The issue was one of competent people to do the job.

VPSP Money was not an issue on the project. The senior management of the company always provided whatever resources they felt were necessary to get the project completed.

DCA There were no funding problems on the project. The company was willing to spend money in the area. But the president also wanted the MIS group to get the work done as inexpensively as possible and to get the company running on the new system as quickly as possible.

MD Money was never an issue. There were no discussions during the meetings on how much the project would cost or how it would be funded.

We are led to offer the following proposition in light of the above narrative:

Factor F The availability of adequate funds and other resources for a systems development project might not be sufficient to prevent the project from being canceled for other reasons.

Project Cancellation Decision

In this section we examine the decision-making process associated with the termination of the project. We analyze the concerns that might have led to the decision and the role, if any, the users may have played in the cancellation of the project. The project, we learn from the information provided by the users, was suspended by senior management twice and restarted with a new set of individuals brought in from outside. The decision to terminate (i.e., "suspend") the project was always forced on the company when management was confronted with evidence of lack of progress despite the continued provision of resources for the effort. However, because the project was unanimously considered critical to the survival of the company, each termination decision was immediately followed by a new desire to restart from scratch with new hires. This is what each user had to say:

VPM The project was never really canceled; it went through an evolutionary phase. The project was temporarily put on hold to enable the company to concentrate its efforts on getting the computing systems to work. About one and one-half years after Mike (director of MIS) arrived, "the chaotic situation still existed" in the company with respect to computer accessibility. Most of the people fired in the MIS group were fired because of the constant downtime of the system. There was not much distinction made between systems maintenance and systems development in the company; they were considered the same activity. The desire was to regroup and to sort out the issues again because of the daily frustration resulting from the computer systems failure.

DCA The project was not moving as scheduled; it was costing too much money and was creating too many performance problems for the business. It was a good decision to abandon the project. It was killing us; it was difficult to do business on a day-to-day basis. He felt disappointed because "the company had an old system which everyone knew was not doing the job… . The sense of frustration was quite deep within the company. Pete had boxed himself into a corner in the old system. The system had been enhanced and modified so much that it had become so complex [that] only a few people could understand [how] it worked. Any change attempted had an unforeseen ripple effect on some other parts of the system; that was how messy and complex things had gotten with the old system."

VPSP The decision to suspend the project was made partly in response to the fact that middle management at VPSP's level went to senior management and made it clear to them what they felt was "needed by way of a new system to deal with the operations of the business." Whoever has had the Vice President of MIS position has been under a lot of pressure "from senior management to get the new system in place. The current system does not allow fast response to economic changes quick enough in today's market."

MD The project was never really canceled. Things were in such disarray that there was no coding work undertaken. Mike brought "zero leadership" to the MIS group. A lot of people were let go at that time, including Mike, but (MD) was not sure what the reasons were for the downsizing of the MIS department.

The data gathered from the users form the basis of the contributing factor below:

Factor TD Lack of tangible progress on a new systems development project considered critical to the company is likely to have contributed to the decision by senior management to terminate the project and reactivate it with a new cast of technical personnel.

"Zero leadership" was probably one of the more important difficulties the project experienced. It is highlighted by comments regarding such problems as the lack of distinction between systems maintenance and new-systems development, the complexity of the system, and the failure of the system to respond to changes in the marketplace for a marketsensitive industry. It can thus be surmised that the decision to terminate the project and to restart it was made partly in response to the sense of frustration generally felt in the company with respect to the performance of the current system. A further catalyst would have been the realization on the part of senior management, in response to the prompting of middle management, that the project was too critical to the company's future not to be reactivated. A summary of the contributing factors is provided in table 7.1.