top of page

5 Key Elements of a Successful Project Kickoff Meeting

Updated: Mar 10


Project kickoff meetings don’t get as much attention on them in the literature as they should. They’re not a process that we practice particularly often. Take for example your issue register - you practice that all the way through a project. But you only kickoff a project once. So this might be something you do once every year or two. But it’s really important. It sets the tone. It may be the first time you’ve met your team, or the first time they’ve worked with you. First impressions count and starting something well allows it to progress smoother than starting badly. So what goes into a good project kickoff meeting?


1. Ice breaker

The team may not have worked together before, and may not have worked with you before. There will be some apprehension. They’re going to be working with you closely for the forseeable. They want to know what sort of person you are and how you’re going to run the team. To me, an ice breaker helps say “I’m human”. It signals an intent to get to know the individual people. It also says that you’re prepared to make this project a bit of fun. For those reasons, I choose an ice breaker and try to choose one that is going to be a bit of fun.


2. Open floor for questions

Next I stop for questions from the team. Lots of kickoff meetings I’ve been in leave the questions until the end. I think it’s a judgement call. If you leave the questions to the end, you might get better quality questions and you might have answered some questions during the meeting. But you may also not have enough time to properly answer all the remaining questions. For me, I prefer to get the questions up front. It helps me understand if there’s a level of understanding already in the room - which might then mean I don’t spend as much time on other things. It also iterates the message from the ice breaker that this is about ‘the team’ not ‘me’ as the Project Manager. I like to get concerns out early and doing so helps me craft the rest of the meeting. Of course, to excel at this you’ve got to be good at thinking on your feet. But I prefer this disarming and open approach to early questions. If you’re nervous, put them later in the meeting. I tend to find most questions focus on the next 3 areas, but I’m prepared to mix things up if the questions are from different areas.


3. Outcomes

I share the outcomes that the project is responsible for and why these are important. If you want my take on outcomes, read them here: https://www.linkedin.com/posts/philjacklin_heres-a-controversial-post-for-a-friday-activity-7252765815463190528-PVYB?utm_source=share&utm_medium=member_desktop. It’s important that the north star is shared and clear for the team. I really try and line the Sponsor up to present this part of the meeting too. It’s more powerful when the outcomes come from the Sponsor rather than the Project Manager. Done well, this part creates lots of discussion and leads to a good understanding of ‘why’.


4. Scope

Often, scope is not accurately defined by the project kickoff meeting, but I still prefer to include it for 2 reasons.


  • Firstly, I like the team to understand that the outcomes are defined, but the solution that is going to generate the outcome is still vague and needs their help to get to clarity. I find people want to contribute, not just be told what tasks are expected of them. It’s important to me that I set that tone early and therefore putting scope that is not fully understood in the kickoff meeting helps demonstrate that we’re all on the journey together and their input is important.

  • Secondly, there will be questions such as “are we expected to do X”, or “is Y in scope”. Presenting scope at the kickoff meeting gets these questions out early and as a Project Manager, I want ambiguity on scope to be addressed as early as possible.


5. Decision making rights

Finally, I want to talk about decision making rights. I want to talk about what rights the project team have for making calls and what calls need authority from elsewhere in the organisation. This is both to define the boundaries that are needed, as well as to show the project team that they do have decision making rights and they are expected to contribute to making decisions as the project progresses.


I know many people like to include RACI and milestones or timelines into their kickoff meetings. For me, these are things that are built together, with the project team, early after the kickoff meeting. I don’t like to have everything too well formed before I do a kickoff meeting. I am more confident that the team will produce a better RACI or milestone list than a small number of stakeholders defining it before the project is introduced to the team.

What do you think is missing? What would you put in a project kickoff meeting that isn’t listed here?

Comments


bottom of page