GUIDE

How to Run a Project Kickoff

A kickoff happens once, at the start, and its only job is to make sure everyone leaves the room agreeing on the same scope, the same roles, and the same way of finding out what's happening next.

What a kickoff is for

A project kickoff is the meeting where a project stops being an idea in someone's head and becomes a shared understanding among the people who will do the work. It happens once, near the beginning, not daily and not weekly, and that's what separates it from a standup or a sprint planning session, both of which are recurring ceremonies inside a project that has already started.

Done well, a kickoff produces three durable outputs: everyone agrees on what's actually being delivered, everyone knows who decides what, and everyone knows how they'll find out about progress and problems without having to ask. Done badly, it's forty-five minutes of a slide deck nobody remembers a week later, followed by the same confusion the kickoff was supposed to prevent.

Alignment

What has to leave the room settled

A kickoff that covers everything except these five things has covered the wrong things.

The success definition

What "done" looks like, described concretely enough that two people wouldn't disagree about whether it's been reached. "Improve the checkout flow" is not a success definition. A conversion-rate target with a measurement window is.

The boundary of scope

Not just what's in. What's explicitly out, and said out loud rather than left implicit. Unstated exclusions are where scope creep starts, because nobody agreed they were exclusions in the first place.

Who decides what

Not everyone needs to agree on everything. Naming who has final say on scope, on design, and on schedule trade-offs prevents the same decision being re-litigated by whoever's in the room that day.

How status will travel

Where people will look to find out how things are going, and how often it'll be current. Agree this now, or it gets improvised later as a rotation of ad hoc emails and hallway updates.

Named risks and dependencies

What could plausibly derail this, and what this project is waiting on from someone else. Risks surfaced at kickoff are cheap. The same risks discovered in week six are not.

Where decisions get written down

Not the kickoff deck itself. Decisions made after it. If there's no agreed place for that, every later disagreement becomes "I don't remember it that way."

Who should be in the room

Smaller than people assume. A kickoff with twenty attendees is usually a kickoff where fifteen people sit quietly through an hour of content that applies to five of them. The people who need to be there are the ones with a decision to make or information nobody else has: the person who owns the outcome, the people doing the core work, and anyone whose team this project depends on or affects.

Stakeholders who just need to be informed don't need a seat. They need the output of the meeting, which is why writing decisions down matters more than who attended. A kickoff that tries to be both an alignment session and a broadcast announcement usually does neither well.

A workable agenda shape

Open with why the project exists and what success looks like: five minutes, and resist the urge to make this a full business case. Move quickly into scope, and spend real time on the boundary rather than the contents, since the contents are usually already understood and the boundary usually isn't. Cover roles and decision rights explicitly, even when they feel obvious to the people who already know each other. Obvious to two people is not the same as agreed by six.

Leave meaningful time (not five minutes at the end) for risks and dependencies, and ask directly: what would have to go wrong for this to miss its date? People are more forthcoming about risk when asked this way than when asked "any concerns?", which tends to produce silence in a room full of people who don't want to be the pessimist.

Close by confirming the mechanics: where the board lives, who updates it, how often, and where the next update will come from. This is the part most kickoffs skip, and it's the part that determines whether the alignment achieved in the room survives past week one.

The slide-deck trap

The most common way a kickoff fails is by being a presentation rather than a working session. One person talks, everyone else listens, questions get asked at the end if there's time, and the meeting closes with the illusion of alignment because nobody objected out loud. Silence in a kickoff is not agreement. It's frequently people who didn't fully follow, or who disagree but don't think the meeting is the place to say so.

The fix is structural: build in moments where the room has to produce something, not just receive it. Ask people to state the scope boundary back in their own words. Ask "what would make this fail" and wait through the uncomfortable pause rather than filling it yourself. A kickoff that only ever flows one direction, from presenter to audience, has not actually tested whether anyone agrees with what was said.

Before you close the meeting, check

  • Could two attendees independently write the same one-sentence success definition?
  • Is there at least one thing everyone agrees is explicitly out of scope?
  • Does everyone know who has final say if a scope disagreement comes up later?
  • Has at least one real risk been named out loud, not just implied?
  • Does everyone know where to look for status without messaging a person?

If the answer to the last one is "they'll ask in the team channel," that's not an answer. It's the exact problem the kickoff was meant to prevent from becoming the default.

Where the decisions actually live afterward

The single biggest predictor of whether a kickoff's alignment survives contact with week three is whether the decisions made in the room get written down somewhere people will actually find them again: not in the kickoff deck, which gets closed and forgotten, but next to the work itself. ShipSprint keeps a built-in wiki attached to the project, with page history, so "why did we decide to exclude that" has a findable answer instead of turning into a Slack search six weeks later. Whatever tool you use, the principle holds: a decision that only lives in someone's memory of the kickoff is a decision that will get re-argued.

FAQ

Common questions

Sixty to ninety minutes for most projects. Under forty-five and you're probably skipping risk discussion; over two hours and attention has usually left the room regardless of agenda quality. Split a large or ambiguous project into a smaller working kickoff first and a broader one once scope is clearer.

Keep reading

Related pages

See it on your own work.

A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.

14-day full-access trial · sample project included · no card required