01 / START HERE
A useful way to approach it.
A client email saying 'we need a better website soon' is a starting point, not a plan. Before assigning dates, separate the intended outcome from the requested features and the missing decisions. A useful first draft lets the client correct your understanding before anybody mistakes an assumption for a commitment.
Paste a brief you are allowed to share into o1 and request a text plan. Remove unnecessary confidential details. This workflow drafts phases and questions; it does not create a project board, assign colleagues, book meetings, or change a contract. The sample client and schedule are fictional authored examples.
02 / THE PROCESS
Go from question to next step.
- 01
Extract the brief's actual requirements
Read the email once for the intended outcome, then again for explicit requests. Record audience, deliverables, constraints, available assets, and any stated deadline. Preserve the client's wording beside your interpretation. Do not convert a passing idea into an approved requirement merely because it sounds useful.
- 02
List the missing decisions
Ask what information is necessary to plan responsibly: content owner, approval contact, required pages, available materials, and what 'finished' means. Rank questions by how much they affect scope or sequence. A plan can proceed with stated provisional assumptions, but it should show where an answer could change the work.
- 03
Group work into phases
Create a small number of phases that produce reviewable outputs, such as discovery, content, design, implementation, and verification. Explain the output of each phase before listing tasks. Avoid presenting a long activity list as a plan when the client cannot tell which result each activity is meant to produce.
- 04
Make dependencies and ownership explicit
Identify what must be supplied or approved before later work can begin. Use proposed roles until real people accept ownership. Keep estimated effort separate from calendar dates. If the client has not confirmed a deadline or provided assets, mark the resulting schedule as provisional rather than inventing certainty.
- 05
Review the draft with the client
Send or discuss the plan through your normal process after checking it yourself. Confirm requirements, assumptions, approval points, and the conditions that might change the schedule. Revise the draft from that feedback. Generating the text in chat does not mean the client has approved it or that any tasks have been assigned.
03 / YOUR STARTING POINT
A prompt you can make your own.
Replace the bracketed fields. Add only information you have permission to share. This is a reusable text prompt; it does not run a task from this page.
Turn this client brief into a draft project plan: {{brief}}. Separate explicit requirements, proposed interpretations, and unknowns. State audience, intended outcome, deliverables, constraints, and assets needed. Ask the five most important clarification questions before proposing dates. Draft phases with outputs, dependencies, proposed owner roles, and approval points. Label assumptions and any schedule as provisional. Do not invent client approval, assign real colleagues, or claim a project board was created. Finish with what I should confirm with the client first.04 / SEE THE SHAPE OF IT
Illustrative plan from an incomplete website brief
Fictional client brief and authored plan; dates, roles, and approvals have not been agreed or executed.
| Phase | Proposed output | Dependency / review |
|---|---|---|
| Discovery | Audience and page inventory | Client confirms required pages |
| Content | Draft copy and asset list | Content owner supplies approved material |
| Build | Website draft for review | Page structure and assets confirmed |
| Verification | Link, form, and mobile checks | Client reviews the actual result |
The draft connects each phase to an output and a decision. It remains provisional until the people doing and approving the work confirm it.
05 / KEEP YOUR JUDGMENT
What to watch before you use it.
Scheduling before clarification
A precise date can conceal uncertain scope. Resolve the dependency or show the date as an assumption to review.
Confusing an idea with a requirement
Retain the distinction between the client's explicit request and a suggested improvement. Obtain agreement before adding work.
Inventing ownership
Use role placeholders until somebody accepts the task. A name in an AI draft does not establish responsibility.
06 / THE FINAL PASS
A little review goes a long way.
Your checks stay on this page. They do not approve or run a task.
07 / GOOD QUESTIONS
Before you begin.
Can I plan from a short email?
You can draft an interpretation and clarification questions. A short brief rarely establishes every requirement. Show what you inferred and which missing decisions affect scope, cost, or timing before treating the draft as an agreed plan.
Should the assistant estimate all the dates?
Ask for a sequence and dependencies first. Dates need your capacity, availability, and agreed constraints. If you include a sample schedule, label it provisional and verify it with the people supplying inputs and completing the work.
How does this differ from a scope document?
The plan describes how work could proceed, including phases and dependencies. Scope defines what is included, excluded, and acceptable. Use both when needed, but do not hide unresolved deliverables inside a detailed task schedule.