Prompt
You are a risk-management assistant for a project manager. Based only on the project details I provide, help me build a first-draft risk register. Be specific to this project — no generic filler risks.

Project summary and objectives: {{project_summary}}
Scope, constraints, and timeline: {{scope_constraints}}
Known dependencies (vendors, teams, approvals, systems): {{dependencies}}

Produce a table with columns: Risk (stated as cause -> risk -> consequence) | Category | Likelihood (H/M/L) | Impact (H/M/L) | Suggested mitigation | Suggested owner role.

Rules:
- Base every risk on the information I gave you. Where a risk depends on an assumption, state the assumption explicitly in a separate "Assumptions I'm making" list rather than treating it as fact.
- Prioritize dependency, sequencing, integration, approval, and resource-bottleneck risks over vague threats.
- Mark all Likelihood and Impact ratings as "DRAFT — validate with the team." Do not present them as measured probabilities.
- Do not invent historical data, benchmarks, or statistics. If you would need data I did not provide, say so.
- End with 3-5 questions whose answers would materially change the register.

Fill in your details and the prompt updates live — then copy.

What you get back (excerpt)

Risk: Sales ops data cleanup slips -> dirty records migrate -> users lose trust in the new CRM. Category: Data / dependency | Likelihood: M (DRAFT — validate) | Impact: H (DRAFT — validate) Mitigation: Lock a cleanup deadline two weeks before migration; sample-audit before cutover. Suggested owner: Sales Ops Lead Assumptions I'm making: The security review runs in parallel, not after, data cleanup. Questions that would change this register: - Is there a rollback plan if migration fails at cutover? - Who signs off that data quality is "good enough" to migrate?

The full workflow

  1. Feed the prompt your real project summary, constraints, and known dependencies
  2. Review each suggested risk for relevance and delete generic ones that do not apply
  3. Validate every likelihood and impact rating with the team and any historical data — do not accept the draft ratings
  4. Assign real owners, load the register into your tool, and review it on a set cadence

Watch out for

AI-assigned likelihood and impact are guesses, and the model can miss the real chokepoint or invent an irrelevant one. Treat the register as a starting point to pressure-test with the team and past-project data — never route AI risk flags straight into decisions or board reporting without human validation.

Do not paste confidential architecture, vendor contracts, or client-identifying detail into a consumer AI tool. Describe the project in general terms or use an approved enterprise account.

Where this comes from

Every use case on this site is grounded in real reports from working project managers — not invented by us.

More AI use cases for project managers

← All 6 use cases: How Project Managers Use AI