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

Project Risks and Uncertainties

Software development projects are inherently risky. Apart from the conceptual nature of the projects, there are often intrinsic risks and uncertainties that are difficult to assess with any degree of reliability prior to the start of the projects. In discussing cost-benefit evaluations of projects, Corti (1973, 75) defined risk as involving "situations in which the outcome is not certain but where the range of possible outcomes is known and the probabilities associated with these outcomes are known or can be estimated with some accuracy." Uncertainty, on the other hand, is described as related to "those situations where either the range of outcomes is known, but where probabilities cannot be estimated accurately, or where even the range of possible outcomes is not known." Thus, in risky situations, according to Fisher (1971, 202), "The outcome is subject to an uncontrollable random event stemming from a known probability distribution." But in uncertain situations, though the outcome may still be subject to random events, it is distinctly characterized by an unknown probability distribution (Ewusi-Mensah 1989).

We do not currently have accurate estimation methods for assessing the probabilities of the various risk factors associated with projects outcomes (Boehm 1991). We do, however, know for a fact that there is an ever present uncertainty as to whether a project may be completed or abandoned for a variety of factors: whether a project may or may not exceed the budgeted costs; whether the schedule for completion will be delayed; and whether the functional specifications will be fully or even partially implemented. In essence, the uncertainty inherent in the outcome of the software development process is a consequence which can be partly attributed to:

The nature of the real world problem domain and the need to abstract from that domain in formulating the software product to be created

The imprecision and incompleteness of the requirements definition and the functional specifications on which the software design alternative solutions are based

The nature, type and magnitude of the errors which may be inherent in the coding, testing and systems integration during the implementation phase of the software development

The changing organizational and/or developmental environments as, for example, when changes are made to the original specifications, and/or as some current team members leave the project and are replaced by new ones.

For large and complex projects there is an order-of-magnitude increase in the risk and uncertainty factors associated with the project's outcomes. Some of the risks and uncertainties that may be unique to software projects include, for instance, large project size. The size of the project may add to the amount of communication and coordination necessary to a successful project outcome by introducing additional layers of interactions among the team members. The complexity of the problem domain may contribute its own risks and uncertainties. This applies to both the design and implementation phases, as bugs introduced in the design phase due to faulty comprehension of the problem domain persist in the implementation phase, adding to outcome uncertainties in the testing of the source code.

Large and complex projects invariably require team-oriented approaches. This introduces yet another dimension of risk and uncertainty into the development equation, because large and complex projects are invariably more difficult to comprehend and manage and are even more prone to problems with communication and coordination of the work of the various subteams than smaller projects are. Typically, large and complex projects are often prone to changes in requirements, which become necessary as new learning and insights gained in later stages of the development necessitate corrections to earlier phases of the development. This forced iterative approach to the development introduces yet another dimension to the risks and uncertainties factors, which if not carefully controlled may create additional hazards for the project.

Technology and technical know-how or experience on the part of the project team may be another factor in a list of risks and uncertainties associated with the project outcome, in particular if the project team has minimal or insufficient experience with the technology needed to undertake the project. The learning capabilities of the team to master the technology to be used in the project may add to the risks and uncertainties associated with the project outcome. The difficulties associated with being able to integrate, in large and complex projects, the different component systems into a composite system create still another layer of underlying risk and uncertainty with respect to the project's outcome. Other potentially problematic factors include the level of commitment of the other members of the stakeholder groups—that is, the users and management—to the successful completion of the project (Keil et al. 1998; Ewusi-Mensah 1997; Barki, Rivard, and Talbot 1993).

In addition to the factors just discussed, there are concerns that may not be unique to software projects but that nonetheless pose their own difficulties. Software projects, in particular applications software, are sociotechnical in nature. They possess a technical or technological dimension, which must be properly understood and managed, as well as a social or organizational dimension, which must also be well understood and properly factored into the dynamics of the development process. The interaction effects of the two critical dimensions introduce yet another layer of risk and uncertainty into the project's outcome. Finally, software projects are capital intensive, requiring the investment of substantial capital and other resources in the development effort. Being able to manage the optimum use of all the resources entails further risk, because projects may be canceled or terminated for lack of funds.

Managing Software Development Project Risks

The inherent risks and uncertainties associated with software development projects have often been cited to explain software project failures. A number of studies have suggested that the best approach to the problem of software failure is to gain a better understanding of the risk factors associated with project development and to manage the impact of these factors. Boehm's (1991) early work, identifying ten software risk factors based on an analysis of several hundred projects, was a pivotal contribution. The factors included providing unrealistic schedules and budgets, changing requirements, and shortfalls in personnel, furnished components, and technology (i.e., "computer science capabilities").

Barki, Rivard, and Talbot (1993), citing but criticizing the pioneering work of Boehm, attempted to extend our understanding of the risk factors plaguing software projects by developing an empirically based set of five risk-factor categories that can be used to assess the risks and uncertainties associated with software development projects. The five categories they identified include the newness of the technology needed for the project, the project size, the level of expertise of the team engaged in the development effort, the technical complexity of the project, and the nature of the organizational environment supporting the project team. The factors were derived from an analysis of survey data obtained from 120 software projects, covering organizations in both the public and private sectors in the Canadian province of Quebec in the early Chapter 3 provides more detail on each of the abandonment factors.) The cogent explanation for the apparent similarities is that while the focus of the two sets of studies may be different, both deal with software development projects. The similarities probably stem from the fact that the underlying causes of the projects' outcomes reflect the risks and uncertainties inherent in software development projects.

For example, Boehm (1991) and Ropponen and Lyytinen (2000) cite problems associated with requirements as project risk factors. Barki, Rivard, and Talbot (1993) list application complexity as a risk factor, which is just a different way of describing essentially the same underlying problem. That problem is that difficulties in comprehending the complexities of the application often lead to revisions in the requirements, as developers and users alike gain a better understanding of the problem domain. The problem of changing requirements is also identified as contributing to abandonment of software projects. Barki, Rivard, and Talbot (1993) cite the expertise of the development team or organization as a project risk factor. Boehm (1991) and Ropponen and Lyytinen (2000), chapter 6, I believe that that factor is only symptomatic of deeper underlying problems— such as changing requirements and lack of expertise. These underlying problems may add to the problems of the project, thus extending the completion time and potentially increasing the cost. Finally, on the issue of the size and composition of the project team, both Boehm (1991) and Ropponen and Lyytinen (2000) list risks involving project personnel, while the abandonment factors suggest that project-team composition in addition to project management and control are potential contributors to project failures. The above specific instances give us some indication of the underlying commonalities between the two sets of studies—one dealing with broad risk factors that software projects generally face, and the other dealing with the specific risk factors that are at the root of abandoned software projects. Thus it can be observed that all software projects face risks; the severity of these risks and the manner in which they combine ultimately decide the fate of the project.