35 AI Prompts for Project Planning and Scoping

You are helping me plan a project. Do not invent facts: if an input
below is missing, list it as an open question instead of assuming it.

Goal: {{project_goal}}
Deadline: {{deadline}}
Team and roles: {{team}}
Constraints (budget, tools, approvals): {{constraints}}

Produce, in this order:
1. A work breakdown structure with 4-6 phases and 3-6 tasks per phase,
   including commonly forgotten tasks (approvals, QA, documentation,
   post-launch support).
2. A low / most-likely / high duration for each phase, with a confidence
   level and the assumption behind each.
3. The five biggest risks, each with a concrete failure scenario and one
   mitigation.
4. A list of open questions I must answer before this plan is reliable.

Format as a numbered outline. Keep each task to one line.

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.

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.

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.

Break this single task down into subtasks that could each be assigned to
one person and completed independently: {{large_task_description}}.

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.

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.

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.

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}}.

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 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.

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.

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.

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.

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}}.

Original scope: {{original_scope}}
Original estimate: {{original_estimate}}
New scope: {{new_scope}}

Re-estimate the work. Do not invent facts about my team or progress so
far; if you need something that is missing, ask before estimating.

Output a table: item | original estimate | new estimate (low / most
likely / high) | one line on why it changed. Then give me two sentences I
can use to explain the new timeline to the stakeholder.

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.

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.

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.

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.

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.

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.

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.

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.

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?

Project: {{project_description}}
Team and constraints: {{team_and_constraints}}
Known history with similar work: {{history}}

Draft a risk register with 8-10 risks. Each risk must be a concrete,
falsifiable failure scenario, not a category like "poor communication".
Do not invent facts about the project; if a risk depends on something I
have not told you, phrase it as a question.

Output a table: risk | failure scenario | likelihood (low/medium/high) |
impact (low/medium/high) | early warning sign | one mitigation step.

Project: {{project_description}}
Deadline and team: {{deadline_and_team}}

Imagine it is a year from now and this project failed completely. Write
5 distinct, specific reasons it failed, as a post-mortem written after
the fact. Avoid vague causes like "poor communication". Do not invent
facts about my team; base each reason on the inputs above or label it an
assumption.

For each reason, add the earliest warning sign I could see today and one
thing I could do this week to reduce the chance.

Original scope: {{original_scope}}
Current commitments and deadline: {{current_commitments}}
New stakeholder request: {{new_request}}

Decide whether the request is in scope, scope creep, or unclear. Quote or
point to the part of the original scope that supports your answer, or say
the scope is silent on it. Do not assume contract terms I have not given
you.

Then give three ways to respond (accept it, trade it against something,
or raise a change order), each with one sentence I could say to the
stakeholder.

Third party: {{third_party_name}}
What we depend on them for: {{dependency_description}}
Date we need it by: {{needed_by}}
What happens to the project if it is late or fails: {{impact_if_fails}}

List the specific risks this dependency creates. Do not make up facts
about the vendor (pricing, uptime, policies); mark anything I should
check with them directly.

Output a table: risk | trigger | impact on the project | contingency |
date by which I must decide to switch to the contingency.

Risk register: {{risk_list}}
Roles available on the project: {{team_roles}}

For each risk, suggest which role (not a named person) should own
monitoring it, what they should watch, and what would trigger escalation.
Do not assign a role that is not in the list above.

Output a table: risk | owner role | what they monitor | escalation trigger |
who is told.

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.

Draft a formal scope statement for this project: {{project_description}}.
Include sections for objectives, in-scope items, out-of-scope items,
assumptions, and deliverables.

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.

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.

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.

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.