Get 1 month of Premium free

Use the code at checkout

00Days
00Hours
00Mins
00Secs
Claim 1 month free

BlogMeetings

How to Run a Project Kickoff Meeting

Use the kickoff to agree what done looks like, who decides what, and what could stop it. Not to present a plan. A kickoff where one person talks and everyone nods has confirmed nothing, and the assumptions that were never spoken aloud become the problems that appear in week four.

What a kickoff is for

Three things, and none of them is presenting a plan.

Agreeing what done means. Not the activity, the end state. Teams that skip this discover in week five that two people had materially different pictures of the finish line.

Establishing who decides. When there is a disagreement about scope or approach in week three, who settles it? Deciding this in advance costs a minute; deciding it during a live disagreement costs a week and some goodwill.

Finding out what could stop it. The dependencies, assumptions and resourcing problems that everyone half-knows and nobody has said out loud.

The failure to avoid

A kickoff where one person talks for forty minutes and everyone nods has confirmed nothing. Nodding is not agreement, it is the absence of an objection that nobody was given room to raise.

What to prepare

Send forty-eight hours ahead, as a document rather than slides:

  • What we think done looks like, in two or three sentences
  • Why now, and what happens if it slips
  • A draft plan with rough phases and dates, explicitly marked as a draft
  • Who is involved, and what each person is expected to contribute
  • What we already know is uncertain

The last item does more work than the rest combined. Naming your own uncertainties first gives everyone else permission to add theirs, and it stops the meeting becoming a defence of your plan.

The agenda

Sixty to ninety minutes.

  1. Agree what done looks like, fifteen minutes

    Read your definition aloud, then ask each person to say what they think will be true at the end. Actually go round.

    The differences that surface here are the ones that would otherwise appear as rework in week four. This is the highest-value fifteen minutes in the meeting.

    15 minutesGo round, do not open the floor
  2. Name who decides what, ten minutes

    Who owns scope, who owns technical approach, who signs off, and who to go to when two of those conflict.

    Write it down. Verbal agreement on decision rights evaporates precisely when it is needed, which is during a disagreement.

    10 minutesWrite it down
  3. Walk the plan and let people change it, twenty minutes

    Phases and dates, with the people doing the work saying whether the dates are plausible. Expect them to move, and change them in the room.

    A plan the team altered is a plan they own. One they were shown is one they will comply with until it becomes inconvenient.

    20 minutesChange it live
  4. Ask what would make this fail, twenty minutes

    Directly, and then be quiet long enough for the second and third answers, which are usually the real ones.

    Write each one down with a name against it. Not a risk register, just a short visible list.

    20 minutesThe question that pays for the meeting
  5. Agree the rhythm and the first step, ten minutes

    How often you will check in, where progress is visible, and what the first concrete action is with a name and a date.

    Attach the check-in to something that already exists rather than creating a new recurring meeting, following the cap in a [weekly operating rhythm](/blog/weekly-operating-rhythm).

    10 minutesFirst action, dated

Surfacing risk without a risk register

You do not need a formal process. You need people to say things they are slightly reluctant to say, which is a facilitation problem rather than a documentation one.

Ask everyone to write silently for three minutes first. What could go wrong, one thing per line. Then read them out. This removes the first-speaker anchor and gets the quieter people's concerns into the room, which is the core technique in facilitating a meeting where everyone actually speaks.

Ask the specific version, not the general one. "What are the risks?" produces generic answers. "What are we assuming about the data that might not be true?" produces real ones.

Ask about other people's availability. Most small-team projects stall on someone outside the project who was never asked whether they had capacity.

Ask what happened last time. If a similar project ran before, what went wrong is the best predictor available, and a post-mortem from that project is worth re-reading before the kickoff.

Then do the thing that makes it worth having asked: assign each named risk to a person to check, with a date. A list of risks nobody owns is a list of things you will be unsurprised by when they happen, which is not the same as being prepared.

What has to exist afterwards

Sent the same day, short:

What done looks like, in the agreed wording rather than yours.

Who decides what, in one line each.

The plan as amended, not as presented.

The risks, each with an owner and a check date.

The first action, with a name and a date.

Then make the check-ins real. A kickoff followed by four weeks of silence produces the same outcome as no kickoff, because the shared understanding decays quickly under contact with the work. The same discipline that makes meeting notes turn into action items applies, and the review point should be an existing slot rather than a new meeting.

One last thing worth doing at the end of the project rather than the start: keep the kickoff document and compare it with what actually happened. The gap between what you agreed done would look like and what done turned out to be is the most useful input into the next kickoff you will ever get.

Frequently asked questions

How long should a project kickoff be?
Sixty to ninety minutes for most small-team projects. Longer usually means a plan is being presented rather than agreed, which is the failure the meeting exists to prevent.
Who should attend a kickoff?
Everyone doing the work, whoever decides when there is a disagreement, and anyone whose cooperation the project depends on. The last group is the one most often left out and the most common source of a stall.
Should the plan exist before the kickoff?
A draft should, sent in advance. Arriving with nothing wastes the room; arriving with a finished plan means the meeting is an announcement. Send a draft and be visibly willing to change it.
What is the most important question in a kickoff?
What would make this fail. Asked directly and early, it surfaces the dependency, the assumption or the resourcing problem that would otherwise appear in week four when it is expensive.
Do small projects need a kickoff?
Anything involving more than two people or lasting more than a fortnight benefits from thirty minutes. The cost of a short kickoff is far lower than the cost of two people building different things for a week.
Danish Khan

Danish Khan

CEO & Founder, Siela

Danish Khan is the CEO and founder of Siela, an AI-native workspace where teams and AI agents run CRM, meetings, tasks, and daily work together on one shared context layer.

Connect on LinkedIn

Published