Quick answer: an AI prompt for risk assessment needs three things: your project brief, the risk categories to cover, and a rule not to invent details. A pre-mortem prompt has to do something different: assume the project has already failed, write the reasons in the past tense, and keep each person's list independent. The 20 prompts below, from risk identification to the recurring review, follow that split.
Run a pre-mortem now. Paste your plan into this prompt (it is prompt 10 below, built on Gary Klein's 2007 method). The two things that make it work: the project is stated as already failed, and the reasons come out as settled facts, not hedges. If you have a team, have each person write their own list before anyone reads theirs aloud.
Act as a facilitator running a project pre-mortem, based on Gary Klein's method (Harvard
Business Review, September 2007).
Here is our project plan: [paste plan].
Assume this project has already failed, one year from now. Generate 10-15 plausible, specific
reasons it failed — not generic risks, but reasons a real team member might have been
reluctant to say out loud during planning (a political dependency, an unstated assumption
about scope, a skill gap no one named).
Write each reason as a settled fact ("The project failed because...") not a hedge
("The project might fail if...").
Jump to: Identify (1-5) · Score (6-9) · Pre-mortem (10-14) · Mitigate (15-18) · Review (19-20). For the planning side of the same project, see 35 AI prompts for project planning and scoping, which links back here for the full risk and pre-mortem versions.
Why does a risk register usually die within a month of being built?
A risk register dies when it becomes a one-time deliverable instead of a living document someone is accountable for reopening. Naming a risk can read as pessimism, scoring it honestly takes longer than scoring it politely, and nobody wants to book a meeting about what might still go wrong on a project that looks fine. AI lowers the friction on the mechanical parts (the first list, the scoring table, the facilitation script) so your attention goes to the judgment calls. Every prompt below that asks for a number also tells the model where the number must come from.
Five things have to happen for a register to stay useful, and the prompts follow them in order:
- Identify risks honestly, including the awkward ones (prompts 1-5).
- Score them without guessing (prompts 6-9).
- Pre-mortem the plan before it is locked (prompts 10-14).
- Mitigate with an owner and a trigger per risk (prompts 15-18).
- Review on a schedule that survives a busy quarter (prompts 19-20).
Skip one and the others do not hold up: a scored register with no owner is a longer spreadsheet, and a pre-mortem never converted into register rows is a good meeting with no lasting output. If you do not yet have a register, a starting set of columns is: ID, risk, category, likelihood (1-5), impact (1-5), score, owner role, mitigation, trigger, status, date last reviewed.
1. Initial risk sweep from a project brief
Here is my project brief: [paste your brief, scope, timeline, and team].
List every risk you can identify across these categories: technical, schedule, budget,
external/market, and people/team. For each risk, write one sentence stating what could go
wrong and one sentence stating why, given what's actually in my brief above.
Do not invent details about my project that aren't in the brief — if a category has no
obvious risk from what I gave you, say so instead of manufacturing one.
2. Category-by-category deep sweep
Focus only on [pick one: technical / schedule / budget / external / people] risk for this
project: [paste brief].
List 5-8 risks specific to this category, ranked from most to least likely given what you know
about projects of this type and size.
For each, name the earliest point in the project where this risk would first become visible,
so I know what to watch for and when.
3. The devil's-advocate stress test
Here is my project plan: [paste plan].
Act as a skeptical reviewer whose job is to find the plan's weakest assumption, not to be
encouraging. Identify the three assumptions this plan depends on that would be most damaging
if they turned out to be wrong.
For each, state what evidence I actually have for the assumption today, versus what I am
simply hoping is true.
4. Stakeholder-specific risk elicitation
Here is my project plan: [paste plan].
Answer as a skeptical [finance lead / legal counsel / operations manager] reviewing this plan
for the first time. What are the three risks a person in that specific role would flag that a
project manager might not think to look for?
Stay strictly inside that role's usual concerns — don't produce generic risks a non-specialist
would already list.
5. Dependency and single-point-of-failure scan
Here is my project's list of dependencies: [paste vendors, tools, team members, or other
projects this one depends on].
For each dependency, state what happens to my timeline if it fails, is delayed, or becomes
unavailable, using only the information I gave you above.
Flag any dependency that has no backup or workaround mentioned in my list — that is the
single point of failure, not the ones I already have a plan B for.
What should AI actually do in a likelihood/impact score, and what should it refuse to invent?
An AI model can organize, normalize, and compare scores you give it reasoning for. It cannot generate a real probability out of nothing, because it has no access to your project's actual base rates, so a fluent-sounding "70% likely" from a model is a guess dressed as a measurement, and it will look identical to a real one until something goes wrong. The fix is the same one that works for any AI-assisted numeric task: you supply the judgment, the model supplies the structure.
This matters more here than in most scoring exercises because the two biases that already distort human risk scoring — optimism about your own plan, and reluctance to rank a colleague's pet initiative as high-risk — don't disappear just because a model is doing the arithmetic. A model asked to "score this risk" with no evidence supplied will happily produce a number anyway, and that number will carry the same false confidence a human's unexamined gut estimate does, just with better formatting. The rubric below exists to force the evidence question before the number gets written down, not after.
| Score | Likelihood means | Impact means |
|---|---|---|
| 1 | Very unlikely — no precedent on this or similar projects | Negligible — absorbed without anyone noticing |
| 2 | Unlikely — would need an unusual chain of events | Minor — a short delay or small budget line |
| 3 | Possible — has happened before on similar work | Moderate — visible schedule or scope impact |
| 4 | Likely — a known weak point in this specific plan | Major — threatens a deadline, budget, or deliverable |
| 5 | Near-certain absent a specific change | Severe — threatens the project's viability |
To turn two scores into a priority, a simple 3x3 grouping is enough. This is an editorial convention, not a standard: set your own thresholds, and define what likelihood and impact mean for your project before you use it.
| Impact 1-2 (low) | Impact 3 (medium) | Impact 4-5 (high) | |
|---|---|---|---|
| Likelihood 4-5 (high) | Review | Act | Act now |
| Likelihood 3 (medium) | Monitor | Review | Act |
| Likelihood 1-2 (low) | Monitor | Monitor | Review |
6. Grounded likelihood/impact scoring
Here is my raw risk list: [paste risks from the identification prompts above].
Score each on a 1-5 likelihood scale and a 1-5 impact scale, using this rubric: [paste the
table above, or your own version of it].
For every score, state the one piece of evidence from my project that justifies it. If you
have no specific evidence for a score, assign a 3 (possible/moderate) as the default and say
so explicitly rather than picking a more dramatic number.
Illustrative output of prompt 6 (a fictional project, written to show the shape of a good answer rather than captured from a real run). Project: moving a customer database to a new CRM in 12 weeks. Notice that every score cites evidence from the brief, and the unsupported one defaults to 3:
| Risk | Likelihood | Impact | Evidence from the brief |
|---|---|---|---|
| Data mapping errors lose fields | 4 | 4 | The brief says two legacy systems use different field names for customer status |
| Key analyst unavailable in weeks 6-8 | 3 | 4 | The brief names one analyst as sole owner of the export scripts and mentions planned leave |
| Vendor onboarding is late | 3 | 3 | No specific evidence given, so the default of 3 is assigned |
The model organises; you supply the numbers. If a score has no evidence behind it, treat it as a question for your team, not a result.
7. Scored list to prioritized top 10
Here is my scored risk list (risk, likelihood, impact): [paste table].
Multiply likelihood by impact for each and rank them highest to lowest.
Output the top 10 only, as a table, and add one column stating why each risk ranked where it
did relative to the one above and below it.
8. Calibration and consistency check
Here is my scored risk list: [paste table with reasoning per score].
Check this list for internal consistency: flag any two risks that received similar scores but
have very different-looking reasoning behind them, and any risk whose stated reasoning
doesn't actually support the number given to it.
Do not re-score anything yourself — only flag the mismatches for me to review.
9. Plain-English narrative for a non-technical stakeholder
Here is my prioritized risk table: [paste top 10 with scores].
Write a 150-word plain-English summary for a stakeholder who has never seen a likelihood/
impact matrix. State the top 3 risks by name, what would trigger them, and what we are doing
about each, in one sentence per risk.
No jargon, no scoring methodology — assume they only care what could go wrong and what we're
doing about it.
What is a pre-mortem, and where did it actually come from?
The pre-mortem is not an unattributed piece of project-management folklore. Cognitive psychologist Gary Klein published it as "Performing a Project Premortem" in the September 2007 issue of Harvard Business Review, building on 1989 research by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, on a phenomenon Klein calls "prospective hindsight—imagining that an event has already occurred", which the researchers found increases the ability to correctly identify reasons for future outcomes.
The two mechanics worth keeping intact when you translate this into an AI prompt: everyone writes their own list independently before anyone speaks, so no one's answer anchors anyone else's, and the framing is "this has failed" rather than "this might fail," a settled fact people are explaining, not a hypothetical they have to defend raising. Lose either mechanic and you get a regular risk-review meeting with extra steps — the independence stops the loudest voice in the room from setting everyone else's answer, and the past-tense framing is what actually gives the reluctant reason permission to be said out loud in the first place.
10. Full pre-mortem facilitator prompt
Act as a facilitator running a project pre-mortem, based on Gary Klein's method (Harvard
Business Review, September 2007).
Here is our project plan: [paste plan].
Assume this project has already failed, one year from now. Generate 10-15 plausible, specific
reasons it failed — not generic risks, but reasons a real team member might have been
reluctant to say out loud during planning (a political dependency, an unstated assumption
about scope, a skill gap no one named).
Write each reason as a settled fact ("The project failed because...") not a hedge
("The project might fail if...").
11. Round-robin capture and consolidation
Here are independent pre-mortem lists from each team member: [paste each person's list
separately].
Consolidate these into one list, removing exact duplicates but keeping every distinct reason,
in the order Klein's method calls for: read one reason at a time from each list, cycling
through people, until everything is captured.
Flag any reason that appears on only one person's list — those are often the ones people were
most reluctant to say, and the ones a facilitator should double-check got a fair hearing.
12. Solo pre-mortem for a one-person team
I'm running this project without a team to pre-mortem it with. Here is my plan: [paste plan].
First, generate my own list: assume the project failed, and list every reason I can think of,
in first person, as if I'm explaining what went wrong to someone.
Second, take the opposite side: act as a colleague who wasn't in the planning and has no
stake in the plan looking good. What did my list miss, and what assumption in my plan would
you personally be most reluctant to challenge if you worked for me?
13. Surfacing the reason nobody wants to say
Here is our project plan and team context: [paste plan and any relevant org context — reporting
lines, recent history, politically sensitive dependencies].
Assuming this project fails, what is the single most likely reason that would be uncomfortable
for someone on this team to say out loud in a meeting — a dependency on a person who's
overcommitted, a decision nobody wants to revisit, a deadline everyone privately doubts?
State it plainly, as something a facilitator should ask about directly rather than wait for
someone to volunteer.
14. Pre-mortem findings into new register rows
Here is our consolidated pre-mortem list: [paste the reasons from the group exercise].
Convert each into a proper risk register row: risk name, category, likelihood (1-5, with your
reasoning), impact (1-5, with your reasoning), and a suggested owner role (not a named person —
just the function, e.g. "engineering lead").
Flag any pre-mortem reason that doesn't map cleanly to a single risk — some may need splitting
into two.
How do you turn a scored risk list into an actual mitigation plan?
A score without an owner and a trigger is a paragraph, not a plan. The step teams skip most often is deciding, in advance, what specific event would tell you a risk is starting to materialize; without that, "monitor it" means nobody notices until the risk has already become the problem. An owner with no trigger tends to check in only when something visibly breaks, which is the same failure mode as having no owner at all, just with someone to blame for it afterward.
For the plan around the register (work breakdown, estimates, dependencies), see AI prompts for project planning and scoping.
15. Owner, mitigation, and trigger per risk
Here is my top-10 scored risk list: [paste table].
For each risk, add three columns: a suggested owner role, one concrete mitigation action, and
a specific trigger — an observable event or metric that would tell us this risk is starting to
happen, not just a vague "if things go wrong."
Keep each mitigation action specific enough that someone could start it this week.
16. Contingency plan for high-severity risks
Here are our top 3 highest-scored risks: [paste risks, scores, and mitigation actions].
For each, write a short contingency plan answering: if the mitigation fails and this risk
fires anyway, what is our first move in the next 48 hours, and who makes that call?
Assume the mitigation didn't work — don't restate the mitigation plan itself.
17. Cost/effort-weighted mitigation prioritization
Here is my mitigation list with rough effort estimates: [paste risk, mitigation action,
estimated effort/cost to implement].
Rank these by the ratio of risk-reduction value to effort, and separate them into three
groups: do now, monitor and revisit next review, and accept as-is with no action.
Justify the "accept as-is" group specifically — that's the one worth double-checking.
18. Mitigation stress test
Here is our mitigation plan for this risk: [paste risk and its planned mitigation].
Act as a skeptic whose job is to find out how this specific mitigation could itself fail —
not new risks to the project, just ways this particular fix might not work as intended.
List the top 3 failure modes of the mitigation itself, and what would need to be true for each
one to happen.
How often should a risk register actually get reviewed, and what changes at each check-in?
The honest answer is a fixed cadence tied to your project's own rhythm rather than a universal rule: weekly for a fast-moving sprint, monthly for most other work, and always again immediately before a major milestone or launch, since that is exactly when a stale register does the most damage by giving false confidence. A register nobody has opened in six weeks is worse than no register at all in one specific way: it lets a team point at a document and believe the risks are handled, when the document is simply old.
19. Recurring review: diff against last time
Here is our risk register from the last review: [paste previous version].
Here is the current state of the project: [paste current status, recent events, and anything
that's changed].
Identify: which risks have grown more or less likely since last time and why, which appear
resolved and can be closed, and which new risks should be added given what's happened since
the last review.
Do not just re-list everything unchanged — flag only what's actually different.
20. Pre-decision gate check
We're about to [launch / ship to production / present to the board / sign the contract] on
[date]. Here is our current risk register: [paste register].
Do a quick pulse check: which of our top 5 risks has a trigger condition that's actually
present right now, based on what I've told you about current status: [paste current status]?
Flag only risks that are live right now, not the full list — this is a go/no-go check, not a
re-scoring exercise.
Should you trust an AI's risk score more than your own judgment?
No, and the twenty prompts above are built around that answer rather than around it. Every prompt that touches a number is written to ask the model for structure and reasoning, not for a probability it has no way to actually know. The same caution applies to the underlying model's tendency to fill a gap with a plausible-sounding answer rather than an honest "I don't know." Our explainer on why ChatGPT makes things up covers the mechanism in more depth (full post here), and the practical takeaway carries over directly here: a model will produce a confident-sounding likelihood score exactly as readily as a correct one, so every number that reaches your actual register needs to trace back to evidence you can name.
The pre-mortem is the one prompt in this set worth running even if you skip everything else. It costs one meeting, it is built on a named, dated, verifiable method rather than a folk technique, and it is specifically designed to surface the risk everyone already half-suspected but nobody had said out loud yet. To check a scored register before you rely on it, rubric-based prompting shows how to score output against criteria. For risk in a decision rather than a project, see using AI to make better decisions and prompting for architecture decision records; if you work as a consultant or analyst, best AI prompt tools for consultants and analysts is the related read. If your team already runs a PM workflow built around AI, the risk register slots in as one more artifact fed by the same persistent product context rather than a one-off document you paste a plan into once — the fewer times you retype the same project background before a prompt, the more likely the register actually gets kept current. Before you trust any output here past a first draft, it's worth running your own plan through the same kind of adversarial check our guide to red-teaming your own prompts walks through, and if part of your review cadence includes reporting risk status upward, the same no-spin discipline from our investor update prompts applies just as directly to a risk section as it does to a metrics section: state the risk plainly, before the reassurance, not after it.
Stop rewriting prompts. Start shipping.
Turn a rough idea into a structured prompt in one click, inside ChatGPT, Claude, Gemini and 40+ AI tools. 5 free prompts a day, no card. 4.8★ on the Chrome Web Store.
Create a free accountSave the pre-mortem prompt and the recurring-review prompt above: those two are the ones that actually determine whether this register is still alive in three months. The rest draft faster with a model in the loop. Whether every score and every "accepted risk" is actually true is still the judgment call that belongs to your team, not the model that helped you write it down. A register is only as honest as the meeting that built it, and the meeting is still yours to run.
By Nafiul Hasan — Founder of Prompt Architects.