Risk registers that nobody updates become decorative — the team writes “monitor” next to every row and never revisits. These prompts force you to name risks specifically, score likelihood and impact honestly, decide between mitigate / accept / transfer / avoid, and surface the dependency, scope, and stakeholder risks that registers usually miss. Pair with project planning prompts when you’re still scoping the plan itself.
Best for
- Project kickoff risk register
- 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) from issues (already happening).
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".
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 × 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 (paste), pick one: 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}
8. Pre-launch risk review
T-14 days before launch of {project}. Review register (paste): (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 (paste) against reality: (1) which risks materialized, (2) which mitigations actually worked, (3) which risks we missed entirely, (4) which "high" risks were actually fine. Output 5 learnings to seed the next register.
{paste}
Common mistakes
- Vague risks like “schedule risk” — name the specific task, dependency, or person
- Likelihood and impact set by gut 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 response now)
- Skipping the pre-mortem because the team is optimistic — that’s exactly when you need it
Related
- Project planning prompts
- Workflow bottleneck analysis prompts
- Weekly report prompts
- Sop drafting prompts
- Productivity & Office Prompts hub
Tags: #Prompt #Productivity #Risk #Project