Software Project Risk Identification

Identifying risks is an absolutely essential activity for all software projects. A risk is an event which is unpredictable and which has negative consequences. You must identify project risks, so that you can analyze the likelihood and impact of the risks (see a nice overview at, and then plan to prevent the risks (in part, through testing) and mitigate the effects of risks if they do occur.
Technique #1 – At a very high level of granularity, you take each of the four components of any project (time, cost, quality, features) and ask yourself, what could happen to make any of these four components go wrong. For example, "In my project, what events would make me go over budget?" Pros: easy, good way to get started. Cons: too high level to catch all risks.
Technique #2 – At a slightly lower level of granularity than Technique #1 above, you can walk through a taxonomy. This is simply a classification of generic software risks. There are many software project risk taxonomies available. One commonly used taxonomy was published by the Software Engineering Institute. It is available in an Appendix in a document at The SEI taxonomy is structured into various categories and sub-categories as a list of 194 questions. Examples include, "[159] Are the development facilities adequate?", and "[3] Are there any TBDs in the specifications?" Pros: relatively easy and mechanical. Cons: can take a long time, too generic to catch risks specific to specialized projects.
Technique #3 – A less generic approach of risk identification is to walk through your software project specification documents, and ask what could go wrong for each feature, activity, and person. Pros: quite specific. Cons: only as good as the specification documents.
Technique #4 – If you use traditional project management techniques, you will have a Work Breakdown Structure. For each leaf Work Package activity, you ask yourself, what risks are associated with the activity. Pros: Can be applied to many levels of work package granularity, leverages an existing WBS. Cons: requires a WBS, often emphasizes activities and deemphasizes resources.
Technique #5 – An unusual approach, but one which I’ve used quite successfully, is to storyboard. You assume various roles (end user, developer, etc.) and walk through various scenarios, asking yourself what could go wrong at each step. Think about going on a plane trip: drive to airport (bad traffic risk), park at airport (no parking available risk), etc. Pros: effective in practice, very specific. Cons: more art than science.
(Semi) Technique #6 – A theoretical but promising approach is explained in a research paper at The authors present a possible structured way to identify risk by first identifying six project components: activities, artifacts, roles, practices, features and capabilities. Next you run through a list of risk patterns. For example, one specific example of a pattern is: "If Requirements <artifact> loses Clarity <feature> then Development <activity> takes more time than expected." Pros: unknown. Cons: unknown.
This entry was posted in Software Test Automation. Bookmark the permalink.