Project Kickoff Recap Template: A One-Page Visual Guide

A project kickoff recap should record what the team agreed about the goal, scope, responsibilities, milestones, and immediate next steps. A one-page visual version gives stakeholders an overview, while the written recap holds the detail and links to the working plan.

Use the template below after the kickoff. It is a record of outcomes, not an agenda for running the meeting or a substitute for a project charter.

The illustrations and help-center project are editorial examples. They are not a live project plan, customer result, or screenshot of the generator.

Copy the kickoff recap template

Replace the bracketed fields with the actual meeting outcomes. Leave unresolved items explicitly pending.

Project: [name]
Kickoff date: [day month year]
Recap status: [draft for review / confirmed]

Goal:
[What change should this project produce?]

Success check:
[What will be reviewed, and who accepts the result?]

In scope:
- [agreed deliverable]
- [agreed deliverable]

Out of scope:
- [explicit exclusion]

Owners:
- Project lead: [name]
- Delivery owner(s): [name and responsibility]
- Decision or approval owner: [name or pending]

Milestones:
- [deliverable] — [owner] — [date or pending]

Dependencies and risks:
- [dependency] — [status] — [person following up]

Immediate actions:
- [task] — [owner] — [due date]

Open decisions:
- [question] — [who will resolve it, if agreed]

Next checkpoint: [date and purpose]
Working plan: [link in the accompanying text document]

The goal and success check deserve separate lines. “Improve the help center” describes a direction, but not how the team will accept the work. If no acceptance criterion was agreed, record that gap instead of inventing a percentage target.

Atlassian's project kickoff play emphasizes building a shared understanding of the work and its success. This recap template is an original structure for carrying those agreements into a concise follow-up artifact.

Worked example: define the scope boundary

Consider a fictional help-center refresh. The team agrees to improve article navigation, search labels, and mobile readability. Translation, billing changes, and account redesign are excluded. Analytics access is still pending.

Do not mix all seven items into one “Things to do” list. A visual boundary should distinguish approved work, excluded work, and an unresolved dependency.

Pending analytics access belongs beside the scope boundary as a dependency, not inside the approved deliverables.

Here is a compact version of the fictional project:

Field	Example recap
Goal	Make help-center navigation and labels easier to use on mobile
Success check	Nora reviews the prototype against an agreed usability checklist; checklist still to be confirmed
Project lead	Maya
Delivery	Maya prepares the outline; Leo prepares the prototype
Review owner	Nora
Dependency	Analytics access pending; Leo to follow up
Open item	Confirm the usability checklist before review

The pending checklist is not an embarrassment to hide. It is work the kickoff recap has made visible.

Attach an owner to every milestone

A milestone should describe an observable deliverable or review point. “Design” is ambiguous; “Prototype ready for review” is more concrete. Keep dates as planned dates until the work is actually complete.

For this example, the team has planned an outline for 11 September, a prototype for 16 September, and a review for 18 September 2026.

These are planned milestones. A neat timeline does not establish that a dependency has been resolved or that delivery is guaranteed.

If a pending dependency threatens a date, say so in the written plan. Do not add green completion marks or remove the uncertainty simply to make a more attractive graphic.

Make the visual overview

Once the recap is checked, select the goal, the most important scope boundaries, the milestone owners, and the open dependency. Paste those notes into the YK Handdrawn generator, choose Clean Infographic, and select English.

Landscape can suit a timeline; portrait can suit stacked sections. The generator may choose a different arrangement from the examples, so review whether the result preserves the boundary between agreed and pending work.

Keep the full template in a text document. The generated result is a static image, not an editable project plan, slide deck, or task board. Links written into the graphic are not interactive. Put the working-plan link in the surrounding message, and download the image within the displayed 30-minute availability window.

If you need to correct a generated label, revise the source and generate again, or use a separate image editor. A new generation uses another credit.

Send a recap that invites precise corrections

Attach the visual to a short message that identifies the document's status:

Here is the draft recap of our help-center kickoff. Please check your responsibility, planned milestone, and the scope exclusions. Analytics access and the acceptance checklist remain open. The linked working plan contains the detailed actions and will hold subsequent updates.

After participants confirm or correct the record, update the written recap and the image if needed. Keep one authoritative working-plan link so a forwarded image does not become a competing source of truth.

Common questions

What is the difference between a kickoff agenda and a recap?

The agenda sets the topics before the meeting. The recap records the actual outcomes afterward. Copying the agenda into a graphic may show what you discussed without showing what you agreed.

Should the one-pager include every risk?

Include the risks and dependencies needed to interpret the headline plan. Keep the full risk register in the linked project record. If several risks materially change the plan, use an additional page instead of unreadably small text.

What if responsibilities are not agreed?

Label them pending and record who will resolve the assignment if that is known. Do not infer ownership from who spoke most during the meeting.

For recurring team updates, use the simpler visual meeting recap. If your kickoff was mainly exploratory, use the workshop synthesis method before presenting ideas as approved work. When the source is ready, create the kickoff overview.