Risk Identification
Finding risks before they find you
Identification is iterative, not a single workshop. It runs through initiating, planning, executing, and monitoring; new risks appear as design matures and vendors are selected. Techniques to know: brainstorming, the Delphi technique (anonymous, iterative expert consensus, good when personalities dominate), nominal group technique, interviews, root cause analysis such as fishbone diagrams, SWOT analysis, assumption and constraint analysis, prompt lists, document review, and checklists. Checklists alone miss novel risks, so pair them with prompt lists built from the RBS to guarantee category coverage.
Write each risk as cause, then uncertain event, then effect: "Because the vendor may miss the delivery date, we may need to resequence integration testing, resulting in a two-week schedule slip." Vague entries such as "the project may fail" cannot be analyzed, owned, or responded to.
Traps: recording only threats when opportunities belong in the register too; logging an issue as a risk (if it has already happened, it is an issue, not a risk); identifying risks without listing assumptions the register depends on; skipping secondary and residual risks until too late; letting one stakeholder group monopolize the session.
Rule of thumb: every risk gets a cause, an owner, a category from the RBS, and at least one candidate trigger before it enters the register.
Worked example: an assumption analysis reveals the team assumed site access on day one. Because access may be delayed by permitting, that becomes a risk with a named owner and a permit-approval trigger date.