LEARN. PRACTICE. GROW.Write uncertainty that can be analyzed
“Batch problem” is too vague to guide a response. In the fictional example, the supplier has not confirmed file delivery by 03:00; if it arrives late, reconciliation may miss the 06:00 cut-off. The known condition, uncertain event, and affected objective are separated. You need not invent a probability to record the concern and request analysis. If today’s file already arrived late, handle that occurrence as an issue or incident; retain a separate future-recurrence risk where useful. A list of causes without events can hide what needs deciding. A list containing only impacts also fails to show where to act.
Search at handoffs
Walk through the service from file arrival to business acknowledgement. At each handoff, ask about owner, schedule, version, format, access, and acceptance condition. One team knows WebSphere, another knows the supplier calendar, and a third closes the funds position. If only development participated, the register may omit overnight operations dependencies. Compare interviews against logs and documentation without treating one source as complete proof. For sensitive subjects, individual contributions before the meeting can reveal concerns not raised in front of management. Facilitation should allow evidence-based disagreement and record what remains unconfirmed.
Challenge assumptions and distinguish constraints
“The supplier will be available on Sunday” is an assumption until applicable confirmation exists. The exercise’s 06:00 cut-off is a constraint. Risk may be failure to recover before that limit if support is absent. For each assumption, record its basis, validation owner, deadline, and effect if false. Check chains: the database team assumes networking will finish; networking assumes security-approved access. Apparent availability can result from circular promises. A dependency map helps locate the point without a real commitment. Do not turn a desired date into confirmed capacity.
Use categories without replacing events
The RBS organizes sources such as technology, people, suppliers, and the external environment. Use it to find gaps and tailor service questions; it is not a closed list proving complete coverage. Keep the concrete event in the register and link it to its category. If three teams record the same supplier failure under different names, relate or consolidate entries while retaining objectives and owners; do not automatically count the same consequence three times. A supplier can create distinct events that should not be merged merely because they share an origin. Include opportunities: a calendar change may allow extra rehearsal and reduce uncertainty, but benefit depends on confirmed access and capacity.
Make the register observable and reviewable
Complete the entry with owner, exposure period, source, trigger, and next action. “Monitor the supplier” does not identify a signal. In the fictional case, no file confirmation by 02:30 triggers contact with the owner before expected delivery; timing must fit available responses. If logs show three delayed deliveries but omit periods without telemetry, do not conclude there were only three problems. State the gap and plan data collection. Deliver two threats and one opportunity with testable assumptions and objective links. Repeat review when design or participants change, retaining the history of where entries came from.
Workshop: turn “supplier risk” into an entry with condition, event, impact, owner, a 02:30 signal, and pending validation. Add an extra-rehearsal opportunity in a freed window. Mark an already observed delay as a separate issue and link recurrence risk.
Common pitfalls
Recording only categories, treating observed incidents as hypotheses, accepting circular assumptions, counting duplicates as independent exposure, or mistaking missing logs for absence of events.
Related topics: Context, appetite, and decision rights · Organize people, cadence, and resources · Identify events, assumptions, and opportunities
Each entry should explain what may happen, why, to which objective, and with what evidence. Identification continues throughout the project; examples and times are fictional.
Reference: Risk identification · PMI-RMP five-domain ECO, updated-2024 public document