Manu's Vault

Risk Storming Process

4 min readStatus:Seedling

Core Idea

The risk storming process is a structured three-phase workflow (identification, consensus, mitigation) that guides teams through systematically discovering, validating, and addressing architectural risks in collaborative workshop sessions.

Process vs Technique: While Risk-Storming defines the collaborative technique itself, the risk storming process provides the specific facilitation steps and workflow that make these sessions effective:

  • Without clear process: Sessions devolve into unfocused brainstorming or get dominated by the loudest voices
  • With structured process: Ensures comprehensive risk coverage, democratic participation, and actionable outcomes

Three-Phase Process

The process consists of three distinct phases, each with specific objectives and facilitation techniques:

Phase 1: Individual Identification (Silent Brainstorming)

Activity: Participants individually and silently identify potential risks:

  • Use sticky notes or digital collaboration tools
  • Each person considers: “What could go wrong with this architectural approach?”

Why silent and individual?:

  • Prevents groupthink
  • Ensures quieter team members contribute their perspectives before discussion begins

Risk dimensions to consider:

  • Technical failures: Service timeouts, data corruption
  • Operational concerns: Deployment complexity, monitoring gaps, performance degradation
  • Organizational challenges: Skill gaps, communication overhead, team dependencies
  • Business impacts: Scalability limits, vendor lock-in, maintenance costs

Facilitation:

  • Time limit: Typically 10-15 minutes
  • Encourage participants to think broadly across categories rather than self-censoring early ideas

Phase 2: Consensus Building (Group Evaluation)

Activity: Team collectively reviews all identified risks, one by one

Discussion questions for each risk:

  • Is this a genuine concern?
  • How likely is it?
  • What would the impact be if it occurred?

Goal: Validate risks and establish shared understanding, not solve them yet

Priority signals:

  • Risks that multiple people independently identified receive particular attention
  • Signals a broadly-recognized concern

Output:

  • Facilitator helps group plot validated risks on a Risk-Matrix (probability vs. impact)
  • Creates visual prioritization framework
  • Low-probability, low-impact risks: Acknowledged and set aside
  • High-probability or high-impact risks: Move forward to mitigation planning

Phase 3: Mitigation Planning (Risk Response Strategies)

Activity: For highest-priority risks identified in phase 2, develop specific mitigation strategies

Four response categories:

  1. Accept: Acknowledge the risk but take no action if probability and impact are sufficiently low
  2. Avoid: Change the architectural approach to eliminate the risk entirely
  3. Mitigate: Reduce either likelihood or impact through:
    • Architectural guardrails
    • Redundancy
    • Monitoring
    • Design changes
  4. Transfer: Shift risk through architectural decisions like:
    • Vendor selection
    • Insurance
    • Service-level agreements

Documentation:

  • Each high-priority risk receives a documented mitigation plan:
    • Specific actions
    • Owners
    • Success criteria
  • Mitigation plans often become part of Architecture-Decision-Records for the architectural decision being evaluated

Session Logistics:

  • Duration: Typically 60-90 minutes for a significant architectural decision
  • Facilitator role (critical):
    • Maintaining time discipline
    • Ensuring balanced participation
    • Preventing premature solution-jumping in phases 1-2
    • Driving toward concrete action items in phase 3

Why This Matters

A clear process transforms risk storming from a vague “let’s discuss risks” meeting into a structured discovery activity with measurable outputs. Teams that follow this process consistently catch risks that would otherwise surface only in production, when mitigation costs have increased by orders of magnitude. The process also builds shared ownership—because risks were collaboratively identified and mitigation was collectively designed, the entire team commits to monitoring and responding to risks as the system evolves.

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks