Risk Identification

Risk identification is finding risks while there is still time to act — “you can’t manage what you don’t know about” [1]. Most of what you are missing is already known to someone on the project who has not been asked.

1. What identification can and cannot reach

Three bands, and naming them tells you what to expect from the effort [1]:

Most risks are already known, to someone who is not you. [1]

• Known — risks “one or more project personnel are aware of — if not explicitly as risks, at least as concerns.” The job is to get them onto one list.
• Unknown — risks that “would be surfaced… if project personnel were given the right opportunity, cues, and information.” This is the target of every structured method.
• Unknowable — risks “even in principle, none could foresee”, and “beyond the purview of any risk identification method.”

One caution belongs with them: “no overall judgment can be made about the success or failure of a project based solely on the number or nature of risks uncovered.” A long register is not a failing project, and believing otherwise keeps risks off the list.

2. The barrier is the reporting line, not the technique

Across 15 field tests in 11 organisations, the SEI found something managers did not expect:

Even in organizations where staff across the project hierarchy felt that they had open and honest communications, the presence of a reporting relationship in an interview group always had an inhibiting effect on the subordinates.

Teams that believed they communicated openly went quiet when a supervisor was present. So the peer-group rule is engineering, not etiquette: interview groups of three to five peers with no supervisor, four groups per project, one unattributed copy of the findings to the project manager — and in the SEI’s evaluation method, the flipcharts and numbering maps are destroyed at closure [2]. “Confidentiality and non-attribution are non-negotiable issues.”

That method also supplies a quality gate no other source offers: a 2.5-hour peer interview should produce 15 to 40 risk statements, and fewer than 15 means the session is run again.

3. Three techniques, which fail in different places

A taxonomy sweep buys coverage. The SEI taxonomy is three classes — product engineering, development environment, program constraints — with 13 elements and 64 attributes. Its value is that somebody is forced to ask about the environment and the externals, not only about the product. The questionnaire is deliberately semi-structured: a fully structured interview yields more comparable and less valid data. For example, under design → performance it asks “are there any problems with performance?”, offers six cues only after people have answered freely, then probes on a “no”. The question is a door, not a datum.

A premortem buys the objection nobody will voice [3]: “team members assume that the project they are planning has just failed—as so many do—and then generate plausible reasons for its demise.” Four steps — declare the failure, write privately, read round-robin, revise the plan. Its mechanism is social: raising an objection at a kickoff looks disloyal, and inside a premortem it is the assigned task.

A picture of success buys the boundary. Ask when will it be, what will it be, what makes it a success before any risk talk [2] — because “if I am focused on arriving safely at my destination tomorrow, my list of risks will be completely different from the list I would define if I were focused on successfully raising a family.” See threshold of success.

The cheapest sweep of all is a checklist. Boehm’s top-10, from a survey of experienced project managers, still starts where a software team least expects: personnel shortfalls at number one, ahead of every technical item [4].

4. Shrinking the list

Identification is cheap and analysis is not — affinity grouping yields more than a hundred candidate ideas in 30 to 35 minutes [5]. Consolidate statements into 7 to 11 risk areas sharing a mitigation strategy, then ask of each pair whether one area’s conditions drive another’s. Areas with many outgoing arrows are the drivers, and those are what you mitigate [2].

Mitigate areas, not rows. [2]

How solid is this?

• Where it comes from. Two SEI technical reports and a method description reporting operating experience across more than 50 organisations. The field tests are evolutionary development, not a controlled study: the instrument changed between them.
• What is contested. The checklist tradition’s provenance — earlier risk research “relied on descriptions of good practice observed by the researchers” [6], so compare Boehm’s list and the SEI taxonomy rather than merging them.
• What we do not hold. No source here shows that a structured method finds more risks than an unstructured one, and the one number attached to the premortem is third-hand.

---

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [7] on software project management.

References

1. M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich, and C. F. Walker,
   “Taxonomy-Based Risk Identification,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-93-TR-6, June 1993.
2. R. C. Williams, G. J. Pandelios, and S. G. Behrens,
   “Software Risk Evaluation (SRE) Method Description, Version 2.0,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-99-TR-029, Dec. 1999.
3. G. Klein,
   “Performing a Project Premortem,” Harvard Business Review, vol. 85, no. 9, pp. 18–19, Sept. 2007, [Online]. Available: https://hbr.org/2007/09/performing-a-project-premortem
4. B. W. Boehm,
   “Software Risk Management: Principles and Practices,” IEEE Software, vol. 8, no. 1, pp. 32–41, Jan. 1991, doi: 10.1109/52.62930.
5. A. J. Dorofee, J. A. Walker, C. J. Alberts, R. P. Higuera, R. L. Murphy, and R. C. Williams,
   Continuous Risk Management Guidebook, no. CMU/SEI-96-HB-002. Software Engineering Institute, Carnegie Mellon University, 1996.
6. R. Schmidt, K. Lyytinen, M. Keil, and P. Cule,
   “Identifying Software Project Risks: An International Delphi Study,” Journal of Management Information Systems, vol. 17, no. 4, pp. 5–36, 2001, doi: 10.1080/07421222.2001.11045662.
7. D. Root,
   Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

---

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.