TL;DR: These 35 prompts cover work breakdown structures, estimates, dependencies, risk registers, and scope documents for project planning. AI drafts a strong first pass fast, but it reliably underestimates timelines and doesn't know your team's real constraints — treat every output here as a draft for a human to correct, not a plan to execute unedited.
Project planning is a lot of structured document-writing under time pressure: a scope statement due before a kickoff call, a WBS that needs redoing after the client changes the requirements, a risk register nobody wants to write from scratch. That's the part of project management AI genuinely speeds up. What it can't do is know your team, your client's real priorities, or the dependency that only exists because one person is on parental leave in March. The 35 prompts below are grouped by planning phase, and are meant to get you from a blank page to a document you can actually edit, not to hand you a finished plan.
Anyone who has scoped more than a handful of projects knows the actual bottleneck isn't writing skill, it's the mental overhead of holding an entire project's structure in your head while also trying to phrase it clearly for a stakeholder. A WBS with forty line items, a risk register with a dozen entries, and a dependency map that has to stay internally consistent with both, that's a lot of simultaneous bookkeeping even for an experienced PM. AI is well-suited to holding that structure steady while you focus on the judgment calls, provided you don't let it also make the judgment calls.
Why AI underestimates project timelines
Before the prompts: the single most common failure mode in AI-assisted planning is timeline optimism. Ask a model to estimate how long a task will take and it will typically produce the "if nothing goes wrong" number, because that's the number that shows up most often in the planning documents, case studies, and project templates it was trained on. Real projects run into approval delays, scope creep, and the simple fact that most estimates undercount coordination overhead between people.
The fix isn't to distrust every AI estimate outright. It's to explicitly ask for a range, a confidence level, and the assumptions behind the number, then sanity-check that range against your own team's actual track record on similar work. Several of the prompts below build this pushback in directly.
Where AI estimates go wrong, by planning stage
Different planning artifacts fail in different ways when AI drafts them unsupervised. A WBS built from a one-line project description tends to be structurally reasonable but missing the tasks nobody thinks to mention out loud, documentation, stakeholder sign-off rounds, post-launch support. A dependency map built without real team context misses the dependency that exists only because one specific person is the sole reviewer for a module. And an estimate built without a stated confidence range collapses a genuinely uncertain number into a false-precision single figure that then gets treated as a commitment.
| Planning artifact | Common AI failure | What to add to the prompt |
|---|---|---|
| Work breakdown structure | Missing "invisible" tasks (approvals, QA, docs) | Ask explicitly for commonly forgotten tasks |
| Time estimate | False precision, optimistic bias | Require a range and a stated confidence level |
| Dependency map | Misses team-specific, non-obvious dependencies | Supply real team structure, not just task names |
| Risk register | Generic categories ("poor communication") | Ask for concrete, falsifiable failure scenarios |
| Scope statement | Thin or missing out-of-scope section | Ask what a client might wrongly assume is included |
Each row in that table maps to a cluster of prompts below. Knowing the specific failure mode in advance means you can catch it in the output rather than discovering it three weeks into the project.
A short worked example
Say a stakeholder hands you a one-line brief: "we need a redesigned onboarding flow before end of quarter." That's not a scope, it's a direction. Run it through prompt 5 (the scope-to-tasks converter) and you'll typically get back a task list plus a set of flagged ambiguities, does "redesigned" mean visual only or does it include new logic, does "onboarding flow" include the post-signup email sequence or stop at the in-app steps. Those flagged ambiguities are the actual value of the exercise, more than the task list itself, because they're the questions that would otherwise surface as a scope dispute in week six instead of a five-minute clarifying conversation in week one.
From there, prompt 1 turns the clarified scope into phase-based structure, prompt 18 maps which of those tasks can run in parallel, and prompt 25 drafts a starting risk register you'd then edit against what you actually know about this specific client and team. The output at each step is meant to be argued with, not accepted as-is; the value is having something concrete to react to rather than staring at a blank scoping document while the kickoff call gets closer.
Work breakdown structure prompts (1-9)
1. The phase-based WBS
Break this project into a work breakdown structure with 4-6 phases:
{{project_description}}. For each phase, list 3-6 major tasks. Do not
estimate durations yet — this is structure only.
2. The deliverable-based WBS
Take this project: {{project_description}}. Build a WBS organized around
final deliverables rather than phases. Each deliverable should have its
own set of supporting tasks nested under it.
3. The WBS gap check
Here is my current WBS: {{wbs_list}}. Review it for tasks that are commonly
forgotten in projects like this one (things like documentation, stakeholder
sign-off, and post-launch support). List anything missing.
4. The task-decomposition prompt
Break this single task down into subtasks that could each be assigned to
one person and completed independently: {{large_task_description}}.
5. The scope-to-tasks converter
Here is a rough scope description a stakeholder gave me: {{scope_paragraph}}.
Convert it into a structured task list, flagging anywhere the scope is
ambiguous enough that two different people could interpret it differently.
6. The milestone extractor
From this task list, identify 4-6 milestones that represent meaningful
checkpoints a stakeholder would care about: {{task_list}}. Each milestone
should be a clear yes/no completion state, not a vague phase name.
7. The parallel-work identifier
Here is my task list: {{task_list}}. Identify which tasks can run in
parallel versus which must run sequentially, and explain the reasoning
for each sequential dependency.
8. The resource-tagging prompt
For this task list, tag each task with the type of skill or role needed
to complete it (e.g. design, engineering, copywriting, client approval):
{{task_list}}.
9. The out-of-scope drafter
Given this scope description: {{scope_description}}, draft a list of
5-8 explicit out-of-scope items — things a client might reasonably assume
are included but aren't. Be specific, not generic.
Estimate prompts (10-17)
10. The range estimate
Estimate how long this task will take: {{task_description}}. Give me a
low, most-likely, and high estimate, and state your confidence level in
the most-likely number. Explain what would need to be true for the high
estimate to happen.
11. The estimate stress-test
I estimated {{task_description}} will take {{your_estimate}}. List 5
specific things that commonly cause this type of task to run over, and
tell me which ones apply here based on what I've told you.
12. The team-velocity adjuster
My team has historically taken {{historical_multiplier}}x longer than
initial estimates on similar work. Here is a raw estimate: {{raw_estimate}}.
Adjust it and explain the reasoning.
13. The buffer calculator
Given this list of task estimates: {{task_estimates}}, recommend where to
add schedule buffer and how much, based on which tasks have the most
estimate uncertainty rather than applying a flat percentage everywhere.
14. The client-facing estimate range
Convert this internal estimate range: {{internal_range}} into a client-
facing estimate. Decide whether to show a range or a single number, and
explain the tradeoff of each choice for this specific client relationship:
{{client_context}}.
15. The re-estimate after scope change
The original scope was {{original_scope}} estimated at {{original_estimate}}.
The scope has changed to {{new_scope}}. Re-estimate and clearly show what
changed and why, so I can explain the new timeline to the stakeholder.
16. The estimate-vs-actual retro
Here are my estimated and actual durations for the last project's tasks:
{{estimate_actual_pairs}}. Identify the pattern in where estimates were
most wrong, so I can adjust future estimates in that category.
17. The "what's not included" cost check
This estimate covers {{scope_summary}} for {{estimate_amount}}. List
common cost or time items that might not be obviously included (revisions,
QA, project management overhead, tooling costs) so I can confirm they're
accounted for.
Dependency and sequencing prompts (18-24)
18. The dependency map
Given this task list: {{task_list}}, map out dependencies — which tasks
must finish before others can start. Present it as a simple list of
"X blocks Y" statements.
19. The critical-path identifier
Given these tasks with durations and dependencies: {{tasks_with_durations}},
identify the critical path — the sequence of tasks that determines the
minimum possible project duration.
20. The external-dependency flag
Review this task list: {{task_list}} and flag any tasks that depend on
something outside our team's control (client approval, third-party
vendor, external API). These are the highest-risk dependencies for
schedule slippage.
21. The single-point-of-failure check
Given this team and task assignment: {{team_task_assignments}}, identify
any tasks where only one person on the team can do the work, since those
create schedule risk if that person is unavailable.
22. The dependency-change ripple effect
Task {{task_name}} is now delayed by {{delay_amount}}. Given this
dependency map: {{dependency_map}}, tell me which downstream tasks and
the final deadline are affected.
23. The cross-team handoff clarifier
This task list involves a handoff between {{team_a}} and {{team_b}}:
{{task_list}}. Draft a clear description of exactly what {{team_a}} needs
to deliver to {{team_b}} for the handoff to count as complete.
24. The sequencing sanity check
Here is my proposed task sequence: {{sequence}}. Does this order make
sense given the stated dependencies, or would a different order reduce
overall risk or duration?
Risk and pre-mortem prompts (25-30)
25. The risk register starter
For this project: {{project_description}}, draft a risk register with
8-10 risks. For each, include likelihood (low/medium/high), impact
(low/medium/high), and one concrete mitigation step.
26. The pre-mortem
Imagine this project has failed completely: {{project_description}}.
Write 5 distinct, specific reasons it failed, as if writing a post-mortem
after the fact. Avoid vague causes like "poor communication" — be concrete
about what actually went wrong.
27. The scope-creep early warning
Given this original scope: {{original_scope}} and this recent stakeholder
request: {{new_request}}, is this scope creep? Explain your reasoning and
suggest how to respond to the stakeholder.
28. The vendor/third-party risk check
This project depends on {{third_party_name}} for {{dependency_description}}.
List the specific risks this creates and one contingency for each.
29. The risk-to-mitigation-owner assignment
Here is my risk register: {{risk_list}}. For each risk, suggest which role
(not a specific person) should own monitoring it and what would trigger
escalation.
30. The stakeholder-alignment risk check
Given these notes from separate conversations with two stakeholders about
the same project: {{stakeholder_notes_a}} and {{stakeholder_notes_b}},
identify any places where their expectations seem to conflict.
Scope document and communication prompts (31-35)
31. The scope statement drafter
Draft a formal scope statement for this project: {{project_description}}.
Include sections for objectives, in-scope items, out-of-scope items,
assumptions, and deliverables.
32. The assumptions list
Given this project description: {{project_description}}, list the
assumptions I'm implicitly making that should be stated explicitly in
the scope document before work begins.
33. The kickoff agenda
Draft a kickoff meeting agenda for this project: {{project_description}}
with a team of {{team_size}} and these stakeholders: {{stakeholder_list}}.
Keep it to items that need live discussion, not status updates that could
be an email.
34. The client status update
Turn these internal notes into a client-facing status update:
{{internal_notes}}. Keep it factual, mention any risks in plain language
without alarm, and end with what we need from them, if anything.
35. The change-order draft
The client has requested this change: {{change_request}} to a project
originally scoped as {{original_scope}}. Draft a change-order summary
covering what's changing, the estimated time/cost impact, and what stays
the same.
Using these without letting AI plan the project for you
The pattern across all 35 prompts is the same: AI is fast at producing structure, a WBS shape, a risk register template, a dependency list format, and unreliable at the judgment calls that make a plan actually correct for your team. It doesn't know that your best engineer is leaving in six weeks, that the client historically changes scope after every review, or that "medium risk, medium impact" undersells a risk your team has been burned by twice before.
Use these prompts to skip the blank-page problem, not to skip the review. A scoping document a stakeholder signs should always have had a human read every assumption and out-of-scope line before it goes out.
Where this fits into a longer project
None of these prompts are one-time exercises. The strongest use of them is at each transition point in a project's life: scoping before kickoff, re-estimating after every scope change, running a risk check at the start of each phase rather than only once at the beginning, and running the estimate-vs-actual retro (prompt 16) at the end of every project so the next one's estimates start from real data instead of a fresh guess. Treating these as a recurring cadence, not a one-off planning session, is what actually improves estimate accuracy over time, since a single retro on one project tells you far less than a pattern across five.
It's also worth being honest about where these prompts don't help. They won't tell you whether a project should exist in the first place, whether the team has the bandwidth to take it on alongside existing commitments, or whether a client relationship can absorb a difficult scope conversation right now. Those are judgment calls that depend on context no prompt can supply, and treating a WBS or a risk register as a substitute for that judgment is exactly the kind of over-reliance that turns a useful drafting tool into a source of false confidence.
The same caution applies to the estimate prompts specifically. A range with a stated confidence level is more honest than a single number, but it's still only as good as the historical data or reasoning you fed into it. If your team has never delivered a project like this one before, no prompt, however well constructed, can substitute for the uncertainty that comes with genuinely new work. In that situation the honest move is widening the range and flagging the novelty explicitly to the stakeholder, not asking the model to produce false confidence in a number nobody has grounds to believe yet.
Keeping planning documents consistent across a team
If more than one person on your team is scoping projects, the biggest risk isn't a bad individual estimate, it's inconsistency: one PM's risk register has ten detailed entries and another's has three generic ones, and a client comparing two proposals notices the gap immediately. Saving the prompts in this post as a shared library, with your team's actual historical estimate multiplier and commonly-missed task categories baked into the prompt itself rather than left to each person's memory, keeps the output format consistent even when the people writing it aren't the same from project to project.
If you're running project scoping and planning prompts every week, saving the versions that worked for your team's specific project types, and reusing them with new variables per project, is faster than rebuilding a WBS prompt from scratch each time. See also 30 AI Prompts for PRDs, User Stories and Roadmaps for the product-management side of the same planning discipline.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An Account