Act as an experienced project manager helping me create a practical, fair project plan. Use only the information I provide; do not invent dates, staffing, approvals, budgets, or commitments. Ask up to 3 clarifying questions only if a required input is missing. Project context: [PROJECT BRIEF] Known work, constraints, and dependencies: [WORK AND CONSTRAINTS] People, roles, and decision-makers: [TEAM AND STAKEHOLDERS] Target date or planning horizon: [TIMELINE] Current status or problem to solve: [CURRENT STATUS] Produce a working project plan in this format: 1. A 3-5 sentence objective, including the intended outcome, scope boundaries, and measurable definition of done. 2. A scope table: in scope, out of scope, and assumptions requiring confirmation. 3. A milestone plan in chronological order. For every milestone, state deliverable, owner or owner role, due date/status, predecessor dependency, and acceptance criterion. Mark unassigned owners and unknown dates as open decisions rather than guessing. 4. A task register grouped by milestone. Break work into tasks small enough to hand off and track; identify the accountable owner separately from contributors where the information supports it. 5. A risk and issue log with likelihood, impact, early warning sign, mitigation, and owner. Distinguish a current issue from a possible risk. 6. A decision log listing decisions needed, who should decide, decision deadline, and what is blocked until then. 7. A short update I can send to the team: progress, next steps, asks, and no blame. Apply normal project controls: surface critical-path dependencies, avoid assigning a person work they do not own, and call out capacity conflicts or ambiguous handoffs. Before answering, check that every milestone has a concrete acceptance criterion and that no claimed fact, date, or owner was invented. End with the three highest-value actions for the next five working days.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT BRIEF] | Describe the project goal, desired outcome, and why it matters. | Launch a customer onboarding webinar series that reduces first-month support tickets for new Pro subscribers. |
| [WORK AND CONSTRAINTS] | List known deliverables, requirements, dependencies, budget or scope limits, and relevant facts. | Create curriculum, registration page, email sequence, live webinar, recording, and help-center links. Legal must approve customer examples; no paid media budget. |
| [TEAM AND STAKEHOLDERS] | List team members or roles, their responsibilities, and people who approve or are affected. | Maya owns marketing; Dev owns webinar production; Priya from Support supplies top questions; Legal approves examples; VP Customer Success approves launch. |
| [TIMELINE] | Provide fixed dates, target launch dates, and any planning horizon. | First webinar should run by November 14. Registration page needs to be live 14 days earlier. |
| [CURRENT STATUS] | Describe what is complete, blocked, behind schedule, or uncertain. | Topic is approved. Support has not yet supplied questions, and Dev is unavailable November 5-7. |
How to use
- Paste the prompt and replace every bracketed input with your project facts.
- Check the scope and milestone plan before sharing it; resolve any open decisions or invented-looking assumptions.
- Confirm owners directly with the people named, especially where the plan lists only a role.
- Follow up with: “Turn the task register into a weekly status agenda for the next four weeks, retaining all open risks.”
Variations
Weekly status update
Use this when the project already has a plan and you need a factual team update.
Create a concise weekly project status update from [PROJECT NOTES] for [AUDIENCE]. Use sections for overall status, completed work, work due next week, decisions or help needed, risks, and changes to timeline. Separate facts from assumptions, name an owner for every ask when supplied, and do not turn a late item into blame. Include a one-line recommended status color with its evidence. Ask up to 3 questions only if a key update is missing.
Construction schedule
Use this for a construction work plan with trade sequencing and site controls.
Build a look-ahead plan for [CONSTRUCTION PROJECT] covering [PLANNING PERIOD]. Based on [SCOPE AND SITE FACTS], list work by trade, predecessor activity, required inspections, material lead times, site-access constraints, and accountable superintendent or subcontractor. Identify activities that could affect the critical path and any work that cannot start because a prerequisite is unverified. Do not assume permits, deliveries, or labor availability. End with a daily coordination agenda and ask up to 3 questions only for missing essentials.
Project recovery plan
Use this when a project has missed dates or is at risk of doing so.
Create a recovery plan for [PROJECT] based on [CURRENT PLAN], [ACTUAL STATUS], and [CONSTRAINTS]. First identify the variance between planned and actual work, then distinguish root causes from symptoms. Provide options to recover time or scope, each with tradeoffs, decision owner, and effect on quality, cost, and dependencies. Recommend one option only if the evidence supports it. Produce a revised milestone table, risk log, and a candid stakeholder update. Do not invent capacity or approval. Ask up to 3 questions if needed.
Tips
- Write acceptance criteria as observable evidence, such as “registration page passes legal review and accepts a test signup,” rather than “page is complete.”
- A dependency should name both the predecessor and the consequence of delay; “waiting on Legal” is less useful than “webinar examples cannot be published until Legal approval.”
- Keep one accountable owner per task even when several people contribute; shared ownership often hides a missing handoff.
- Treat a target date with no approved scope, owner, or prerequisite as a planning assumption, not a commitment.
FAQ
Can AI create a project plan from a rough brief?
Yes, but it should label missing owners, dates, and dependencies as open decisions. A polished plan with guessed commitments creates false certainty.
How detailed should the task register be?
Use tasks that can be completed, reviewed, or escalated within a reporting cycle. If a task spans weeks, break it at meaningful handoffs or deliverables.
Will this work for an agile project?
Yes. Supply the sprint cadence, backlog constraints, and team roles, then ask the model to organize milestones around releases and sprint outcomes rather than a fixed waterfall schedule.