Citation
Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management Information Systems, 10(2), 203–225.
Other Sources
Beath, CM. (1983). Strategies for managing MIS: A transaction cost approach. Proceedings of the Fourth International Conference on Information Systems, Houston, ACM/SIGBDP, pp. 415-427.
Bell, T.E. (1989). Managing Murphy’s law: Engineering a minimum-risk system. IEEE Spectrum (26)6, 24-27.
Bernier, C. (1989). Etude des relations entre l’environnement, l’incertitude environmementale perçue et le mode de gestion dans les projets de développement de systèmes d’information. Ph.D. dissertation, École des Hautes Études Commerciales, Montréal, Quebec.
Boehm, B.W. (1989). Software Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1989.
Charette, R.N. (1989). Software Engineering Risk Analysis and Management. New York: McGraw-Hill.
Davis, G.B. (1982). Strategies for information requirements determination. IBM System Journal, (21)1, 4-30.
Denenberg, H.S., Eilers, R.D., Melone, J.J., and Zelten, RA. (1974). Risk and Insurance (2nd ed.). Englewood Cliffs, NJ: Prentice-Hall.
Haimes, Y.Y. (1991) Total risk management. Risk Analysis, (11)2, 169-171.
Kaplan, S., and Garrick, J.B. (1981). On the quantitative definition of risk. Risk Analysis, (1)1, 11-27.
Post, G.V., and Diltz, D.J. (1986). A stochastic dominance approach to risk analysis of computer systems. MIS Quarterly, (10)4, 363-375.
Tversky, A., and Kahneman, D. (1982). Belief in the law of small numbers. In D. Kahneman, P. Slovic, and A. Tversky, A. (eds.). Judgement under Uncertainty: Heuristics and Biases. Cambridge: Cambridge University Press, 1982, pp. 23-31.
Zmud, R.W. (1980). Management of large software development efforts. MIS Quarterly, (4)2, 45-55.
Notes
The authors conducted a review of software development uncertainty and risk literature and identified 35 variables. While their literature review differentiates between uncertainty and risk, they note the similarities represented by the two concepts and consolidate the identified factors into their underlying concepts. For example, risk factors identified from the literature as “team turnover” and “teams not having worked together in the past” are equated with the literature’s uncertainty factor of “personnel changes” to form an underlying concept of “team diversity.” The 35 risk factors are identified only by name: The researchers do not provide more detailed definitions of the terms, except to equate some factors with risk and uncertainty factors from literature. Barki does not list the sources consulted in this literature review, but the work appears to have been written from the MIS context and is unlikely to have included any consideration of digital game development.
we would argue that risk and uncertainty factors, as discussed in the IS literature, are one and the same, and should all be named uncertainty factors
They seem to have lost this battle. I think “risk factor” is the more common term.
Defining risk from existing lit:
In essence, many definitions of risk comprise two dimensions: (1) the probability associated with an undesirable event, and (2) the consequences (usually financial) of occurrence of this event. Speaking of total risk the management, Haimes (1991) states, “Risk is often defined as a measure of probability and severity of adverse effects” (p. 169). In the field of engineering, is defined as risk “a combination of the probability of an undesirable event with the magnitude of each and every foreseeable consequence property, loss of money, injury (damage to to people, lives lost, and so on)” (Bell, 1989, p. 24).
In the management of software projects Charette (1989) states for an event or that action to be considered a there must be a loss associated with it, chance, and some risk, choice involved. Finally, with reference to software risk management, Boehm (1989) defines risk impact or risk exposure as
(RE) RE= Prob(UO) * Loss(UO) where Prob(UO) is the probability of an unsatisfactory outcome, and Loss(UO) is the loss to the parties affected if the outcome is unsatisfactory. (p. 4)
And the authors’ update:
it would seem appropriate to define project development risk by referring to the uncertainty surrounding a project and the magnitude of potential loss associated with project failure. Thus, we define
Software development risk = (project uncertainty) * (magnitude loss due project failure)
This definition, consistent with Kaplan & Garrick (1981) and Denenberg et al.’s (1974) recommendations, differs from Boehm’s in two respects. First, the above definition than refers to uncertainty rather to probability. Second, while Boehm identifies several potential unsatisfactory outcomes for a given project, our definition assumes a single unsatisfactory outcome: project failure (p. 206).
The 35 risk factors are identified only by name: The researchers do not provide more detailed definitions of the terms, except to equate some factors with risk and uncertainty factors from literature.
Several sources break down risk between the development group and the users. Barki does as well.
Since these characteristics are related to technical aspects of a project as well as to its user environment, their reliable assessment requires that two sources be used: the project leader, and the future users of the system. Consequently, two questionnaires were designed: one for the project leader, and one for a representative user.
There is no mention made that the project leader may be a representative user, or may think that s/he is a representative user. This is important when we look at IT identity’s impact on risk behavior.
The authors note that “In order to be included in the sample, a project had to be ongoing, with system conversion not yet completed […] to avoid retrospective bias” (Barki, 1993, p. 209). With my work, retrospective bias may also be a concern. If I’m looking at identification with the product being developed, retrospective may be influenced by management, critical, or consumer reaction may bias retrospectives on the project.
Assessing risk also includes biases:
Unfortunately, assessing risk via a quantitative evaluation of probabilities has two shortcomings. First, in many situations probability distributions of undesirable events are very difficult and unreliable to estimate (Post & Diltz, 1986; Tversky & Kahneman, 1982). These estimation problems are present in many domains including R&D, engineering, insurance,and business policy, as well as IS. Second, many authors draw attention to the relative nature of risk, pointing out that absolute risk does not exist, and that “It is a subjective thing–it depends upon who is looking” (Kaplan & Garrick, 1981, p. 12). Proponents of this view argue that risk involves uncertainty and loss rather than probabilities and loss. Referring to risk in its general sense, Kaplan & Garrick (1981) state: “The notion of risk, therefore, involves both uncertainty and some kind of loss or damage that might be received” (p. 12). (Barki et al., 1993, p. 205.)
The authors identify five dimensions of uncertainty in the literature:
The five dimensions were the uncertainty related to (1) the characteristics of the application itself, (2) the future users of the system being developed, (3) the development team. (4) the task(s) being computerized. and (5) the characteristics of the organization. Since, a priori. we did not know what uncertainty dimensions would based emerge in the study, the five criterion variables were on four dimensions identified by Davis [17], and a fifth dimension (characteristics of the organization) drawn from Zmud (1980), Beath (1983), and Bernier (1989). (Barki et al., 1993, p. 213-214.)
Barki does not list the sources consulted in this literature review, but the work appears to have been written from the MIS context and is unlikely to have included any consideration of digital game development.