Project Risk Register Prompt for PMs

What this prompt does

A project risk register prompt turns the facts a project manager already holds, the scope, the dates, who's on the team and what the work is waiting on, into a ranked list of what could go wrong before any of it has — each line with a signal you'd notice early, a mitigation, and a name. You supply the plan. The model supplies the structure, the ranking, and a list of the things it couldn't assess because you didn't tell it. It does not supply probabilities as percentages, a cost of failure, or risks about a project it hasn't been told about.

Ask a chat window to "list the risks for my project" and you get the same eight lines every project gets — scope creep, resource constraints, stakeholder misalignment, communication gaps. None of them is wrong. None of them is a risk you can act on Monday morning either, because none of them names a thing on your plan. The version worth having starts from your dependency list and works outward.

Two neighbours sit either side of this page. The project status report prompt looks backwards over the period that just ended and gives one line to "what's at risk." This page looks forward — before anything has slipped. The decision matrix prompt picks between options already on the table; the register is where those options tend to come from.

The prompt

Build a project risk register from the inputs below. Every risk must trace back to something I typed. Do not add risks about things I haven't described.

**Project, in two sentences:** [WHAT it delivers and WHO it's for]
**Key dates:** [START, GO-LIVE or DEADLINE, and any fixed milestones — say which dates can move and which can't]
**Team:** [EACH ROLE, their allocation (full time / 50% / joins in week N), and anyone leaving or on leave during the project]
**Dependencies:** [EVERYTHING the work waits on that the team doesn't control — a vendor, another team, a sign-off, a credential, a document. For each one, WHO owns it and WHEN it was promised]
**Assumptions the plan rests on:** [THINGS you're treating as true but haven't verified]
**Constraints:** [FIXED budget, fixed date, fixed scope — which one gives if something slips?]
**What's gone wrong on projects like this before:** [OPTIONAL — one line each, or "nothing I know of"]
**What failure looks like to the sponsor:** [ONE SENTENCE, in their words if you have them]

Output:
1. A risk register with 8–12 rows, ranked by exposure (impact and likelihood, both as High / Medium / Low with a one-clause reason — no percentages). Columns: ID · Risk statement · Likelihood · Impact and what it hits (date, cost, scope, quality) · Early warning signal · Mitigation · Fallback if it fires · Owner · Time frame (immediate = within 30 days, near-term = 30–90 days, far-term = beyond 90).
2. Write every risk statement in this form: "Given that [a condition from my inputs], there is a possibility of [the departure from plan], adversely impacting [the deliverable, date or team], which can result in [the consequence]." The condition must be a fact I gave you. Quote it. Keep cause, risk and effect in their own slots; don't merge them.
3. The three rows to act on this week, with the first concrete step for each.
4. A "can't assess" list: the risks you suspect but couldn't rank because an input was missing, stated as the question I need to answer.

Rules:
- Every early warning signal must be something a person could check by looking: a date passed, a reply not received, a number on a dashboard. "The team seems behind" is not a signal.
- Owners must be roles from my team input. If no listed role fits, write [OWNER NEEDED] and say why.
- No generic risks. If a risk would read the same on any project, either tie it to a specific input or leave it out.
- Thin inputs get a short register, not a padded one. Put what's missing in the "can't assess" list rather than inventing rows.
- Do not estimate costs, budgets, or the financial size of any consequence.

How to use it

1. Write the dependency list before anything else, with names and dates. Most of the register comes from this one input. "Waiting on the vendor" gives the model nothing to rank. "Sandbox credentials from Acme's onboarding team, promised for 3 October" gives it a condition, an owner to chase, and a date that can pass.
2. Read the conditions before you read the rankings. NASA's Risk Management Handbook defines the condition as "the current key fact-based situation," and the same test applies here: every condition should be a sentence you typed. One you didn't type is the model guessing — and the row goes.
3. Test each signal against next Monday. If you couldn't check it at 9 a.m. with a browser and a calendar, it isn't an early warning signal — it's a feeling. Send those rows back with "make the signal observable."
4. Assign the owners for real. The register names roles; you name the people. A risk with no one watching it is a risk nobody sees until it's an issue.
5. Carry the top three into your weekly review. The weekly review prompt has a place for what's at risk, and this is where those lines come from. Re-run it every two weeks with what's changed — retire what fired or expired.

Example output (partial)

Inputs: migrating a subscription billing system from an in-house tool to a third-party provider; 14 weeks, go-live 12 December, and the date is fixed because the old tool's support contract ends 31 December; team: PM, two backend engineers (one at 50% until week 6), one QA joining in week 8; dependencies: provider sandbox credentials (their onboarding team, promised 3 October), finance sign-off on the reconciliation report format (no date given), a data-mapping document owned by an engineer who leaves on 31 October; assumption: invoices older than 24 months don't need migrating; the sponsor's definition of failure: "a customer gets billed twice."

R1 · Immediate · Likelihood High · Impact High (date) Given that the data-mapping document is owned by an engineer leaving on 31 October, there is a possibility of the mapping being incomplete or unexplained after that date, adversely impacting the migration build in weeks 7–14, which can result in the 12 December go-live slipping past the 31 December contract end. Signal: no second engineer has walked through the document by 17 October. Mitigation: a two-hour recorded handover in week 5, with the 50% engineer as the named reader. Fallback: contract the leaving engineer for a fixed number of hours in November. Owner: PM.

R4 · Near-term · Likelihood Medium · Impact High (quality) Given that the sponsor's definition of failure is "a customer gets billed twice" and the reconciliation report format has no sign-off date, there is a possibility of reconciliation being designed late, adversely impacting the cutover checks in week 13, which can result in duplicate charges going undetected on go-live weekend. Signal: no finance sign-off by 24 October. Mitigation: send finance a one-page draft format this week with a reply-by date. Fallback: run a manual double-charge check on the first three billing cycles. Owner: PM.

Can't assess

1. Which date is the harder one, 12 December or 31 December? If the old tool can run into January, R1's impact drops to Medium.
2. Does "invoices older than 24 months don't need migrating" have a sign-off, or is it your assumption? If finance disagrees in week 10, the scope grows by an amount nobody has sized.

Nine rows came back in the full run. The two above were the ones with a date in the signal — which is why they ranked where they did.

Variations

For a two-week sprint

"This is a sprint, not a project. Give me five rows, every signal checkable before the sprint's midpoint, no time frame column."

For briefing the sponsor on one risk

When a row turns from likely to happening, run the internal memo prompt on that single row: what you've decided first, the condition second, what you need from them third. Don't paste the whole register into a sponsor email. They'll read the first line and ask about the ninth.

For a product launch

Replace the dependencies input with "Launch dependencies: [marketing assets, app-store review, support docs, legal copy — owner and promised date for each]" and add "the asset for every risk is either the launch date or the first week's users." The PRD writing prompt asks what would make this the wrong thing to build; this asks what would stop it shipping.

Re-running mid-project

Paste last time's register under a heading "Previous register, dated [DATE]" and add "for each row: retired, unchanged, re-ranked or fired, with the reason. Then add new rows for anything that's changed." NASA's software engineering handbook calls the discipline continuous risk management for a reason — a register written once is a snapshot of week one. The immediate, near-term and far-term bands in the prompt are that handbook's, too.

Common pitfalls

• Don't accept a percentage. "35% likely" reads as measured and isn't — the model has no base rate for your project. High, medium and low with a reason is what you can defend in a steering meeting.
• Don't let issues into the register. An issue has already happened, and it belongs in the status report, not here. The tell is tense — "the vendor is late" is an issue, "the vendor may be late" is a risk.
• Don't skip the "can't assess" list. It's the most useful section on a first run: the model telling you which inputs were too thin, as questions you can go and answer.
• Don't merge cause and effect. "Risk: the project runs late" is an effect with no condition — there's nothing to mitigate. The prompt's slot structure exists to stop that.
• Don't write the register and file it. NASA's software engineering handbook notes that the minimum statement of risk is the condition, and conditions change. Two weeks is about as long as a register stays true.

Who uses this prompt

• Project managers on cross-team work: the dependency input is where the register earns its keep, because the risks you own least are the ones you see last. More in prompts for project managers.
• Product managers before a launch: the launch variation replaces the "what are we forgetting" meeting. See prompts for product managers.
• Consultants scoping an engagement: run it on the client's plan, and the "can't assess" list becomes your first set of questions. See prompts for consultants.
• Small business owners running a one-off project: an office move, a system change, a first hire — the fallback column is the part you'll be glad you wrote. See prompts for small business owners.

ChatGPT, Claude, and Gemini all run this prompt unmodified. Anthropic's prompting best practices recommend giving the model "context or motivation behind your instructions," and that's the reason the prompt spells out the sponsor's definition of failure: a model that knows what failure means to the person reading the register ranks differently. In the example, the engineer leaving on 31 October was typed in as a dependency, one of three — the model didn't find that risk. It turned a fact everyone on the team already knew into a row with a signal, a date and a name, which is the whole job.