How to run a project kickoff meeting

When is a kickoff worth it?

Hold a kickoff when several people must coordinate on a new outcome and assumptions aren't settled yet. It helps most when ownership crosses teams or people picture success differently. Atlassian's kickoff guidance stresses the same things: shared purpose, roles and success criteria.

For small, familiar work, a short written brief may be enough. For a big or uncertain project, the kickoff will surface questions that need more planning. Treat it as the start of coordination, not the moment every estimate gets settled.

Send a brief people can push back on

Send a short draft before the meeting. Cover the problem, the goal, the proposed scope, known constraints and the questions the group must answer. Label assumptions as assumptions. Ask for comments in advance so disagreements come up early, not in the last five minutes.

For an onboarding redesign, the brief might say: “We want new customers to finish setup without a support call. This covers the setup instructions and welcome flow. Pricing and account migration are out of scope.” The team still has to agree how to measure that.

• State one outcome the people doing the work can measure.
• List scope limits, fixed dates and dependencies to confirm.
• Name the decisions you need from the group, with background attached.
• Invite people who can commit, plus anyone whose work depends on them.

Give everyone a clear role

Pick a facilitator and a notetaker. The project lead explains the proposal and contributors test whether it's achievable. A decision maker settles questions within their authority. Other stakeholders can comment beforehand or review the outcome afterwards.

Check authority out loud. If nobody present can approve the scope or commit a resource, write down what needs approval and from whom. Enthusiasm isn't approval. Don't invite a crowd just so everyone hears the same presentation.

Atlassian's DACI play draws the same line. One Approver decides, and Contributors have a voice but not a vote. Name that person before the kickoff.

A 45-minute kickoff agenda

This sample suits a modest project with a pre-read. For more complex work, extend it or split it into sessions. Keep the brief on screen and update it as you decide things.

Turn a vague agreement into a first action

“We'll improve the instructions” is too broad to act on. Better: “Maya will collect three recent examples of confusing setup steps and bring a revision to Thursday's review.” Now there's a deliverable, an owner and a review point.

Keep decisions apart from investigations. “We'll test new instructions with a small group first” is a decision. “Find out whether the welcome email can link to them” is an investigation. Logging both as decisions hides the uncertainty.

Send a working record and follow through

Afterwards, share the revised brief, the decisions and a short action list. Include open questions, each with an owner and a date to revisit. Invite corrections, and make them easy to send.

At the first checkpoint, compare what happened with the kickoff's assumptions. Did a dependency change? Is the scope too big?

Update the plan where everyone can see it. The kickoff worked if people can say what they're aiming for, what they own and what's still undecided.