The prompt
Score 10 of 10, Excellent
Use it when You need phases, tasks, owners, dependencies and milestones from a goal and a deadline.
- {{project_goal}}
- {{definition_of_done}}
- {{start_date}}
- {{deadline}}
- {{constraints}}
- {{team}}
- {{notes}}
Full prompt and why it works
Prompt
Project goal: {{project_goal}} How we will know it is done: {{definition_of_done}} Start date: {{start_date}} Deadline, and whether it can move: {{deadline}} Constraints (budget, fixed dates, approvals, people or suppliers outside the team): {{constraints}} Team, with roles and how much time each has for this project: {{team}} Notes on the work so far (tasks I know about, estimates, decisions already made): """ {{notes}} """ Task: Turn the goal above into a project plan with phases, tasks, owners, dependencies and milestones, for me to review with the team before we commit to dates. The team will use it to see who does what and when, and I will use it to tell the sponsor whether the deadline is realistic. Format: 1. Summary: the goal, the deadline, whether the plan fits it, and the chain of tasks that sets the end date (the critical path). 2. Phases and milestones: each milestone is a finished, checkable deliverable with a date, such as "Supplier contract signed" or "Pilot results reviewed by the sponsor", not an activity. 3. Task table with the columns ID, Task, Phase, Owner, Depends on, Estimate (working days), Start, Finish. Up to 30 tasks; group small ones. 4. Assumptions: every estimate or date that I did not give you. 5. Top three risks to the schedule, each with an early warning sign. 6. Open questions for the team. How to plan it: - Work back from the deadline as well as forward from the start, and include the work people forget: reviews, approvals, testing, training, handover, holidays and waiting on people outside the team. - Every task has one owner, using a name or role from the team list; write "to assign" if none fits. Keep tasks to ten working days or fewer so progress is visible. - Do not plan anyone for more time than they have for this project. - Show contingency as its own line before key milestones (roughly 10 to 20 percent of the time), not hidden inside estimates, so everyone can see it. The plan should be realistic enough that the team would sign up to it. If the work does not fit before the deadline, say so in the summary and give options (reduce scope, add people, move the date) rather than squeezing estimates to make it fit. If an estimate is missing, give your best one marked "(estimate)" for the owner to confirm.
Variables
- {{project_goal}}
- What the project will achieve, in a sentence or two.
- {{definition_of_done}}
- For example "new booking system live at all three clinics and the old one switched off".
- {{start_date}}
- When work can start.
- {{deadline}}
- The date, and whether it is fixed or can move.
- {{constraints}}
- Budget, fixed dates, approvals and outside dependencies. Write "none" if there are none.
- {{team}}
- Each person or role and how much time they can give, for example "analyst, two days a week".
- {{notes}}
- Tasks you know about, any estimates, and decisions already made. Rough notes are fine.
Why it works
- What good looks like. Milestones must be finished deliverables and every task has one owner, which makes the plan something you can track rather than a list of intentions.
- What to avoid. It forbids planning people beyond the time they have and hiding contingency inside estimates, the two usual reasons a plan looks fine on paper and slips in practice.
- If unsure. If the work does not fit the deadline, it says so with options instead of squeezing estimates, and every guessed estimate is marked for its owner to confirm.