TL;DR
You need a one-page project plan stakeholders can react to in 48 hours: milestones, dependencies, a risk register, and a testable definition of “done” for each milestone. AI is excellent at the structure (enumerating milestones, surfacing dependencies, drafting a RAID-style risk log) and poor at effort estimates and your org’s real constraints. Feed it the goal, deadline, team, and known constraints; use the prompt below to get a milestone table, a named critical path, and a top-5 risk register; then have a human re-estimate every date. Recommended model as of June 2026: Claude Opus 4.7 or GPT-5.5 in Thinking mode for reasoning through dependencies, with the plan stored in a Claude Project or ChatGPT Project so the context persists across the project’s life.
The task
You are kicking off a project and need a plan stakeholders can react to in 48 hours. Not a Gantt chart — a one-page plan that names the milestones, the dependencies, the risks, and what “done” looks like for each milestone. The trap is producing a plan that reads well in a meeting but breaks the first time reality intervenes. The job is honest scoping, not impressive scoping.
Where AI helps and where it does not
AI is strong at structure: enumerating milestones, surfacing dependencies, and listing risk categories (technical, organizational, market, regulatory). It is weak at estimating effort and at knowing your organization’s actual constraints — who has bandwidth, who is on holiday, which team owes you a favor. So the division of labor is fixed: AI drafts the skeleton and the risk categories; a human who knows the team supplies every date and every effort estimate.
| Step | Owner | Why |
|---|---|---|
| List milestones and dependencies | AI | Fast, exhaustive, no recency bias |
| Draft the risk register categories | AI | Surfaces categories you forget under pressure |
| Estimate effort and dates | Human (with the engineer) | AI has no access to who is actually free |
| Name the critical path | AI drafts, human confirms | AI orders the dependency chain; you sanity-check it |
| Decide what is out of scope | Human | A judgment call AI cannot make for you |
What to feed the AI
- Goal: what success looks like in one sentence
- Deadline: hard or soft, and why
- Budget: money, headcount, calendar time
- Team: roles, seniority, time allocation %
- Known constraints: technical, regulatory, dependencies on other teams
- What you have already decided is out of scope
- Past similar projects: what went well, what went wrong
The thinner this input, the more the model invents plausible-but-wrong dates. If you can only fill three fields, fill goal, team, and deadline first.
The prompt
Draft a one-page project plan I can present in 2 days.
Goal (one sentence): [line]
Deadline: [date, hard or soft]
Budget: [money / headcount / calendar]
Team: [roles, seniority, allocation %]
Known constraints: [technical, regulatory, cross-team]
Out of scope: [list]
Past similar projects (wins and losses): [notes]
Return:
1. Milestones (4-7), each with: name, success criterion (testable),
owner, due date, dependencies
2. Critical path: the longest dependency chain, named explicitly
3. Risk register (RAID-style): top 5 risks, each with probability
(L/M/H), impact (L/M/H), and a named mitigation owner
4. Decision log: 3 decisions that must be made in week 1, with owner
5. Success metrics: 2-3 leading + 1 lagging, each with a definition
6. Communication cadence: who hears what, how often
Rules:
- Be honest about estimates. If a milestone's uncertainty is over 50%,
mark it [UNCERTAIN: needs a spike] instead of guessing a date.
- Milestones are observable outcomes, not tasks.
- Every milestone gets exactly one owner.For high-uncertainty projects, add: Build an explicit week-2 reassessment into the plan with Go / No-Go criteria.
What good output looks like
Ask for a one-page milestone table — milestone / owner / due / dependencies / success criterion / done? — with the risk register as a separate RAID table below it, the decision log as a list, and the communication cadence as one paragraph. Skip Gantt-chart formatting in the draft; shapes hide the dependency logic you are trying to pressure-test.
The risk register is where most AI plans fall down, so demand the RAID format. RAID stands for Risks, Assumptions, Issues, and Dependencies (some teams use Decisions for the D), and it is the standard project-tracking artifact at PMO-level shops. Every entry needs an owner; “the team” is not an owner. A usable register reads like this:
| Risk | Probability | Impact | Mitigation | Owner |
|---|---|---|---|---|
| Auth vendor API changes mid-build | M | H | Pin SDK version; isolate behind adapter | Backend lead |
| Designer out 2 weeks in March | H | M | Front-load design review to February | PM |
| Data migration larger than scoped | M | H | Run a sizing spike in week 1 | Data eng |
Assumptions decay faster than risks, so flag the assumptions the plan rests on and put a revalidation date on each — that single habit catches most plans that quietly drift off the rails.
How to check the output is usable
- Every milestone has a testable success criterion (“API deployed to staging, all integration tests passing”), not a fuzzy one (“API ready”).
- The critical path is named, not implied.
- Risks are specific to your project, not boilerplate (“scope creep” is not a risk; “the payments vendor’s PCI review takes 6 weeks, not 2” is).
- The communication cadence is realistic — a daily standup plus a weekly exec read-out, not three standing weekly meetings.
- Out-of-scope items have not quietly reappeared as requirements.
Common mistakes
- No risks listed: every plan without risks is a wish list.
- Milestones with no success criteria, so “done” becomes argument fodder.
- Letting AI estimate effort without a human engineer grounding it.
- Confusing milestones with tasks — milestones are observable outcomes, not to-dos.
- No decision log, so the project stalls on undeclared decisions.
- Missing or shared milestone ownership, so accountability dissolves.
Which AI tool to use (June 2026)
Any frontier model can draft this, but the difference shows up in dependency reasoning and in keeping the plan alive after the kickoff:
| Tool | Best for plans | Persistence | Price (June 2026) |
|---|---|---|---|
| Claude Opus 4.7 (Claude Pro) | Reasoning through dependency chains and risk trade-offs | Claude Projects: shared instructions + uploaded docs, ~200K-token knowledge base | $20/mo (Pro) |
| GPT-5.5 Thinking (ChatGPT Plus) | Structured tables, fast iteration | ChatGPT Projects: up to 20 knowledge files, 512 MB | $20/mo (Plus) |
| Gemini 3.1 Pro (Google AI Pro) | Pulling context from long source docs; Workspace integration | Gems + 1M-token context; live Google Drive sync | $19.99/mo (AI Pro) |
For most planning work, draft in Claude Opus 4.7 or GPT-5.5 in Thinking mode — both reason carefully through a dependency chain rather than rushing to a list. Then store the plan, the constraints, and the running RAID log inside a Claude Project or ChatGPT Project so every re-plan starts from the live context instead of a blank chat. If your source material lives in Google Docs, Gemini 3.1 Pro with its 1M-token window and Drive sync ingests it without copy-paste.
A grounding note on what these models cannot do: none of them know your calendar. Treat every date the model proposes as a hypothesis to be re-estimated by the person who will actually do the work.
FAQ
PRD or project plan — which comes first? The PRD describes what you are building; the project plan describes how you will deliver it. Write the PRD first, then plan delivery. See PRD draft.
Agile or waterfall — does the prompt change? Iterations versus phases are sequenced differently, but milestones, owners, and testable done criteria apply to both. For agile, frame milestones as end-of-sprint outcomes.
How often should I re-plan? A weekly soft check (have assumptions changed?) plus a hard check at every milestone completion. Update the RAID log in real time, not at the next meeting — a register that lags reality is worse than none.
Can AI estimate effort if I give it the team list? No. It can propose a date, but it has no access to who is actually free or how fast your team ships. Use its dates as a starting point and re-estimate with the engineer who owns the work.
What is a RAID log? A single living artifact tracking Risks, Assumptions, Issues, and Dependencies (or Decisions). It is the standard project-tracking record at PMO-level teams; see Asana’s RAID log guide for the full template.
Related
- PRD draft: the product spec that precedes the plan
- User story writing: break milestones into user stories
- Feature prioritisation: choose which milestones go in
- Roadmap planning AI: the multi-project view
- Launch checklist: the final milestone
- AI task breakdown tutorial: break a milestone into tasks
- Project Planning Prompts: From Goal to Sprint Plan
Tags: #Workflow #Productivity #PRD