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

Stakeholders-Interaction Model

As discussed in earlier chapters, software project abandonment is a multidimensional event with several interacting subcomponents. The CODIS case study has explored the factors relating to the role of users and their perceptions in the systems development process. The interaction of the users group with the other two stakeholders—that is, the IS staff and senior management—provides us with a framework for understanding the dynamics of the systems development process and for understanding the risks associated with systems development failure.

Figure 7.1 depicts the three main pillars of the stakeholder-interaction model (SIM) as constituting pairwise interaction and communication between the IS staff and the users group, between senior management and the users group, and between senior management and the IS staff. The software development literature is replete with articles indicating user involvement as a prerequisite to successful project development. What is not clear is the extent to which inadequate or inappropriate interaction with codevelopers of a project may act as a catalyst to its demise. We have already discussed the role each stakeholder plays in the systems development process. We now discuss the interactions each stakeholder must have with the others to ensure successful project development.

Interaction between IS Staff and Users Group The level and frequency of interaction between these groups should be high, almost day-to-day, to keep everyone aware of the varied issues that are bound to crop up in the course of the project. The objective is to foster an environment of cooperation and collaboration, learning, and exchange of views on the technical capabilities of the system vis--vis the users' expectations and the information needs that the system is intended to satisfy. When the level of interaction, collaboration, and communication is judged satisfactory by both groups, the likelihood of project success may be significantly increased.

Interaction between Senior Management and Users Group The frequency of interaction, collaboration, and communication between these two entities may be relatively low compared to that between the users and the IS staff. Still, this interaction is critical to effective project development in conveying the level of senior management commitment to and interest in the successful outcome of the development process to the users group. In addition, the value of the project to the organization can be more convincingly expressed by senior management, with its broadbased perspective on the organization's future direction and strategy. This interaction will also have the beneficial effect of reassuring the users of the significance of their role in the project and help motivate them to work more diligently and cooperatively with the systems developers toward a successful outcome.

Interaction between Senior Management and IS Staff This leg of the model is equally critical to successful project outcome. Depending on the prevailing organizational environment, interaction should be as frequent as necessary to achieve the following:

Make the IS staff aware of senior management commitment to the project's success and its importance to the organization.

Help resolve quickly and effectively project-related problems requiring decisive management action.

Make the work of the IS staff on the project, as well as the project's significance to the organization, visible to the rest of the organization.

Help assure the IS staff of the availability of the resources it needs to carry out the project.

Enable senior management to learn as quickly as possible of any problems encountered during the development and of how they may affect the project's outcome.

Figure 7.1: Stakeholder-interaction model

Communication among all three stakeholders is essential to the success of the project development process. Consequently, if the level of interaction and communication required of any pair of stakeholders falls below what is expected depending on the size and complexity of the project, the entire development process may be affected. For example, inadequate communication between senior management and the users group may undermine the level of commitment users feel senior management attach to the project, which may in turn affect their own level of commitment to the project. Even more important, it will prevent senior management from learning firsthand from the users group of any project mishaps or foul-ups with the potential to inflict serious damage on the development efforts. It is therefore necessary that the level and intensity of interaction and communication existing among the stakeholders be appropriate to the task in order to ensure successful project development. We now discuss the factors derived from analysis of the data in the context of the interaction model to highlight the potential problems that a breakdown in any leg of the model may produce.

Project Goals

The relationship between IS staff and the users group fell somewhat short of the expected level of cooperation and collaboration in this case. The result was the lack of agreement or consensus on the objectives or goals of the project and how they could be jointly accomplished. The interaction between IS staff and the users group achieved in the project did not pass the minimum threshold essential to create a mutually supportive and productive environment for successful systems development to thrive. Consequently, the development efforts "never moved beyond the level of what we wanted to do and could the computer do it," as expressed by VPM. Senior management also share part of the responsibility for failing to engage with both groups and to make their members realize individually as well as collectively the value of the project to the organization and the need for joint action to create the desired systems product.

Project Leadership

Project leadership is an important issue senior management need to resolve early on in the development process. As Krault and Streeter (1995, 69) point out, "Large projects are more successful if a single, often exceptional, individual with both application-domain knowledge and software knowledge guides and coordinates the project," though such an individual may be hard to come by in most projects. In this instance the failure of senior management to fully engage with either the IS staff or the users group also made them unaware of the lack of leadership and progress on the project until it became obvious and much time had been lost.

Project Interaction

The level of interaction and collaboration necessary for any userinitiated project to succeed should generally be high, as appropriate for a joint development project. Each participant in the project brings a level of expertise and experience critical to the success of the project. For example, the users will possess application-domain knowledge lacking on the part of the IS staff; similarly, the IS staff will possess software and systems-domain knowledge that may be lacking in the users group. Whenever the level of interaction between these two groups is too low to permit mutual interchange of ideas about the requirements of the desired application system, and the technical feasibility of the system is not properly communicated and understood by both groups, the potential for failure of the project is going to be significant. The statements from all the users have this underlying thread of lack of sufficient contact and collaboration between the two groups. Here again, if senior management had acted appropriately, the problems would have been observed sooner and suitable steps could have been taken to correct them.

Senior Management Involvement

At the apex of the model sits the senior management of the company, playing the role of benefactor and supervisor to the project. Senior management's involvement in the project should thus be perceived throughout the project team as active and not passive. Hence the necessity of convincing the team members of management's commitment to the project's success. This sort of active commitment to the project on senior management's part may elicit from the rest of the team—principally the IS staff and users group—an equally significant commitment to project. Another benefit is that executives will become aware sooner than usual if the project is experiencing difficulties that, if not resolved appropriately and quickly, can lead to problems later. The data from this case suggest that senior management's failure to participate fully in the project during the tenure of the two MIS directors—Pete and Mike—was partly to blame for the disastrous results. Both directors were able to get away with less-than-full disclosure of the status of the project. Another point worth noting is the singular damage project cancellations bring to the IS staff and its leadership through mass dismissals and demotions. This makes it imperative for the IS staff to be especially vigilant in their role as technical experts on the project, because of the tendency for senior management to assign a disproportionate share of the blame for the project cancellation to the IS staff, as this case and others illustrate (see, for example, the Confirm case (Oz 1994)).

The stakeholders-interaction model has provided a framework for interpreting and explaining some of the underlying factors that contributed to the cancellations of the project during the tenures of both MIS directors. The model is useful in pointing out the need for communication, collaboration, and interaction among the stakeholders as necessary for successful systems development. However, because project cancellation is a multidimensional issue, the model is not sufficient for determining whether projects meeting these—that is, communication, collaboration, and interaction—requirements will be successful. What we can infer from the model is that communication, collaboration, and interaction among the major stakeholders may significantly improve the likelihood of the project being successfully completed.

Project Development Risks

In chapter 2 I highlighted some major studies that have contributed to our understanding of software project risks. I cited, in particular, the contributions of Boehm (1991), Barki, Rivard, and Talbot (1993, 2001), and Ropponen and Lyytinen (2000), whose studies have examined the risk factors associated with software project failures. However, none of these studies specifically examined risks associated with the role of users in software development. In this section I extend the analysis of project risks to specifically include risk factors involving the role of users in software development projects.

The stakeholders-interaction model has helped to explain how high the level of interaction and communication between the three pairs of stakeholders should be if project failure is to be minimized, if not avoided. It does not, however, fully discuss the risks of project failure where the level of interaction is deemed satisfactory for all pairs of stakeholders. In this section we use results from previous studies to try to describe the multidimensional nature of issues associated with failed or abandoned projects and to partially explain some of the risks associated with development projects, as illustrated by this case.

In a study of software project risk factors, Keil et al. (1998, 78) identify several risk factors associated with users, ranging from "failure to gain user commitment," "lack of adequate user involvement," "misunderstanding [user] requirements," and "failure to manage end user expectations" to "conflict between user departments," derived from an analysis of the perspectives of software project managers in Finland, Hong Kong, and the United States. Powers and Dickson (1973, 156) also conclude from an earlier study that "user participation is crucial to the success of the MIS project." They list a number of factors representing user participation that, in their view, are instrumental to user satisfaction with project results. These factors are as follows:

"The origination of projects by users as opposed to IS staff"

"The reported clarity of initial objectives and the specificity of user information requirements"

"The existence of a project team consisting, in part, of the managers who were to use the products"

"The managers' perception of their participation in project development" (Powers and Dickson 1973, 153)

The issue of projects being initiated by users as opposed to IS staff is indeed important; however, it is not clear to what extent this issue contributes to the project's successful completion. In the case of CODIS, the project was definitely initiated by the user group, which was involved in its development both "by doing" as well as "by control" (Ives and Olson 1984, 590 also see Tait and Vessey 1988). Still, the project never really progressed.

Risks Associated with Project Objectives On "clarity of initial objectives," Powers and Dickson (1973, 153) found "several projects where the initial objectives were reportedly very vague." This situation, however, changed over time as users worked closely with IS staff to define "their objectives and information requirements as they learned more about their information/decision-making environments." This result is confirmed by Newman and Noble (1990) in their learning model of user interaction with IS staff. Keil and colleagues (1998, 78) also found that project managers considered "changing scope/objectives" of a project to be a risk factor threatening project success. Unfortunately, in the CODIS project there was no clear attempt on the part of the IS staff to facilitate the learning process or to create an environment where the project's objectives could be clarified and the information requirements better articulated as the users became more aware of their information needs vis--vis the technical feasibility of achieving those needs. Perhaps the level of technical competence and experience of the IS staff played a role in the failure of the learning model in this case, but so did the user attitude of claiming to be in full "control" over the IS staff, who the users believed to be acting as merely consultants in the initial stages of the project development. Here also the conflict and political-influence models of Newman and Noble (1990) seem to be at work. The users asserted their authority in some areas of the project development where they clearly would have been wiser to have deferred judgment to the technical experts. This attitude of the users might have created some conflicts in their relationship with the IS staff in terms of deciding what needed to be done, the order in which it needed to be done, and how it needed to be done.

Risks Associated with Project Team A project team consisting of the "managers who were to use the products" is indeed necessary in helping to define the information requirements the system must satisfy. Nevertheless, it is not a sufficient criterion for systems success, as this case illustrates. All the users involved in the project were drawn from the ranks of middle management—the primary beneficiary of the system to be developed. Still, their failure to carefully articulate their information needs, coupled with the lack of experience and technical expertise in new-systems development methodology, almost guaranteed the demise of the project. As Keil et al. (1998, 78) also confirm, "Misunderstanding [user] requirements" was considered a major risk factor in project development by project managers. Similar findings are noted by Boehm (1991) and Ropponen and Lyytinen (2000) with respect to requirements changes. In the case of CODIS, the situation was exacerbated by the failure of senior management to stay engaged with the project at a level that enabled them to be sufficiently informed about problems encountered on the project. This fact is also confirmed in the study by Keil and colleagues (1998, 78), which lists "lack of top management commitment to the project" as being the premier risk factor perceived by project managers in the three countries they studied—Finland, Hong Kong, and the United States.

Risks Associated with User Involvement The successful development and implementation of IS in organizations is influenced by several factors, including user involvement. Tait and Vessey (1988) present data contradicting the hypothesis that the likelihood of systems success increases as a function of the extent of user involvement in the development process. They are, however, able to accept the claim that "as the complexity of the system increases, the extent of user involvement increases." They explain this fact by suggesting that the "managers react to systems that are technically complex by involving users in their development" (pp. 99, 104). Indeed, as they subsequently suggest, the above two hypotheses are complementary in that without the equally active and committed participation of technically competent and experienced IS staff, systems success becomes illusory in the development process because the "likelihood of system success" will not significantly increase. This is what happened in the CODIS project—the users seemed to bear a disproportionate share of the burden for the development process without a matching level of commitment and participation from the IS staff and the senior management. Thus "lack of adequate user involvement" may be a risk factor that needs to be monitored, but perhaps a more significant risk to project development success may be "misunderstanding [user] requirements" (Keil, Lyytinen, and Schmidt 1998; Boehm 1991; Ropponen and Lyytinen 2000).

Tait and Vessey (1988) present two other hypotheses, one of which points to the likelihood of systems success as a decreasing function of the resource constraints on the development of the system. The other hypothesis, which was rejected, speculates that user involvement decreases as the resource constraints on systems development increase. The combined effect of the two hypotheses suggests that resource constraints can indeed be expected to "have a significant negative effect on successful CBIS design and implementation"; however, that fact may not lead to "a significant decrease in the involvement of users in the development process" (p. 104). Analysis of the users, statements confirms that resource constraints were not an issue in this case study, nor was the users' involvement in the development process. Thus the abandonment of the project could not be attributed to lack of adequate resources (e.g., several IS staff were hired and new equipment was purchased), nor can it be blamed on a lack of active user involvement. On the contrary, the project's abandonment can be attributed to a combination of factors, not least of which includes the lack of technical leadership in the IS group and management leadership from the ranks of senior management; the lack of satisfactory technical infrastructure in the MIS department to support a project of that magnitude, complexity, and significance to the company; and inadequate or inferior technical competence and expertise of the IS staff on the project team. The claim by Tait and Vessey (1988, 105) that the "information systems department has greatest knowledge of the complexities of the system to be implemented" is not confirmed in this case. Consequently, the risk of project abandonment was very high in this project in spite of the cluster of factors Powers and Dickson (1973, 156) have outlined as "crucial to the success of the MIS project." Several of the user-related project risk factors that Keil et al. (1998) identify are present in the CODIS project.

Finally, as noted, Newman and Noble (1990) discuss four models of user involvement: learning, conflict, political influence, and garbage can. They indicate how different models are appropriate to explain the nature of user involvement in different stages of systems development as well as within different contexts. With the exception of the learning model, which was clearly indicated to be absent, all the other interaction process models are exhibited in this case. In the learning model, the interaction between users groups and IS groups can take the form of one-way or two-way learning. In the case of the project in question, learning could have been the basis of interaction between the users group and the IS staff. However, the data does not support this model, in that the communication and therefore the learning between the two groups was at a bare minimum. No attempt was made by the IS staff to help the users group appreciate the technical complexity of the system to be developed and to help in refining the systems requirements. The users group, on the other hand, kept the IS staff at arm's length; they viewed them only as consultants who were "expected to deliver" the system, as VPM indicated. The failure of the IS staff to manage the expectations of the users group seemed to have indeed contributed to the project's failure.

The conflict model was present in their relationship, which stemmed, in part, from the "frequent systems failures" and "the chaotic situation" with respect to the computing facilities, a situation that had a serious negative effect on the ability of the users group to carry out their tasks. The users group attributed this condition to the technical incompetence of the IS staff for failing to keep the computers operating in any reliable manner. It was this sense of frustration that eventually forced the president of the company, after repeated complaints from middle management, to demand that the MIS department "return the company to the old computer system."

The political-influence model of the interaction process was also played out in this case, first in the attitude of Pete, which was described by DCA as "very directorial, … everything had to be done Pete's way and if Pete disapproved then it could not be done." Subsequently, Mike, who replaced Pete, tended to concentrate on his interaction with senior management in an effort to curry favor with them on his job performance. Eventually, when the situation did not improve, middle management also exercised their political option and forced senior management to stop the project, an action that led to the firing of Mike and several of his staff.

Perhaps the model that best typifies the kind of user interaction with the IS staff in this case is the garbage-can model. As Newman and Noble (1990, 93) describe it, "Randomness and accident play a large part… .Involvement and participation are fluid. Key players leave the scene, the composition of the team changes constantly, as do the goals." We saw earlier that the project changed IS leadership twice and that with the new leader, Mike, new IS staff were hired to work on the project. However, in most people's minds the project was still vaguely defined. For example, an IS staff member associated with the project from the beginning and who was still with the company at the time of this study recalled that "the scope of the project kept changing all the time; … People came in [i.e., joined the project] too soon when the systems were not set up; … New programmers were hired to do the coding even before the design specifications were completed." It was a classic case of "a decision situation" for which solutions were being proposed before the requirements problems had even been defined or at least identified and prioritized. Again, the same IS staff member noted that "there was no requirements analysis done as to how to get started on the project before even the new hires were brought on board the project. The team did not have that many design specs written, no true specs that a coder could code from." The Keil et al. (1998) study confirms most of the above problems as risk factors project managers view as detrimental to project success.

Consequently, the relative stability of the users group did not really matter because the technical development of the project rested with the IS staff only, which was constantly changing. Indeed, to cite Cohen, March, and Olsen (1972, 1), the project development effort exhibited all the properties of "organized anarchies," namely, "problematic preferences" (e.g., the requirements were unclear and undefined); "unclear technology" (e.g., no distinction was made between new-systems development and systems maintenance of an existing, mature system); and "fluid participation" (e.g., changes in the IS leadership and staff over the course of the project). It was in every respect a case of a project organized on the basis of "solutions looking for issues [i.e., requirements] to which they might be the answer, and decision makers looking for work" (Cohen, March, and Olsen 1972, 2).