Project kickoff meeting checklist for new teams
A project kickoff meeting is the first time the whole team sits together to agree on what the project is, who does what, and how work will move. Keep it short, usually 60 to 90 minutes. Send the agenda a day early. End with written actions that have names and dates beside them.
This checklist works for a new product, a regional rollout, an office move or an internal system change. Use the parts that fit and skip the rest.
Why the first meeting matters
Most early confusion comes from small gaps. One person thinks the work is a pilot. Another thinks it is the full launch. A third does not know who can approve spending. A kickoff meeting closes those gaps while changing course is still cheap.
Formal methods build in the same idea. PRINCE2 starts with a "starting up a project" step. The team is appointed, including an executive and a project manager, and a project brief is written. Later, the project initiation documentation is assembled and the business case is refined. You do not need the full method to borrow the habit: agree on the basics in writing before the real work begins.
Source: summary of PRINCE2 at en.wikipedia.org/wiki/PRINCE2.
Agree on goals and success
Start with why the project exists. Say it in two or three sentences that anyone on the team could repeat. Then list what success looks like in numbers or clear yes and no checks. "Launch in three offices by the end of the quarter" is clear. "Improve the process" is not.
- State the reason for the project in plain words.
- Write down two to four success measures.
- Name the deadline and say whether it can move.
- Name the budget limit, if there is one.
PRINCE2 calls the business case the most important document, and it is updated at every stage so the project keeps making sense. A one page version of that idea is enough for most teams. If the reason for the project stops being true, say so and stop early.
Source: summary of PRINCE2 at en.wikipedia.org/wiki/PRINCE2.
Settle roles and decision rights
List every person and what they own. Separate the role from the person. One person may hold two roles on a small team, and that is fine if it is written down. What matters is that every task has one owner.
Cover these four roles first:
- Sponsor: the person who backs the project and decides if it continues.
- Project lead: the person who plans the work and tracks it day to day.
- Team members: the people who do the work, each with named tasks.
- Reviewers or approvers: the people who sign off on key results.
PRINCE2 draws a similar line. A project board directs the project manager and decides whether to authorise the next stage, while the project manager hands out work to team managers. For multi-country teams, add time zones and working languages to the role list so nobody is surprised later.
Source: summary of PRINCE2 roles at en.wikipedia.org/wiki/PRINCE2.
Fix scope and name the risks
Scope is the edge of the project. Write what is in and what is out. The "out" list matters most, because that is where later arguments start. If a request arrives that is not on the "in" list, the team knows to treat it as a change, not as a small favour.
Next, ask the room one question: what could stop us? Collect answers without debate. Then pick the top five and give each one an owner and a first response. Keep them in a simple risk list that the team reviews on a set day.
- What is in scope, and what is clearly out?
- Which tasks depend on other teams or suppliers?
- Which risk is most likely, and which would hurt most?
- Who watches each risk, and when do we look again?
PRINCE2 supports this with a risk management approach and a risk register. The Project Management Institute also moved its PMBOK Guide, seventh edition, published in 2021, toward a set of 12 principles in place of the older knowledge areas. Different words, same advice: look for trouble early and keep a list.
Sources: summary of PRINCE2 at en.wikipedia.org/wiki/PRINCE2; summary of the PMBOK Guide at en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge.
Set the communication rhythm
Decide how the team will talk before it gets busy. Pick one place for questions, one place for files and one weekly meeting time. Say how fast people should reply and what counts as urgent.
- A weekly check in of 30 minutes, with the same three questions: what is done, what is next, what is blocked.
- A short written update to the sponsor on a fixed day.
- One shared tracker that shows owners and due dates.
- A rule for decisions: who decides, and by when.
For teams spread across Asia-Pacific time zones, rotate the meeting time now and then so the same people do not always join late at night. Write meeting notes in simple English and share them within a day.
Agree the first steps before you leave
Spend the last ten minutes turning talk into action. Go around the room and ask each person to state their first task and the date it will be done. The project lead writes these down and sends them the same day.
- Three to seven first tasks, each with one owner and one date.
- The date and time of the next meeting.
- A link to the notes, the risk list and the tracker.
- Open questions, each with a named person who will find the answer.
Check in with the team after one week. If people are unsure about goals, roles or scope, hold a short follow up. A fifteen minute fix in week one is cheaper than a month of rework.
Sources
Wikipedia, "PRINCE2", en.wikipedia.org/wiki/PRINCE2. Wikipedia, "Project Management Body of Knowledge", en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge.