Why it is written this way
When you ask for a risk review with a simple one-line prompt, AI typically returns generic items like "Schedule delays," "Budget overruns," and "Resource shortages." While not wrong, these apply to almost every project, so team members ignore them. This prompt turns generic theory into project-specific, actionable items.
The Role in the opening paragraph sets the persona as a manager who "neither exaggerates nor includes generic items." Asking for risks often makes language models err on the side of caution and generate overwhelming lists; this constraint keeps the output realistic. The Context paragraph includes the remaining timeline and collaborating teams, because a risk looks very different when you have three weeks versus three months.
The two Examples set the expected depth. The good example specifies "what depends on what and what the consequence is," while the bad example lacks specifics. This contrast significantly sharpens the model's output quality.
The Format constraint requiring an "Early Indicator" column makes the checklist actionable in practice. Teams often recognize a risk but miss the window to act because they don't know what warning signs to watch for. Placing the responsible department at the end ensures clear ownership—unassigned risks get read in meetings but never resolved.
The Constraint limits the list to 12 items and forbids hallucinating unmentioned departments. Nobody reads a 20-item checklist to the end, and fake department names undermine credibility. Excluding already completed work prevents the model from recycling past accomplishments as current tasks.
Unfamiliar terms? See Aha AI: role-prompting, output-format
Compared with a bad example
Summarize the risks for this project.
(Paste project plan)
A generic request yields textbook paragraphs under headings like "Timeline Risk / Technical Risk / Budget Risk." It misses specific points of failure unique to your project and omits assigned owners, making it useless for driving accountability in team meetings.
Variations
When you only need a Day-Before Launch checklist
We are launching on {{timeline event schedule}}. Review the project details below and identify exactly 10 items that a human must manually verify the evening before launch.
Format each item as a single line: "What to Check · How to Verify · Who to Escalate to if Broken". Exclude any item that takes more than 5 minutes to verify, and exclude anything that can be safely fixed after launch.
Project details: """ {{project detail content}} """
This variant is not an end-to-end risk register, but a concise punch list for the night before launch. The "must take under 5 minutes" rule filters out broad tasks and leaves only immediate, verifiable checks.
When dividing checklist by department
Break down the pre-launch checklist for the following project by {{relevant department}}.
For each department, list: "Items to verify (max 4) · Requests needed from other teams · Due date". If an item has ambiguous ownership, group it at the end under "Unassigned". Only use the department names provided below; do not invent new ones.
Project details: """ {{project detail content}} """
When you share a single massive checklist, teams assume someone else is handling it. Segmenting by department forces clear accountability and prompts immediate follow-up.
Model notes
The model may occasionally mark every item as "High" likelihood. If this happens, follow up with: "More than half the items are marked High. Recalibrate the criteria and reclassify the likelihood distribution across High, Medium, and Low."
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know