A completed example
This fictional example shows the level of detail to aim for. It is not a customer's work history.
Project kickoff brief Project: Harbor Clinic booking redesign Prepared by: Maya R., product lead Kickoff date: Tuesday, March 3 Version: 1 (draft for kickoff meeting) Why we are doing this Patients often leave the online booking flow at the insurance step and call the front desk instead. We want a booking flow patients can finish on a phone without calling. Goal Ship a redesigned booking flow for both Harbor Clinic locations by Friday, May 15. In scope - New insurance step with an option to add details later - Mobile layout for all five booking screens - Rewrite of the confirmation email Out of scope - Payments and copays - The staff scheduling tool - Spanish translation (planned for the next phase) Team and roles - Maya R.: owner, final call on scope - Dev K.: engineering lead - Lina S.: design - Tom P.: front desk contact, Eastside location Milestones - March 13: wireframes reviewed - April 3: clickable prototype reviewed with front desk staff - April 24: build complete in staging - May 15: live at both locations Risks and open questions - The insurance list comes from a vendor file nobody has updated since last year. Owner: Dev K., answer by March 10. - Does the new consent text need legal review? Owner: Maya R., not yet answered. How we will work Weekly check-in Thursdays at 10:00. Decisions go in the project doc. Blockers go in the team channel the same day. Definition of done A patient can book, add or skip insurance, and receive a confirmation email on a phone, at both locations.
Make it yours
Your draft
The example is fictional. Edits stay in this page and disappear when you leave. Copy or download your work to keep it.
How to fill it in
- Write the why in two or three sentences that name the problem you are fixing, not the solution you have in mind.
- State a single goal with a specific date, then list in-scope and out-of-scope items as short bullets.
- Give every role and every open question one named owner, and add a date each question needs an answer by.
- Plan milestones backward from the deadline and write a definition of done that anyone on the team could check.
- Send the draft to the team before the kickoff meeting, then update it and change the version line once decisions are made.
Start from your actual work
On a Mac, Dayflow can help you remember the work behind the update. It drafts a timeline from screen activity. Export a date range as Markdown from Settings → Export. Review that record alongside your calendar and task tracker, then fill in the template above.
For a guided walkthrough, see exporting your work history or drafting a report with Claude Code. Check the assistant's draft before sending it.
Local AI keeps screenshot analysis on-device. Your own cloud provider or Dayflow Pro processes selected screenshots off-device. An assistant can receive the Dayflow data it retrieves in your conversation. Local storage does not make a cloud assistant conversation local. Read the data-flow guide before choosing a workflow.
Questions about this template
What should a project kickoff brief include?
Most kickoff briefs cover why the project exists, the goal and deadline, what is in and out of scope, who owns what, milestones, known risks and open questions, how the team will communicate, and what done looks like. The out-of-scope list and a named owner for each open question tend to prevent the most arguments later.
How long should a project kickoff brief be?
One or two pages is usually enough. The team should be able to read it in the first ten minutes of the kickoff meeting, so keep each section to a few lines and point to detailed specs, designs or budgets instead of pasting them in. If a section keeps growing, it probably needs its own document.
Is a kickoff brief the same as a project charter or statement of work?
No. A kickoff brief is a working summary for the team, not a signed agreement. It does not replace a contract, a statement of work, a budget approval or a detailed project plan. If your organization needs formal sign-off on scope or cost, get it separately and mention it in the brief so the team knows it exists.
Who should write the project kickoff brief?
Usually the project owner or lead drafts it and shares it with the core team a day or two before the kickoff meeting. Teammates should flag anything they disagree with, especially scope and dates. After the meeting, update the brief with the decisions made and change the version line so everyone knows which copy is current.
How can I tell after kickoff whether time is going where the brief planned?
Compare a few weeks of actual work against the milestones. You can keep a simple daily log, or use a tool like Dayflow, which drafts a timeline from your screen activity on a Mac. You still need to check that draft and add meetings, calls and other offline work before drawing conclusions or sharing it.
Use the right format for the next step
- Weekly status report for a concise progress update.
- Daily work log for a record you can come back to.
- Daily standup template for yesterday, today, and blockers.
Download Dayflow