What's the difference between the SWOT and the risk register?

The SWOT is a snapshot — a structured sort of strengths, weaknesses, opportunities, and threats at one point in time. The risk register takes the weaknesses and threats that could actually derail the initiative and turns each into a tracked, owned item with likelihood, impact, and mitigation. The SWOT is the analysis; the register is the ongoing tracker.

How do I stop the risk register from just being written once and forgotten?

Give it a review-by date in the document itself, and when you revisit, ask Claude to diff the new pass against the last saved version rather than regenerating from scratch — what's resolved, what's changed, what's new. The habit of reopening it, not the initial write-up, is what keeps it alive.

What if I don't know who should own a risk?

Leave it blank and treat that blank as the most urgent thing on the register — an unowned risk isn't being managed by anyone, no matter how well-described it is. Chase the real name before the register is considered complete, the same rule as the requirements doc.

Can Claude tell me how likely or severe a risk actually is?

It can propose a starting estimate from your notes, but likelihood and impact are judgment calls that belong to people who've lived through the process — treat Claude's scores as a draft to sanity-check with the actual stakeholder or team, not a measurement to accept as-is.

Turn scattered concerns into a SWOT and a living risk register

when to reach for this

By the time an initiative is worth a business case, there's already a scattered pile of concerns about it — a worried Slack thread, a stakeholder's offhand comment, a note from a similar project that went sideways. Left scattered, those concerns get raised once in a meeting and forgotten. A SWOT organizes them into strengths, weaknesses, opportunities, and threats grounded in the requirements doc; the risk register turns the threats and weaknesses into named, owned, mitigated items that get checked again next month, not filed away. This runs in Claude Desktop — gather the scattered notes into one place and talk it through.

gather this first

Your requirements.md (and gap-analysis.md if you've run it) — the SWOT is grounded in what the initiative is actually trying to do, not a generic brainstorm.
The scattered concerns themselves — meeting notes, Slack exports, emails, a prior post-mortem — whatever half-formed worries exist about this initiative right now.
If this is a revisit rather than a first pass: the last saved risk-register.md, so Claude updates it instead of starting over.

the workflow

Pour the scattered notes into a first-draft SWOT

Open the requirements doc and every scrap of notes you have in Claude Desktop, and ask for a first-pass SWOT. The point of this step is getting everything out of scattered form, not getting it perfect.

you ask

Read requirements.md and these notes: [paste meeting notes, Slack messages, emails]. Sort everything into a SWOT for this initiative — strengths, weaknesses, opportunities, threats. Use only what's actually in the notes or reasonably inferred from the requirements doc; don't invent generic business risks that aren't grounded in what I gave you.

what you get back A four-quadrant SWOT with each item traced to something real — "Weakness: no backup approver for refunds (from gap-analysis.md). Threat: Finance flagged budget concerns in the Oct 3 planning notes." Nothing generic like "market competition" unless it's actually in your notes.

A SWOT full of generic business-school entries is worthless. If Claude proposes something you can't trace to a source, ask where it came from or cut it.
Stress-test the SWOT for gaps and contradictions

A first pass usually has blind spots — strengths that are really assumptions, threats nobody's said out loud yet. Push on it before moving to risks.

you ask

Review this SWOT critically. Which strengths are actually just assumptions we haven't verified? Are there any threats implied by the requirements doc or gap analysis that nobody's raised yet but should be on here? Flag anything that contradicts something else in the notes.

what you get back A short critique — "Strength 'strong stakeholder buy-in' is actually just one email from Ops; Sales hasn't weighed in. Implied threat: gap-analysis.md flags no backup approver, which is also a threat to this initiative's timeline, not just a process gap." The SWOT gets sharper, not longer for its own sake.
Turn weaknesses and threats into a risk register

A SWOT sits still; a risk register moves. Convert each weakness and threat that could actually derail the initiative into a tracked risk with the four fields that make it actionable.

you ask

Now take every weakness and threat from the SWOT that could meaningfully derail this initiative, and turn each into a risk register entry with: a clear risk statement, likelihood (low/medium/high), impact (low/medium/high), a proposed owner, and a concrete mitigation. Leave the owner blank if you don't know who it should be — don't guess a name.

what you get back A table — "Risk: refund approval has no backup, causing multi-day delays when the approver is out. Likelihood: high (happens most weeks). Impact: medium (delays, not lost revenue). Owner: [blank — needs Ops sign-off]. Mitigation: name a backup approver with the same authority."

Likelihood and impact are judgment calls — sanity-check them against anyone who's actually lived through the process, not just the notes.
Rank the register and flag what needs a decision now

Not every risk needs action today. Rank by likelihood × impact so the ones that could actually hurt this quarter surface above the ones that are theoretical.

you ask

Rank the risk register by likelihood × impact, highest first. For the top three, tell me plainly whether this needs a decision or a mitigation started now, or whether it's fine to monitor and revisit. Call out any risk with no owner as the most urgent gap to close before this moves forward.

what you get back A ranked list with a clear call — "Top risk: no backup refund approver — needs a decision this week, not a monitor-only item. Risk 2: Finance budget concern — monitor, revisit after next planning cycle. Two risks still have no owner — close that before circulating."
Save the register and set the revisit cadence

The register is only alive if someone reopens it. Save it, and build the revisit into the document itself so it doesn't quietly go stale.

you ask

Save this as risk-register.md, with the SWOT above it for context. Add a line at the top noting today's date and when this should next be reviewed. When I bring this back next month, compare it against today's version and tell me what changed, what's newly resolved, and what's newly emerged.

what you get back Claude shows the file as a diff before saving — you accept it, and risk-register.md now carries a review-by date plus standing instructions for how next month's revisit should work: a diff against this version, not a rewrite from scratch.

A risk register with no review date is the one that gets written once and never opened again. The date is what keeps it living.

make it your own

Revisiting an existing register: bring the last saved risk-register.md back into the chat and ask Claude to update it in place — "which risks are resolved, which likelihood/impact scores have changed, what's new since last time" — rather than regenerating a fresh SWOT every time.
High-stakes initiative: for something with real budget or reputational exposure, have Claude argue the threats from a skeptic's point of view first — "what would someone trying to kill this project point to?" — before finalizing the SWOT, so the threats quadrant isn't softened by the room's optimism.
Cross-check against the gap analysis: if you've run Find the gaps between today and the target state, feed gap-analysis.md in directly — every unresolved gap is a candidate weakness or threat, and the register shouldn't quietly drop one that's already been named elsewhere.
Bilingual circulation: if a risk owner reads Arabic, ask Claude to author the risk statement and mitigation in Arabic for that stakeholder directly, rather than machine-translating the English register — a risk mitigation is exactly the kind of instruction that needs to land precisely.

watch out for

A risk with no owner isn't tracked, it's just written down. Resist the pull to fill every blank with a plausible-sounding team name — an unowned risk is the most important thing the register should surface, not hide.
Likelihood and impact scores are hypotheses, not measurements. Claude proposes them from what's in the notes; the people closest to the process should sanity-check them before the ranking drives any real decision.
A SWOT with no source trace is a brainstorm, not an analysis. Every quadrant entry should point back to something real — a requirement, a gap, an actual note — or it's noise dressed up as insight.
"We did a SWOT once" is not risk management. The register's value is in the revisit — a document that never gets reopened is exactly as useful as the scattered notes it replaced. Set the review date and actually keep it.

you'll end up with A SWOT grounded in `requirements.md` and real notes, plus a `risk-register.md` where every risk carries likelihood, impact, an owner (named or explicitly flagged as missing), and a mitigation — ranked by what actually needs a decision now, with a built-in revisit cadence so it stays a living document instead of a slide shown once and forgotten.

Questions people ask

What's the difference between the SWOT and the risk register?: The SWOT is a snapshot — a structured sort of strengths, weaknesses, opportunities, and threats at one point in time. The risk register takes the weaknesses and threats that could actually derail the initiative and turns each into a tracked, owned item with likelihood, impact, and mitigation. The SWOT is the analysis; the register is the ongoing tracker.
How do I stop the risk register from just being written once and forgotten?: Give it a review-by date in the document itself, and when you revisit, ask Claude to diff the new pass against the last saved version rather than regenerating from scratch — what's resolved, what's changed, what's new. The habit of reopening it, not the initial write-up, is what keeps it alive.
What if I don't know who should own a risk?: Leave it blank and treat that blank as the most urgent thing on the register — an unowned risk isn't being managed by anyone, no matter how well-described it is. Chase the real name before the register is considered complete, the same rule as the requirements doc.
Can Claude tell me how likely or severe a risk actually is?: It can propose a starting estimate from your notes, but likelihood and impact are judgment calls that belong to people who've lived through the process — treat Claude's scores as a draft to sanity-check with the actual stakeholder or team, not a measurement to accept as-is.