Fifty-Eight Risks, One Workshop, and No Causes

Diagnosis - what the register actually shows:

• Labels like 'scope creep' are categories, not risks. They cannot be owned, analysed, given a probability, or responded to. A register of categories is a table of contents.
• No cause means no way to design a response that attacks the source, and no way to define a trigger. No effect means no link to schedule or cost, so nothing can be analysed.
• 22 duplicates inflate the count and manufacture the illusion of completeness. 'Full' is a count metric, not a coverage metric.
• One 90-minute brainstorm with a fixed group is subject to availability bias (recent, memorable risks dominate), anchoring, and hierarchy (junior staff defer to the PM). It provides no coverage assurance at all.
• Two departing workstream leads took their tacit knowledge with them. Whatever they knew about the cutover and the vendor is now unregistered.

Techniques and why:

• Risk breakdown structure coverage check - find the empty categories. Fast, and it directly tests the claim that identification is complete.
• Structured interviews with the replacements of the departed leads and with the three application owners who control the cutover window. These people hold interface and dependency risk that no general workshop surfaces, because it is specific to their contracts.
• Assumption analysis on the schedule - the negotiated cutover window and the month-11 lease expiry are assumptions wearing the costume of facts. Test both.
• Pre-mortem on cutover - 'it is month 12 and the migration failed; why?' This is chosen deliberately because the team is anchored on the current plan and a forward-looking brainstorm will keep restating it.
• Prompt lists / checklists by category - as a completeness net at the end, not as the primary source. They generate plausible-sounding risks that teams will not challenge, so they run last.

What I would not do: run another general brainstorm with the same seven people and call it re-identification.

Every entry gets structure: cause → uncertain event → effect on an objective, plus owner, trigger, and affected WBS element.

Metalanguage:

As a result of [cause], [uncertain event] may occur, which would lead to [effect on cost/schedule/quality/compliance].

Worked rewrite:

• Before: 'Vendor may not deliver on time.'
• After: 'As a result of the vendor's integration team having no prior deployment on this platform, acceptance testing of interface 3 may overrun, leading to a three-week delay to cutover and loss of the negotiated window with the three application owners.'

Why each field earns its place:

• Cause separated from the risk lets you design a preventive response that attacks the source (e.g., vendor platform certification before testing starts) instead of only a contingent response.
• Effect separated from the risk lets you map the entry onto the schedule or cost model. Without an effect, quantitative analysis is impossible and the risk can only ever be a colour.
• Trigger / early warning is what makes monitoring possible - name the observable that tells us it is happening (e.g., interface 3 test pass rate below 80% at week 20).
• Risk owner is the accountable person, not the person doing the mitigation action.
• Affected WBS/activity links the register to the plan; a risk attached to nothing is a risk nobody acts on.

Deduplicate by cause, not by wording. 'Scope creep' appearing four times under four labels is one risk with four symptoms, or four distinct causes with different responses. Merging by wording hides both possibilities.

Sufficiency is a set of agreed exit criteria in the risk management plan, tested and reported - never a row count or the fact that a meeting occurred.

Tests I would apply:

1. Coverage: every RBS category and every contracted WBS element has at least one considered entry, or an explicit 'none identified' with a stated rationale. Silent absence is the failure mode.
2. Structure: every risk has cause, uncertain event, effect, owner, and - for anything above threshold - a trigger.
3. People: all three application owners and both replacement leads have been interviewed. Those five conversations are where the unregistered risk lives.
4. Reconciliation: the assumption log has been tested against the schedule - cutover window, lease expiry in month 11, vendor resourcing.
5. Saturation: a further session with a different mix of people produces few new risks and mostly restatements of existing ones. Diminishing returns, evidenced.
6. Downstream readiness: the top risks each have an approved response and an owner, because identification that produces nothing actionable has not finished its job.

What I say to the PM: identification is not a phase that closes; it is sufficient for a decision. Here, sufficient to baseline the schedule and to take the cutover plan to the application owners. It reopens at each phase gate and on every change to scope or interfaces.

What I refuse as evidence: 'the register is full', 'we held the workshop', or the number 58.