Despite the success stories in the literature, it remains a sad statistic that too many software development projects end in failure. At least a quarter of all software projects are canceled outright, and it is likely that 75% of all large systems projects are dysfunctional because the systems produced do not meet specifications or are simply not used. The average software project runs over its budget by 50%. It is common knowledge that software projects are risky, and thus there has been an intense search for appropriate managerial action to counteract software project risk
What is the risk?
The concept of risk is not clear to most practicing managers. Much like the problems the average person has understanding Bayesian statistics, the word “risk” usually conjures up an image of negative outcomes. A “risky” project is seen as one that is likely to fail. A risk factor is seen as an opportunity to fail. This view of risk overlooks the true nature of the beast
Risk as an Element of Decision Theory
The following explanation is highly simplified but sufficient for the purpose of this chapter. For a complete treatment of decision theory and risk, see the collection of essays by Arrow (1965)
Decision theory describes the decision-making process as a choice of actions leading to a specific outcome. A small number of actions lead to outcomes that are favorable, a few to those that are unfavorable, but the vast majority lead to outcomes that are unclear. Assuming that the clearly favorable outcomes are too small to be attractive, the unclear alternatives present the decision-maker with risky opportunities.
Risk as Viewed by Practicing Managers
There are two important biases affecting risk evaluation that have been observed among practicing managers. First, managers act as if they are evaluating only the magnitude of a loss, without considering the probability of the loss. Their focus is on the loss, not the potential gain, because risk carries a negative connotation to them. As a result, their ranking of alternatives is often out of line with expected outcomes.
How Internet-Based Projects Differ From Other IT Projects
Geographic dispersion of team members and the locus of project management are just two of the important risk factors affecting Internet-based projects. Project managers must also deal with the problem of being separated from their users, both geographically and temporally, which complicates the process of verifying work and seeking advice.
Information Technology (IT) Project Risk
IT project risk factors have been defined as any factors that could affect the success of IT projects (Schmidt et al., 2001). Numerous studies have sought to catalog IT project risk factors. A thorough review of risk factors and a ranking of the most important risk factors are presented by Keil, Cule, Lyytinen, and Schmidt (1998) and Schmidt et al. (2001). All 53 of the risk factors discussed in these two papers apply to both traditional IT projects and Internet-based projects.
Internet-based project risks
In recent years, the management of software projects, as well as other types of projects, has met with a new venue, the Internet. By taking advantage of the flexible, ubiquitous communications afforded by the Internet, project managers have been able to extend team membership to analysts and programmers who would not have worked on the project because of distance and time factors.
Sources of Risk
As a first step in formulating strategies to deal with risks, it is important to understand the sources of risk (Schmidt et al., 2001). There are two reasons for this. First, by recognizing the source of risk, the project manager can take action directed at the source to improve the chance of a positive outcome, much as a doctor treats an infection rather than the fever that is a symptom of the infection. Second, some risk sources are perceived by managers to be beyond their control, which leads them to inactive management of the associated risks. By understanding the sources, project managers can take special care to attend to risks they might otherwise overlook.
Existing knowledge about software project risk was summarized, and the concept was extended to cover specific situations typical of Internet-based projects. Four important concepts were emphasized. First, all risks can be traced to a source, and action taken to manage risks should be directed at the sources of risk. Second, the identification of project risks is a key process in risk management. A hybrid approach using checklists of known risks combined with brainstorming to adjust the list to a specific project provides the best approach to identifying risks.