On this page
A project kickoff is the meeting where the person doing the work and the people it is for agree what is being built, what done looks like, who decides, and how the work will run, before any of it starts. To run one: send a short pre-read two days ahead, make sure the person with final say attends, open with why the project exists, agree what done looks like, read the scope out loud including what is out, name who decides and who does what, walk the timeline to the first delivery, set the working rules for messages, approvals and changes, and close on risks and actions. Then send a written summary within 24 hours. The meeting is for making decisions, not presenting a plan.
Most project kickoffs feel productive and decide nothing. Everyone nods through a timeline, someone says it all sounds great, and three weeks later you discover the client thought the copywriting was included and the person who actually signs off never saw the plan.
This guide treats the project kickoff as what it should be: a short meeting that ends with specific decisions written down. It covers the steps, a kickoff agenda and a summary you can copy, a worked example, the questions to ask, and the mistakes that cause most of the trouble later. If you work with clients, the kickoff is stage five of a wider client onboarding process, and it only works if the earlier stages are done first.
How to Run a Project Kickoff Meeting in 9 Steps
Steps 1 and 2 happen before the meeting, steps 3 to 8 are the meeting itself, and step 9 happens the day after.
- Send a pre-read two days before. One page: what you understand was agreed, a draft timeline, and the questions you need answered. The meeting then confirms or corrects a document instead of starting from memory, and nobody hears the scope for the first time on the call.
- Make sure the person with final say attends. Not their assistant, not the colleague who will "pass it on". If the decision-maker cannot come, move the kickoff. A decision made without them is a draft.
- Open with why the project exists, in their words. Ask the client what problem this solves and what changes for them when it is finished. Then repeat it back. You will refer to this answer every time a request drifts away from it.
- Agree what done looks like. One sentence that someone outside the project could check: "the new site is live, takes orders for all three product lines, and the old site redirects to it." Done is a state you can see, not a feeling.
- Read the scope out loud, including what is out. Go through what is included, then name at least three things that are not. Out of scope is the part people skip, and it is the part that prevents the argument in week four.
- Name who decides and who does what. One person with final say for each kind of decision, and the client's own tasks with dates attached: content, logins, approvals. Most project delays are the client's tasks, so they belong on the timeline too.
- Walk the timeline to the first delivery. Milestones, approval windows, and the date the client sees something real. Keep the first delivery close, ideally within a week. The silence between kickoff and first output is where confidence drains.
- Set the working rules. Which channel you use, how fast each side replies, how long approvals take, and what happens when someone asks for something new. Agreeing the change rule now, while nobody is asking for anything, is far easier than inventing it during a disagreement.
- Close on risks, open questions and actions, then send the summary within 24 hours. List what could delay the project, what was not decided, and who does what next. Write it up the same day or the next: decisions, owners, dates, and anything left open. After a day, two people remember two different meetings.
Aziz's take: A good project kickoff should feel slightly boring. Nobody presents anything; you go through a one-page document line by line and change the parts that are wrong. The exciting version, with a deck and a big vision, is the one most likely to produce a scope argument in week two, because it felt like agreement without anything specific being agreed.
A Project Kickoff Meeting Agenda You Can Copy
Sixty minutes is enough for most client projects with two or three people on the call. For a small project with one decision-maker, the same agenda fits into thirty minutes if the pre-read went out and was read. The time budget on each item is what keeps it from running over; the meeting agenda template explains how to set one for any meeting.
How to use this
Fill in
- Every highlighted value. The order stays as it is.
- Send it with the pre-read two days ahead, not at the start of the call.
- For a small project, halve each time budget and run it in 30 minutes.
Check before the meeting
- The person with final say has accepted the invite.
- Your scope list names at least three things that are out.
- You know the date of the first delivery you will propose.
What goes wrong
- Spending the first twenty minutes on introductions and a slide deck.
- Ending on "any questions?" and taking silence as agreement.
- Leaving the change rule for later, when someone is already asking for a change.
The Questions to Ask in a Kickoff Meeting
"Any questions?" at the end of a kickoff produces silence, and silence is not agreement. Specific questions produce answers. These are the ones worth asking, grouped by what they settle.
About the outcome
- What problem is this project solving, and what happens if it is not solved?
- What does finished look like, in a way someone else could check?
- How will you judge whether it worked, six months from now?
About decisions
- Who has final say on the design, the content and the budget? Is that one person or several?
- Is there anyone not on this call who could stop or change the project?
- How quickly can you approve work when we send it?
About constraints
- Is the deadline fixed, and what happens if it moves?
- What has been tried before, and why did it not work?
- What do you already have that we must use: brand files, systems, existing content?
About working together
- Where should messages go, and when do you not want to be contacted?
- How do you prefer to give feedback: written comments, a call, or both?
- What would make you unhappy with this project, even if everything is delivered?
The last question is the most useful one on the list. Clients rarely volunteer it, and the answer is usually something no scope document would have caught.
A Worked Example: Kicking Off a Website Project
A freelance web designer is starting a new online ordering site for a bakery owned by two partners. The figures and names are illustrative, but the decisions are the ones every client project has to make. The pre-read went out on Monday 12 October; the kickoff is on Wednesday 14 October, with both partners on the call.
| Agenda item | What was decided | Why it matters later |
|---|---|---|
| Why | Phone orders take two hours a day and get written down wrong. | Any request that does not reduce phone orders can wait for phase two. |
| Done | Site live by 13 November, taking orders for cakes, bread and catering, old site redirected. | A finish line both sides can check, not "when it looks right". |
| Out of scope | Copywriting, product photography, a delivery booking system. | The photos question came up in week three. It was already answered. |
| Final say | Design and budget: Partner A. Product list and prices: Partner B. | Two owners with equal say on everything is how a project stalls. |
| Client tasks | Hosting login by 16 October; product list and prices by 20 October. | The designer cannot be late because a login arrived late. |
| First delivery | Homepage design on 21 October, five working days after the kickoff. | The client sees something real inside a week. |
| Working rules | Email only; replies within one business day; approvals within two. | No WhatsApp voice notes at 10pm becoming instructions. |
| Change rule | New pages or features are quoted separately before work starts. | When the delivery booking idea returned, it was a quote, not a fight. |
| Open question | Whether to take payment online or on collection. Partner A to decide by 23 October. | Undecided items written down get decided. Unwritten ones get assumed. |
The moment the kickoff earned its hour was the scope item. Partner B assumed product photos were included, because the designer's portfolio was full of them. Reading the out-of-scope list aloud surfaced it on day one, when the fix was a referral to a photographer. Found in week five, it would have been a delayed launch and an argument about what had been promised.
The decision that saved the most time was splitting final say between the partners by area. Without it, every design choice would have needed two approvals and every disagreement between the owners would have landed on the designer.
The Kickoff Summary: What to Send Within 24 Hours
The summary is the part of a kickoff that people remember to do and then do badly. A good one lists decisions, not discussion, and it includes what was not decided. Here is the one from the example, ready to adapt.
How to use this
Fill in
- Every highlighted value, from your notes on the call.
- Write decisions, not a record of who said what.
- Send it within 24 hours, to everyone who attended.
Check before sending
- Every action has one owner and a date.
- Anything not decided is listed, with who decides it and by when.
- It ends by asking for corrections, not approval.
What goes wrong
- A summary that lists topics discussed, so nothing in it can be pointed at later.
- Leaving out the undecided items, which then get assumed by each side differently.
- Sending it a week later, when nobody remembers the meeting well enough to correct it.
What Goes Wrong in Project Kickoffs
Almost every kickoff that fails does so in one of these ways. None of them is about running a bad meeting. Each one is a decision that was left unmade.
- The decision-maker was not there. The real kickoff then happens later, between the client and their boss, without you. You find out what was decided when the feedback contradicts everything you agreed.
- It was a presentation, not a decision meeting. A deck and a vision get nods. Nods are not commitments, and nothing from a presentation can be pointed at three weeks later.
- Out of scope was never said out loud. Everyone assumed the obvious extras were included or excluded, and each side assumed differently.
- Silence was taken as agreement. Ending on "any questions?" invites nothing. Asking "is there anything on the out-of-scope list you expected to be in?" invites the conversation you need.
- No written summary, or a summary of discussion instead of decisions. Without one, the project runs on two memories of the same hour, and memory always favours its owner.
- Work started before the paperwork. A kickoff held before the agreement is signed and the deposit has cleared feels keen and is risky. The payment milestones belong in place before the first meeting, not after it.
Most of these show up later as a difficult client. Usually the client is not difficult; the kickoff left a gap, and the gap filled with assumptions.
Aziz's take: If you only change one thing, put the out-of-scope list in the pre-read and read it aloud on the call. It takes two minutes, it feels awkward the first time, and it removes the single most common argument in client work: the one about what was included.
Who Should Attend, and Client vs Internal Kickoffs
Keep the list short. A project kickoff needs the person doing the work, the person with final say, and the person who will deal with you day to day if that is someone else. Add anyone whose approval could block the project, such as the person who controls the budget or the website login. Everyone else can read the summary.
A client kickoff is the version this guide describes: two sides agreeing the terms of the work. An internal kickoff, when you bring in a freelancer or subcontractor for part of a project, uses the same agenda with two changes. The scope item becomes the handoff: exactly what you will give them, and exactly what you expect back. And the working rules matter more, because the subcontractor never hears from the client directly, so every change has to travel through you. If your projects run on a repeatable set of steps, they belong in your wider business operations, so the next kickoff starts from a document rather than from scratch.