A project kickoff meeting brings the people involved in a project together to establish a shared understanding of its purpose, boundaries, roles, and immediate next steps. A useful kickoff tests assumptions and resolves ambiguity. It is not simply a presentation announcing that work has started.
Prepare a brief before the meeting, but do not treat attendance as agreement with every line. The meeting should reveal where the sponsor, delivery team, operations, and affected users understand the project differently.
APM's project kickoff guidance emphasizes purpose, assumptions, and ways of working. The agenda below is a suggested facilitation design, not an official project-management requirement.
What should exist before kickoff?
Bring a short statement of the problem, the intended outcome, initial boundaries, known constraints, proposed roles, and the decisions that cannot wait. If the project requires formal authorization, follow that process separately. A kickoff invitation is not a substitute for funding or approval.
Send the brief early enough for participants to read it. Ask each person to bring one assumption that could change the plan and one dependency the team may have missed. This makes preparation active rather than a request to “review the slides.”
If essential information is unavailable, name the meeting accurately. A discovery workshop may be the right next step. Calling it a kickoff does not make an undefined project ready for execution.
Who should attend?
Invite people who can explain the purpose, deliver the work, represent affected operations or users, and make the immediate decisions. Avoid both extremes: a meeting so small that it misses a critical dependency and a meeting so large that nobody can test the plan.
A sponsor may need to attend the outcome and authority discussion without joining a detailed technical handoff. A specialist may contribute asynchronously if the relevant question is explicit. Make those boundaries clear in the invitation.
Include people who will run the result after delivery. A launch that succeeds technically but has no support owner is not a complete operational plan.
A 60-minute project kickoff agenda
| Time | Conversation | Output |
|---|---|---|
| 0–8 minutes | Purpose and desired outcome | Shared problem and success signal |
| 8–18 minutes | Scope and exclusions | What is in, out, and uncertain |
| 18–30 minutes | Assumptions and dependencies | Questions that could change the plan |
| 30–42 minutes | Roles and decisions | Decision owners and escalation route |
| 42–52 minutes | First work and evidence | Immediate actions and learning steps |
| 52–60 minutes | Confirm and challenge | Decision record and unresolved issues |
Adjust the duration to the project's complexity. The timeboxes are facilitation suggestions. If a consequential disagreement cannot be resolved responsibly in ten minutes, record it and assign the right follow-up rather than forcing a superficial answer.
Ask for disagreement before asking for commitment
After the purpose statement, ask participants to write what they believe is outside scope. Compare answers. Scope disagreement often becomes visible faster through exclusions than through a broad list of intended work.
For assumptions, use prompts such as: “What must be true for this date to be realistic?” and “Which external contribution have we treated as guaranteed?” Ask people to distinguish confirmed commitments from expectations.
For roles, use actual decisions. Who can approve a scope change? Who decides whether the outcome is ready for operational use? Who resolves a conflict between the target date and a quality concern? A generic organization chart does not answer those questions.
Worked example: a customer onboarding change
Hypothetical example: a team kicks off a project to shorten customer onboarding. The sponsor expects a simpler process, engineering expects a new form, and support expects fewer incomplete requests. Everyone agrees with the phrase “improve onboarding” while imagining a different project.
The kickoff exposes the mismatch. The team rewrites the outcome as reducing avoidable follow-up during account setup, with an initial focus on one customer segment. It keeps the choice of interface open until the current handoff is understood.
A dependency discussion reveals that a required verification decision belongs to another team. Instead of treating the target date as a commitment, the project owner assigns a conversation to confirm the dependency and identify acceptable alternatives.
The meeting ends with three immediate actions: observe the current setup process, agree the decision boundary with the verification owner, and define how follow-up requests will be counted. The team has less apparent certainty but a more credible start.
Copyable kickoff decision record
Use one shared record rather than separate notes that gradually diverge:
- Problem and intended outcome: what the project exists to change.
- Current scope: included work, explicit exclusions, and unresolved boundaries.
- Constraints: required conditions and who confirmed them.
- Decision rights: decisions, owners, and escalation route.
- Assumptions: claims still requiring evidence.
- Dependencies: contribution, owner, expected date, and confidence.
- First actions: owner, output, and review point.
- Open disagreements: the competing views and how they will be resolved.
Send this record after the meeting and ask for corrections by a reasonable date. Silence should not become invented agreement on a material decision. Obtain the approvals required by your organization through the appropriate channel.
What to do in the first week
Check that the first actions actually start. A kickoff can produce a long list of owners who lack time, access, or authority. Discover those gaps before treating the plan as underway.
Resolve the assumptions with the greatest ability to change the project. Do not prioritize only the easiest research tasks. An uncertain legal, operational, or external dependency may determine whether other work is useful.
Schedule a short learning review once real work provides evidence. Use an agile retrospective to inspect the team's collaboration, and choose a simple retrospective format rather than introducing a complicated ceremony immediately.
The retrospective improvement guide can help turn early friction into a testable working agreement. Keep product scope decisions in the project record so the retrospective does not become the only place the plan changes.
Kickoff mistakes to avoid
Presenting a finished plan for ceremonial approval. If nothing can change, explain that the meeting is a briefing. Do not ask for input while hiding that all consequential decisions are fixed.
Leaving dates without assumptions. A date supported by unconfirmed availability or scope should be described as conditional. Record what must be checked.
Assigning ownership to a department. A group name can identify responsibility, but someone still needs to coordinate the immediate action and confirm acceptance.
Ending with “any questions?” Invite a specific challenge: “Which assumption in this plan is most likely to fail?” People often need a focused prompt to raise uncertainty.
Frequently asked questions
Is a kickoff the same as a project planning workshop?
Not necessarily. A planning workshop develops the plan; a kickoff establishes shared understanding and working expectations. A small project may combine them, but make the decisions and outputs explicit.
What should the kickoff presentation include?
Only material that helps participants understand and challenge the purpose, scope, roles, dependencies, and next steps. Keep detailed reference information in the shared brief rather than reading every slide aloud.
What if the project is already underway?
Run a reset kickoff around the current situation. State what has already been decided, identify which assumptions remain open, and establish the decision and collaboration rules needed from this point forward.