Before the meeting
Confirm that the project is ready enough to justify a kickoff. If the first work cannot begin, use the project readiness checklist before scheduling a ceremonial start.
Prepare a short shared note covering:
- the business or user objective,
- the first delivery boundary,
- key exclusions and assumptions,
- the current timeline and major milestones,
- named stakeholders and the decision maker,
- known dependencies, access needs and risks,
- the proposed communication and review rhythm.
Bring the current estimate, but do not present it as immutable. If scope has changed since estimation, review the task estimation checklist first.
When the estimate is current, turn it into a delivery date using the capacity and work calendar agreed for the project.
Confirm the objective and scope
Open with the outcome the project should create, not the list of outputs. Then confirm what the first release includes and what it does not include.
Ask participants to surface different interpretations. A ten-minute scope disagreement during kickoff is cheaper than two teams following different assumptions for a week.
Record any unresolved point with an owner and deadline. Do not hide it inside meeting notes as “to be confirmed”.
Name decision and delivery ownership
The group should know:
- who owns the project on the client or business side,
- who leads delivery,
- who approves product and scope decisions,
- who accepts completed work,
- who can approve commercial or timeline changes.
One person may hold several roles. The important part is that the authority is explicit.
Agree how the team will work
Set a practical operating rhythm:
- where tasks, decisions and risks are recorded,
- which channel is used for urgent questions,
- expected response times,
- when reviews or demos happen,
- how feedback is consolidated,
- how scope changes are raised and approved.
Avoid creating a process for every possible event. Agree only what the team needs to make the next decisions reliably.
Review access, environments and dependencies
Walk through the first two weeks of work and identify what the team will need: repositories, design files, content, credentials, environments, analytics, vendor contacts and external approvals.
For each missing item, assign an owner and due date. If a missing item makes the first work impossible, treat it as one of the blockers to resolve before development, not as a loose follow-up.
Align on quality and “done”
Clarify what must happen before work is accepted. Depending on the project, this may include review, testing, documentation, accessibility, security or stakeholder sign-off.
The definition does not need to cover the entire project in exhaustive detail. It should be concrete enough for the first milestone to avoid a late disagreement about whether the work is complete.
Finish with owned next steps
End with a short list of actions, each with one owner and one date. Confirm the first delivery item, the next decision point and the next team touchpoint.
A kickoff is successful when everyone can explain what happens next. A polished deck is optional.