Posted on
5 minutes to read
Project kickoff meetings
Some tips based on my experiences running successful project kickoff meetings.
I've been involved in leading and project-managing many large scale editorial website redesigns over the years. Here's a structure that I've developed that tends to leave people feeling like things have got off to a good start.
Why run a kickoff meeting?
The main purpose of a kicking meeting is to get everyone involved in a project on the same page. That means getting stakeholders to explain the project goals as they see them and to begin exposing people working on the project to those ideas.
It may also be the first time people have met or worked together so it's a good chance for everyone to put a face to a name.
Consider your guest list
There is no right answer to this one, but consider who you invite.
You may want every stakeholder plus every developer and designer working on the project to meet up for maximum coverage and inclusion. If you can manage a group that large that isn't a bad thing.
You may wish instead to invite a few key stakeholders and one or two key members from your own team.
In my experience if the teams have never met or interacted before then getting the entire group together works well. If you've worked with the stakeholders previously and they've been to this type of meeting before you can run the meeting with a smaller guest list.
Don't be afraid to leave people off the guest list if they have a habit of railroading discussions. These meetings work best with people being open and relaxed.
Explain what the purpose of the meeting is
This is a good point to let everyone know that the meeting needs to stay broad-brushed.
It is important that people on your team understand that kickoff meetings are a listening exercise. Ensure people on your team that are technical by nature do not start talking about implementation details. This can come later.
It is important for other stakeholders to understand that this is their opportunity to give the team some high-order details about what is important to them. What business goals exist?
Kickoff meetings (or meetings in general) can tend to flag after the first hour, so I try and keep kickoff to an hour and half at a maximum.
Introduce everyone
Make sure everyone knows who everyone is. Get everyone to introduce themselves and say what their role is.
You can also choose to take this opportunity to get each person to answer the question: "What does a successful redesign look like to you?"
Start with higher-order goals
Encourage everyone to talk about the wider goals of the project. They should be very general at this point.
Allow people time to provide background context
Allow people to provide some background information to help you understand the history of how the project came to be.
Ask stakeholders to assume the team have no prior knowledge of the area being discussed. It can be very easy for people to assume the team has the same experience or knowledge of a given product or market.
A helpful metaphor is to think about the "fog of war" -- a good kickoff meeting will lift the fog and leave everyone with a clear view of the playing field.
The time for deep dive on technical specifics isn't now
Very enthusiastic people on technical teams may be very keen to deep-dive into problem solving and try to talk about specific implementation ideas. Gently remind them that kickoff meetings are for problem discovery, not for solutions.
Explain the general project approach, structure, and timelines
If you have a project method or process that your team follow then a kickoff meeting is a great time to tell your stakeholders about it. You can also re-affirm (or negotiate!) the broad timeline for the project.
Give every stakeholder time to express their goals
Stakeholders should be encouraged to talk about their specific goals for the project.
Be mindful that stakeholders from different departments may have competing or colliding goals. These conflicts don't need to be resolved right away but they should be identified and noted down for follow up.
Give everyone on your team time to ask their own questions
It is important that a single person drives the meeting agenda, but be mindful of dominating the exchanges. Notice any passive or quiet attendees and encourage them to ask questions.
Give people concrete next steps
Explain what will happen next. Normally it will be a case of scheduling more requirements gathering sessions, but everyone should leave the meeting knowing what happens next. Giving a timeline for next contact will make people feel reassured.
Follow up with notes
Assign someone in the meeting to be a scribe for the group but also ensure everyone takes their own specific notes that are relevant to them. Designers may pick up on things developers don't, and vice versa.
In closing
If the kickoff meeting has been a success stakeholders should leave with a feeling that their goals and desires have been heard and noted. Members of your own team should leave feeling that they have a solid understanding of the high-level goals of the project and that they have a growing understanding of the background history and context as to why the project exists. Everyone should leave understanding what will happen next.
