The Project Kickoff Checklist: Start Right or Restart Later

Most projects that fail were already failing on day one. The team just didn't find out until week six, when a stakeholder nobody consulted vetoed the approach, or two departments discovered they had signed up for different definitions of "done." A kickoff is not a ceremony. It is the cheapest moment in the entire project to fix problems, because nothing has been built yet and nobody has to defend sunk cost.

This is the checklist we use, in the order we use it, with the scripts and artifacts that make each step real. It assumes a project of roughly four weeks to six months with three or more contributors and at least one stakeholder who is not on the delivery team. Smaller than that, run a trimmed version. Bigger than that, run this per workstream.

Why kickoffs fail before they start

The most common kickoff mistake is treating the meeting as the kickoff. The meeting is the last step. The work happens in the week before it: the sponsor conversation, the stakeholder map, the draft success criteria. If you walk into a kickoff meeting planning to discover the goal together, you will get a pleasant conversation and a vague summary email, and you will re-litigate scope for the next two months.

Three failure patterns show up over and over:

1. The assumed sponsor. The person paying for the project (in budget or political capital) never explicitly agreed to what they were buying. Someone senior said "we should really fix onboarding" in a meeting, and a project materialized around the comment. Four weeks in, the "sponsor" sees the plan and says "that's not what I meant."
2. The missing veto. Legal, security, brand, a regional lead — someone with the power to stop the project wasn't in the loop. They exercise that power late, at maximum cost.
3. The unmeasured goal. "Improve the checkout experience" survives the kickoff intact because it offends no one. Six months later, nobody can say whether the project worked, so it never really ends.

Every item on this checklist exists to kill one of those three patterns early.

Step 1: The sponsor conversation

Before anything else, get 30 minutes with the actual sponsor — the person whose budget, headcount, or reputation is on the line. Not their delegate. Ask four questions and write down the answers verbatim:

• "What does this project make possible that we can't do today?" This surfaces the real goal, which is often one level above the stated one. "Rebuild the reporting pipeline" is often really "stop the CFO from asking why our numbers differ from finance's."
• "How will you personally judge whether this succeeded?" Sponsors often carry a private success criterion they've never said out loud. You want it out loud, in the doc, before it becomes a surprise at review time.
• "What's the deadline, and what happens if we miss it?" Deadlines split into three types: real (a regulatory date, a contractual commitment, a launch event), directional (a quarter target someone committed to upward), and decorative (a date someone picked to create urgency). Your planning posture is completely different for each, so find out which one you have. It's fine to ask directly: "Is this date connected to anything external, or is it a target we set ourselves?"
• "Who can stop this project, and who will be annoyed by it?" Sponsors usually know the political terrain better than the delivery team. Get names.

A realistic exchange, from a marketing-site rebuild kickoff:

PM: "How will you judge whether this succeeded?" Sponsor: "Honestly? If sales stops complaining that the site embarrasses them in front of prospects." PM: "Can we make that measurable — say, sales sign-off on the top ten pages before launch, plus a demo-request conversion target?" Sponsor: "Sign-off, yes. I don't want conversion in the success criteria — too many variables we don't control."

That two-minute exchange just changed the project's definition of done and removed a metric the team would otherwise have been judged against unfairly. That's what the sponsor conversation is for.

Step 2: Map the stakeholders — all of them

A stakeholder map is a table, not a diagram. Build it in a shared doc or a table board so it stays current. For each person or group, capture five columns:

Stakeholder	Role in project	Power	Interest	Engagement plan
Dana (VP Sales)	Sponsor	Decides	High	Weekly async status + biweekly 15-min call
Priya (Legal)	Veto on claims/copy	Can block	Low	Review milestone at content-complete; 5-day SLA agreed
Support team	Affected users	None formally	High	Rep in kickoff; feedback channel; early access
Marco (Brand)	Approves visual direction	Can block	Medium	Approves at design milestone; consulted on wireframes
Finance	Pays vendor invoices	Process gate	Low	PO raised before kickoff; invoice schedule shared

Two rules make this table useful instead of decorative:

• Every "Can block" row needs a dated touchpoint. A veto-holder discovered in week one costs an email. The same veto-holder discovered in week nine costs a restart. Ask each blocker directly: "At what point do you want to see this, and how long do you need to respond?" Write both answers into the plan.
• Distinguish decision-makers from opinion-havers explicitly. The kickoff is the right moment to say, kindly and in front of everyone: "Dana decides on scope trade-offs. Marco approves visual direction. Everyone else's input is genuinely wanted and genuinely advisory." Teams that skip this sentence spend the project treating every comment as a change request.

If your organization uses DACI or RAPID, run the assignment now, not when the first conflict hits. One decider per decision type. If you can't name the decider for a category of decision, that's not a small gap — that's a predictable future stall, and the kickoff is when you escalate it.

The forgotten stakeholders

Run this prompt list against your map, because these are the groups that most often surface angry in week six: support (who will field the questions), sales (who may have promised something), the data/analytics team (who owns the metrics you'll claim), IT or security (who gate anything touching access or vendors), whoever ran the last attempt at this project, and any team whose roadmap your project's output lands on. You don't need them all in the meeting. You need them all in the table.

Step 3: Write success criteria that can fail

A success criterion that cannot fail is decoration. "Improve internal communication" cannot fail; "reduce the weekly all-hands from 60 to 30 minutes and move status reporting fully async by March 31, with 80%+ weekly check-in completion" can fail, which is exactly what makes it useful.

Write three to five criteria, no more. For each, force four properties:

1. Measurable or verifiable. A number, a date, or a named person's sign-off. "Sales leadership signs off on the top ten pages" is verifiable without being a metric.
2. Time-bound. Success by when? "Eventually" hides failure indefinitely.
3. Owned. One name attached to tracking it — not to achieving it alone, but to knowing its current state at any moment.
4. Honest about baseline. If you're claiming a 20% improvement, write down today's number in the kickoff doc. Teams that skip the baseline discover at the end that nobody recorded where they started, and the whole criterion collapses into vibes.

Just as important: write the non-goals. Two or three explicit sentences about what this project will not do. "We are not redesigning the pricing page." "We are not migrating historical data before v1." Non-goals are the single most effective scope tool you have, because they convert the fuzzy edge of the project into a bright line people can point to when scope creep arrives — and it always arrives wearing the costume of a small, reasonable request.

Step 4: The communication plan

Most project conflict is not disagreement — it's surprise. A communication plan is a table that eliminates surprise by answering, in advance: who hears what, where, and how often. Keep it to half a page:

Audience	What they get	Where	Cadence	Owner
Delivery team	Standup + blockers	Async check-in room	Daily	Whole team
Sponsor	Status: RAG, progress, risks, asks	Status room / status doc	Weekly, Fridays	PM
Stakeholder group	Milestone announcements	Feed post / email	At each milestone	PM
Company	Launch comms	All-hands + announcement	At launch	Sponsor

Three decisions matter more than the rest:

• One channel per audience, stated out loud. The failure mode is status scattered across a Slack thread, a deck, and three DMs, so every stakeholder has a different picture. Pick the single source, link it everywhere else. Teams running their reporting in a dedicated status room with standing questions and RAG goals — the model we describe in status reports people actually read — get this for free, because the room is the single source and the history is the timeline.
• Pull over push for detail. The weekly status is a push: short, skimmable, honest. Everything deeper — the board, the specs, the decision log — is pull: always current, linked from the status, never emailed as attachments that rot on arrival.
• Agree response-time expectations now. "Reviews returned within three working days; blockers flagged with @mention get same-day response." If your team has a communication charter, inherit its defaults and note only the exceptions.

Step 5: Risks — run a pre-mortem, not a brainstorm

Asking "what are the risks?" in a kickoff gets you polite genericism: "timeline risk," "resourcing risk." Run a pre-mortem instead. The prompt: "It's six months from now. This project failed badly enough that we're embarrassed. Write down what happened." Give people five silent minutes to write before anyone speaks — silent writing roughly doubles the number of distinct risks surfaced, because it stops the first loud answer from anchoring the room.

Then consolidate into a risk register with four columns: risk, likelihood (H/M/L), impact (H/M/L), and — the column everyone skips — the early-warning sign and the named owner watching for it. "Vendor API delays" is a poster. "Vendor API delays — warning sign: sandbox access not granted by Nov 21 — owner: Sam — mitigation: fallback to CSV import for v1" is a plan.

Give dependencies their own pass, because cross-team dependencies are the most reliably underestimated risk category in project work. For each one, capture what you need, from whom, by when, and what you'll do if it slips — then go get actual agreement from the other team, not an assumption. We've written a full method for this in managing dependencies before they manage you; at kickoff, the minimum bar is a named contact and a confirmed date for every external dependency on the critical path.

Cap the register at the top eight to ten risks. A forty-row register is a filing cabinet; nobody reviews it, so it protects no one.

Step 6: The kickoff meeting — a 60-minute agenda

Everything above happens before the meeting. The meeting's job is alignment and commitment in front of witnesses, not discovery. Send the kickoff doc 48 hours ahead with a one-line instruction: "Read before the meeting; we'll spend the time on questions and gaps, not a walkthrough."

The agenda, timed:

Time	Segment	What happens
0:00–0:05	Why this, why now	Sponsor — not the PM — states the goal in their own words. Two minutes of sponsor conviction is worth twenty slides.
0:05–0:15	Success criteria & non-goals	PM walks the three to five criteria and the non-goals. Ask explicitly: "Does anyone define success differently?" Silence now is agreement later.
0:15–0:25	Plan & milestones	Milestone-level only. Dates, sequence, the one or two dependencies that scare you. Not a task-by-task tour.
0:25–0:35	Roles & decisions	Who decides what, who approves at which milestone, who is advisory. Name the decider for scope trade-offs out loud.
0:35–0:45	Pre-mortem readout & open risks	Top risks with owners. Invite the room to add the one you missed — someone always has it.
0:45–0:55	Working agreements & comms	Channels, cadence, response expectations, meeting rhythm.
0:55–1:00	Explicit commitment	Go around the room: each named owner confirms their part and their first action. Corny, and it works — public commitment measurably outperforms silent nodding.

Two facilitation notes. First, if a fundamental disagreement about the goal surfaces mid-meeting, stop the agenda and take it — a kickoff that ends in "we discovered we don't agree" is a successful kickoff, because that discovery just got six weeks cheaper. Second, assign a note-taker who captures decisions and questions only, not transcript; decisions go into the kickoff doc the same day.

Step 7: The artifacts you leave behind

A kickoff that lives in people's memories decays in about two weeks. Leave behind five artifacts, each with a permanent home and an owner:

1. The kickoff one-pager — goal, success criteria, non-goals, milestone dates, roles. One page, honestly. This is the document you'll re-send every time someone joins mid-project, which is also why it must stay current.
2. The stakeholder map and comms plan — the tables from steps 2 and 4.
3. The risk register — reviewed briefly at whatever weekly rhythm you set; a register that isn't on a recurring agenda is already dead.
4. The decision log — starts empty. Every scope call, trade-off, and approval gets a dated entry with who decided and why. Six months from now this log is the difference between "why on earth did we do it this way?" and a thirty-second answer.
5. The working board — the actual backlog or plan, seeded with at least the first milestone's work, so the project starts moving the day after kickoff, not "once we get set up."

Where these live matters less than that they live together. Teams on Openbook typically spin up a single project space for this: a Docs room holding the one-pager and decision log, a Kanban or Gantt room for the plan, and a Project Status room whose standing questions and RAG goals become the weekly report — so the kickoff artifacts and the running project share one address instead of scattering across five tools. See what the rooms cover on the features page if you want the concrete tour.

The checklist itself

Print this, or paste it into your project doc and check it off for real:

Before the meeting

• Sponsor conversation done; their success definition captured verbatim
• Deadline classified: real, directional, or decorative
• Stakeholder table built; every "can block" row has a dated touchpoint and agreed review SLA
• Decision rights assigned — one named decider for scope trade-offs
• Three to five success criteria drafted, each measurable/verifiable, time-bound, owned, baselined
• Non-goals written (at least two)
• Comms plan table drafted: audience, content, channel, cadence, owner
• Dependencies listed with named contacts and confirmed — not assumed — dates
• Kickoff doc sent 48 hours ahead

In the meeting

• Sponsor states the why in their own words
• Success criteria and non-goals confirmed — disagreement invited explicitly
• Milestones and scary dependencies walked
• Roles and decision rights stated aloud
• Pre-mortem run (silent writing first) or readout reviewed; top risks owned
• Working agreements confirmed
• Round-the-room commitment; first actions named

Within 48 hours after

• One-pager updated with meeting outcomes and posted to the permanent home
• Decision log created with kickoff decisions as entries one through n
• Board seeded with milestone one's work, owners assigned
• First weekly status scheduled and its channel announced
• Risk register on a recurring agenda

The first two weeks: where kickoffs go to die

The kickoff's real test is week two. Watch for three signals that the alignment is already eroding:

• Status silence. If the first weekly status slips ("nothing much to report yet"), the reporting habit dies before it forms. Ship the first status on schedule even if it's three sentences — the cadence is the product.
• Ghost stakeholders. A "can block" stakeholder who hasn't acknowledged their scheduled touchpoint is a live risk. Chase the acknowledgment now, in week one, while chasing is cheap.
• Scope whispering. The first "while you're in there, could you also…" arrives within days. The answer is the non-goals list plus a standard sentence: "That's out of scope for this project — I've logged it, and Dana can trade it in if she wants to drop something." Scope changes are fine; silent scope absorption is how four-week projects become four-month projects.

Then, at the end of milestone one, run a 20-minute checkpoint against the kickoff one-pager: are the success criteria still the right ones? Any register risk upgraded or retired? Any decision made outside the log? Projects drift; the teams that stay pointed are the ones that re-read their own kickoff.

Start the next one right

You don't need permission to run a better kickoff — you need a week of prep and the discipline to do the sponsor conversation first. Take the checklist above, run it on your next project exactly as written once, then trim what your context doesn't need. Most teams find the pre-mortem and the non-goals list alone pay for the whole exercise.

If you want the kickoff artifacts, the plan, and the weekly status living in one place instead of five tabs, Openbook gives a project team a single space with docs, boards, and async status rooms built in — free to start, set up in an afternoon. Your next kickoff could be the last one you run from a scattered folder of decks.