Risk Categorization

Risk technique · See it on the map

Guide only — Sorting risks into categories is a judgment call.

Grouping identified risks by source or area so patterns become visible instead of staying a flat list.

When to use it

Once the register has enough entries that scrolling through it no longer shows you anything: a dozen or more risks, or a project with several distinct workstreams. Categorizing surfaces concentration you would otherwise miss, such as half your open risks tracing back to one vendor or one unproven technology choice.

When to avoid it

On a short list of risks a person can hold in their head at once — the categories add bookkeeping without adding insight. Also avoid inventing a deep, formal risk breakdown structure before you have enough risks to populate more than a couple of its branches; an elaborate taxonomy with three risks in it is effort spent on the wrong thing.

Steps

1. List every open risk currently in the register.
2. Pick a small set of categories that matches how your team actually thinks about the project — by source (technical, external, organizational, project management) or by affected area (a specific workstream, vendor, or deliverable).
3. Tag each risk with one primary category; note a second if it genuinely spans two.
4. Count and total exposure by category.
5. Look for concentration: one category carrying most of the exposure, or most of the count, is the signal you were looking for.
6. Feed that concentration back into planning — a shared root cause across several risks is often cheaper to address once than risk by risk.

What it produces

• Risks grouped into a small number of named categories.
• A per-category count and exposure total.
• A short written note on where the concentration is and why it matters.

Common pitfalls

• Choosing categories that sound thorough (a full PMBOK-style RBS) but that the team never actually uses when a new risk shows up, so tagging drifts to 'other' and the structure stops meaning anything.
• Treating the category count as the finding instead of using it to ask why one category dominates.
• Recreating this by hand every time instead of noticing Driftless has no category field on the risk record — there is nowhere to store the tag itself yet, so this stays a spreadsheet or notebook exercise layered on top of the register, not something the tool tracks for you.

Worked example

A mid-size warehouse automation project has nineteen open risks. Sorted by source, eight trace back to the conveyor vendor's late deliveries, three to unfamiliar sensor firmware, and the rest are scattered. The PM stops treating the eight vendor risks as independent items and instead escalates one conversation with the vendor's account manager about their delivery schedule — addressing the root cause instead of eight symptoms.

Source

• PMBOK-6 §11.3.2.5

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.