Citation
Wallace, L., Keil, M., & Rai, A. (2004). Understanding software project risk: a cluster analysis. Information & Management, 42(1), 115–125. https://doi.org/10.1016/j.im.2003.12.007
Notes
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.
Under the requirements dimension the author notes
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.
Feature creep isn’t specifically mentioned (frequently changing requirements may not be creep by my operationalization, since swapping in new requirements for old isn’t creep if no new work or other expense is involved) though it’s certainly one possibility when requirements change. The authors also don’t specifically mention over-requirement.
Under the user dimension, the author notes
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.”
Other authors have noted that user focus is easier in a smaller projects with fewer users, and are more difficult with commercial software with large user populations. I have yet to find an author that specifically attempts to mention users as part of the development team (they’re always split) nor any form of risk or benefit for to having members of your development team consider themselves part of the target user base.
The paper has other material suitable for game-related project management studies, but is out of scope for my current work.