Risk registers that nobody updates become decorative: the team writes “monitor” next to every row and never revisits. These 12 prompts force you to name risks specifically, score likelihood and impact honestly, pick one of the four PMBOK responses (mitigate / accept / transfer / avoid), and surface the dependency, scope, and stakeholder risks that registers usually miss. Pair them with project planning prompts when you are still scoping the plan itself.
TL;DR
- Paste a project summary into prompt 1 to seed a six-category register, then run prompts 2–6 to attack the categories a flat register hides (failure modes, dependencies, schedule, scope, stakeholders).
- Prompt 7 is the one that earns its keep: it forbids the lazy “monitor” and forces an owner plus a date on every row.
- The pre-mortem (prompt 2) is grounded in real research — imagining the project has already failed (“prospective hindsight”) raised the accuracy of risk identification by about 30% in the original 1989 study (Mitchell, Russo & Pennington), and Gary Klein formalized it in a 2007 Harvard Business Review piece.
- For pasting a whole project doc or a long register, use a model with a 1M-token context: Claude Opus 4.7 or Gemini 3.1 Pro (both 1M as of June 2026). For strict adherence to a fixed table format, Opus 4.7 follows column instructions most reliably.
Best for
- Project kickoff risk register (or the broader RAID log: Risks, Assumptions, Issues, Dependencies)
- Mid-project re-assessment
- Pre-launch GO / NO-GO review
- External dependency and vendor risk
- Stakeholder and communication risk planning
1. Risk register seed
Project: [project]. Generate an initial risk register across 6 categories:
technical, dependency, schedule, scope, stakeholder, regulatory. For each:
2-3 specific risks, likelihood (L/M/H), impact (L/M/H), owner, mitigation.
Distinguish risks (uncertain future events) from issues (already happening).
Output as a table.2. Pre-mortem
Project: [summary]. Imagine it failed 6 months from now. Write a 200-word
pre-mortem: what went wrong, what we should have done differently, which
early signals we missed in week 2. Surface the non-obvious failure modes,
not just "the timeline slipped".The pre-mortem flips the question from “what could go wrong” to “what did go wrong,” which is exactly why it works: speaking in the past tense about a definite failure is the prospective-hindsight effect that beats a normal brainstorm. Run it before the team’s optimism hardens into groupthink.
3. Dependency risk audit
List external dependencies for [project] (other teams, vendors, infra, APIs).
For each: (a) what we need from them, (b) likelihood of delivering on time,
(c) what we do if late, (d) is there a backup. Don't treat any dependency as
guaranteed.4. Schedule risk decomposition
Project timeline: [timeline]. Identify the 3 schedule risks most likely to
cause slip: critical-path tasks, unfamiliar tech, dependencies, holidays,
planned PTO. For each: how much buffer to add + the early-warning signal that
means "act now".5. Scope-creep risk
Audit scope of [project]: what's been added since kickoff? For each addition:
(1) Is it essential to the original goal? (2) What gets cut to fit?
(3) Who approved? Output a scope-discipline note plus 3 phrases to push back
on future additions.6. Stakeholder-risk map
List stakeholders for [project] by influence x support:
(a) high influence + supportive (engage),
(b) high influence + opposed (mitigate),
(c) high influence + neutral (convert),
(d) low influence (inform).
For each in (b) and (c), name the specific intervention and owner.7. Mitigate / accept / transfer / avoid
For each risk in my register (pasted below), pick exactly one response:
MITIGATE (concrete action + owner + date), ACCEPT (one-line rationale +
monitoring date), TRANSFER (insure / outsource / contract clause),
AVOID (descope). No row may stay as bare "monitor" without a date.
[paste register]This is the prompt that turns a list into a plan. Use a simple decision rule to sanity-check the model’s choices:
| Likelihood | Impact | Default response |
|---|---|---|
| High | High | Avoid or mitigate |
| High | Low | Mitigate or accept |
| Low | High | Transfer (insure, outsource, clause) or mitigate |
| Low | Low | Accept (with a review date) |
Acceptance is a legitimate choice, not a cop-out — but an accepted risk still needs a named owner and a date to revisit it.
8. Pre-launch risk review
T-14 days before launch of [project]. Review the register (pasted below):
(1) Which risks resolved? (2) Which got worse? (3) Any new risks emerged?
Output a GO / DELAY / CONDITIONAL recommendation with the 1-2 conditions that
would flip the call.
[paste]9. External-vendor risk
Vendor [vendor] is delivering critical service [service]. Build a risk profile:
(1) SLA history, (2) is this a single point of failure, (3) contractual
remedies if they fail, (4) backup vendor or DIY fallback, (5) off-boarding
plan. Output a risk score and the single most overdue action.10. Communication risk
Audit project comms for [project]: (1) stakeholders who haven't heard from us
> 2 weeks, (2) updates that under-state risk to look good, (3) decisions made
in DMs not recorded anywhere durable. Output a fix list with owners.11. Risk-to-leadership memo
Write a 200-word risk memo for executives on [project]: (1) top 3 risks named
concretely, (2) what we're doing about each, (3) the specific decisions we
need from them, (4) when we'll update next. No hedging, no buried asks.12. Risk-debrief retrospective
Project [project] complete. Review the register (pasted below) against reality:
(1) which risks materialized, (2) which mitigations actually worked, (3) which
risks we missed entirely, (4) which "high" risks turned out fine. Output 5
learnings to seed the next register.
[paste]How to run these well
- Feed the AI real context. A model cannot invent your critical path or your vendor’s SLA history. Paste the actual plan, timeline, or register text — these prompts are scaffolding, not a substitute for project knowledge.
- Pick the model for the job. For one paste of a long register or a full project doc, use a 1M-token model: Claude Opus 4.7 or Gemini 3.1 Pro (both 1M as of June 2026). ChatGPT Plus carries roughly 320 pages of in-app context; the full 1M window is only on the $200 Pro tier. For locking the model to a fixed table format, Opus 4.7 adheres to column instructions most reliably.
- Run the register and the RAID log together. A risk register tracks risks only; a RAID log adds Assumptions, Issues, and Dependencies. Unvalidated assumptions and untracked dependencies sink as many projects as named risks. Review both weekly, not once at kickoff.
- Treat the output as a draft. The AI’s likelihood/impact scores are starting guesses. Re-score them with the people who actually own the work before anything reaches a stakeholder.
Common mistakes
- Vague risks like “schedule risk” — name the specific task, dependency, or person.
- Likelihood and impact set by gut once and never revisited as facts change.
- Every risk gets “mitigate” — accepting risk is a legitimate, often correct choice.
- No owner per risk, so the register has no one to escalate to.
- Confusing risks (uncertain future events) with issues (already happening, need a response now).
- Skipping the pre-mortem because the team is optimistic — that is exactly when you need it.
FAQ
Which AI model is best for risk analysis? For pasting a long register or whole project doc in one shot, use a 1M-token context model — Claude Opus 4.7 or Gemini 3.1 Pro (both 1M as of June 2026). Opus 4.7 follows a fixed table schema most reliably, which matters when you want consistent columns. Gemini 3.1 Pro leads on scientific reasoning benchmarks and is cheaper per token. ChatGPT Plus works for shorter registers but caps in-app context at roughly 320 pages.
Risk register or RAID log — which should I use? A risk register tracks risks only. A RAID log tracks Risks, Assumptions, Issues, and Dependencies in one place. On small projects a register is enough; on larger or cross-team work, keep the detailed register and reference it inside a RAID log so assumptions and dependencies stay visible too.
How is a risk different from an issue? A risk is an uncertain future event you can still plan around. An issue is already happening and needs a response now. Prompt 1 forces the AI to separate them, because mixing the two is the fastest way to make a register useless.
Does the pre-mortem actually work, or is it just a brainstorm? It outperforms a normal brainstorm. Imagining the project has already failed (“prospective hindsight”) raised the accuracy of risk identification by about 30% in the original 1989 study, and Gary Klein turned it into a standard practice in a 2007 Harvard Business Review article. The trick is the past tense — “it failed, here’s why” generates more concrete causes than “what might go wrong.”
Should I let AI assign the likelihood and impact scores? Use them as a first draft only. The model has no inside knowledge of your team, vendors, or history, so re-score every row with the people who own the work before the register goes to anyone who makes decisions on it.
Related
- Project planning prompts
- Workflow bottleneck analysis prompts
- Weekly report prompts
- SOP drafting prompts
- Meeting notes prompts
- Productivity & Office Prompts hub
Tags: #Prompt #Productivity #Risk #Project