The work includes citations for several studies that generated lists of risk factors:
- S. Alter, M. Ginzberg. (1978). Managing uncertainty in MIS implementation. Sloan Management Review 20(1), pp. 23–31.
- F.J. Heemstra, R.J. Kusters. (1996). Dealing with risk: A practical approach. Journal of Information Technology 11(4), pp. 333–346.
- T. Moynihan. (1997). How experienced project managers assess risk. IEEE Software 14(3), pp. 35–41.
- R. Schmidt, K. Lyytinen, M. Keil, P. Cule. (2001). Identifying software project risks: an international Delphi study. Journal of Management Information Systems 17(4), pp. 5–36.
Moynihan was already on my to-do list, as was Schmidt et al.
Hazel Taylor cited Heemstra & Kusters (1996) as well as Alter & Ginzberg (1978).
Page 117 includes a table describing six dimensions of risk.
Under the team dimension, the author includes “insufficient knowledge among team members” and “motivation” in the description. Among the full set, these two seem related to my work. We see that skills are often the primary focus of team risk. Motivation may be related to identity, though it’s more likely the authors were considering pay, recognition, and advancement as motivators rather than identification with the product.
frequently changing requirements are not the only possible requirements-related problem associated with system
development projects. Incorrect, unclear, inadequate, ambiguous or unusable requirements may also increase the problems, or risks, associated with a software development project.
The lack of user involvement during system development is one of the most often cited risk factors in the literature. If the attitudes of users towards a new system are unfavorable, then it is likely that they will not cooperate during a development effort, leading to an increased risk of project failure.”