Risk identification is the disciplined search for uncertainty that could affect objectives. Good identification considers adverse outcomes and opportunities, looks beyond obvious events, and records enough context for later analysis.
Use cause–event–consequence statements
A useful statement separates the source of uncertainty from the event and its effect. For example: “Because a single supplier provides a specialized component, an extended disruption may delay production and customer deliveries.” This is more actionable than writing only “supplier risk.”
Combine techniques
| Technique | Best use | Watch for |
|---|---|---|
| Structured interviews | Specialist knowledge and tacit concerns | Interview bias |
| Process mapping | Handoffs, bottlenecks, and control gaps | Missing external dependencies |
| Scenario prompts | Low-frequency or emerging events | Dramatic but irrelevant stories |
| Incident review | Recurring failures and trend evidence | Unreported events |
| Assumption testing | Plans built on uncertain conditions | Treating assumptions as facts |
| Lessons learned | Known patterns from earlier work | Copying old risks without checking relevance |
Look across categories
- People and skills
- Processes and controls
- Technology and information
- Suppliers and dependencies
- Legal and compliance obligations
- Resources and capacity
- Reputation and stakeholder confidence
- External and market conditions
Avoid common traps
Do not confuse an existing issue with a future risk, list consequences as if they were risks, or capture only risks the team can easily control. Consolidate true duplicates while preserving meaningful differences in cause, owner, or response.
Questions that uncover risk
- What must go right?
- Which assumptions could fail?
- Where are the single points of dependency?
- What changes faster than our controls?
- What has nearly failed before?
- What could create an opportunity?
Use several lenses
No single workshop prompt finds every material risk. Look at objectives, process steps, people, technology, information, suppliers, assumptions, interfaces, deadlines, external change, and prior incidents. Ask both “what could prevent success?” and “what could create an unexpected opportunity?” Then examine causes and consequences separately so the risk statement does not collapse several different issues into one vague sentence.
Example: introducing a new scheduling system
“The system may fail” is too broad. More useful entries could describe inaccurate migrated data causing missed appointments, insufficient training causing workarounds, or an interface delay preventing timely updates. Each statement points toward different controls, owners, evidence, and treatment options. The purpose is not to predict every failure but to reveal decision-relevant uncertainty.
Prompts that reduce blind spots
- Which assumption would hurt most if it proved false?
- Where does work pass between teams or systems?
- What has changed since the last review?
- Which near misses or recurring exceptions are being normalized?
- What depends on one person, supplier, location, or technology?