Turn the project information below into a working project brief that a cross-functional team can follow. Do not fill gaps with invented decisions, dates, budgets, owners, dependencies, or metrics. Project request: [PROJECT CONTEXT] Desired outcome and success measure: [SUCCESS CRITERIA] People and responsibilities known so far: [TEAM AND STAKEHOLDERS] Constraints, deadline, and available resources: [CONSTRAINTS] Existing decisions, open questions, and source notes: [SOURCE NOTES] Write a concise brief with these sections:
1. Objective and non-objectives: one measurable outcome, what is explicitly out of scope, and why. 2. Deliverables and acceptance criteria: what will exist at handoff and how each item will be judged complete. 3. Work plan: 5-10 ordered work packages. For each, list owner, contributor or approver if known, dependency, estimated timing, and completion evidence. Mark unknown ownership as “unassigned,” not a guessed person. 4. Milestones: a dated sequence only where a date is supplied; otherwise use relative order and label dates as proposed. 5. Risks and assumptions: include trigger, impact, mitigation, and person to resolve where known. 6. Decision log and open questions: separate confirmed decisions from choices that still need an owner and deadline. 7. Weekly status format: completed, next, blocked, decisions needed. Make handoffs explicit and distinguish accountable owner from people consulted. Identify scope creep risks and dependencies outside the team. Before answering, check that every acceptance criterion is observable and every claimed fact appears in the supplied information. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT CONTEXT] | Describe the project request, problem, audience, and current state. | Launch a self-serve onboarding flow for a payroll SaaS trial to reduce setup confusion. |
| [SUCCESS CRITERIA] | State the desired outcome and any metric, quality bar, or completion definition. | Increase the share of trial accounts that connect a payroll system within seven days from 32% to 42%. |
| [TEAM AND STAKEHOLDERS] | List known team members, their roles, and stakeholders who approve or depend on the work. | Priya, product manager; Leo, designer; Marta, engineering lead; Owen, lifecycle marketing; finance operations approves compliance copy. |
| [CONSTRAINTS] | List fixed deadlines, budget, tools, legal limits, capacity, or other constraints. | Pilot must start by November 4; one frontend engineer is available; no changes to payroll integrations. |
| [SOURCE NOTES] | Paste meeting notes, decisions, open questions, research, or links summarized in text. | Users abandon the connection screen when they cannot find their provider. Decision: test a searchable provider list. Open question: who owns support content? |
How to use
- Paste source notes before asking for the brief, especially decisions made verbally in meetings.
- Check that each work package has observable completion evidence and that an approver is not accidentally assigned as the owner.
- Confirm proposed dates and unassigned owners in a kickoff before treating the plan as committed.
- Send: “Convert this brief into a weekly status update for [WEEK], leaving missing evidence as blockers rather than assumptions.”
Variations
Project kickoff
Use to prepare an agenda and decisions for the first working meeting.
Create a 45-minute project kickoff agenda from: [PROJECT SUMMARY] [ATTENDEES] [KNOWN CONSTRAINTS] Include the objective, decisions required, a timed agenda, questions to resolve, and a post-meeting action table with owner and due date only where supplied. Separate information sharing from decisions. Do not invent commitments. Check that every agenda item serves either scope, ownership, timeline, dependency, or risk alignment.
Executive update
Use to turn project facts into a leadership-ready update.
Write a project update for [AUDIENCE] using these facts: [PROJECT FACTS] [REPORTING PERIOD] Use five sections: outcome status, progress since last update, next milestone, top risks with requested decision, and metrics. Limit it to [WORD LIMIT] words. State unknowns and red status plainly; do not imply work is complete without evidence. Check that dates, metrics, and ownership exactly match the source.
Recovery plan
Use after a milestone slips or a dependency fails.
Build a recovery plan for this project issue: [ORIGINAL PLAN] [CURRENT PROBLEM] [FIXED CONSTRAINTS] Give the root-cause hypotheses separately from confirmed facts. Offer three recovery options with scope, time, staffing, risk, and decision required. Recommend no option unless the evidence supports it. Then provide a revised milestone sequence with assumptions clearly labeled. Check that no option hides a dependency or changes a fixed constraint.
Tips
- Write acceptance criteria as observable evidence, such as a signed approval, deployed feature, or completed test, rather than “finished” or “aligned.”
- Assign one accountable owner per work package; a list of departments makes it unclear who drives a stalled handoff.
- Keep assumptions separate from decisions so a planning guess does not later become an unexamined commitment.
- Put external dependencies beside the work they block, not only in a risk register where they are easy to overlook.
FAQ
What is the difference between a deliverable and a milestone?
A deliverable is the thing produced. A milestone is a meaningful point in the sequence, often an approval, test start, or handoff.
Can AI assign project owners?
It can propose a role-based owner when you ask, but it should not present that as an agreed assignment. Confirm ownership with the team.
How detailed should a project brief be?
It should be detailed enough to make handoffs and completion testable, but not so granular that every small task needs a separate approval.