How to Kick Off a Project: A Practical Starter Guide

In my last post, I explained what a kickoff meeting is, why this type of meeting is such a critical part of the process for a smooth and efficient project, and why I think even your meeting-averse coworkers will eventually see how putting in the time for a project kickoff will benefit both the project and them personally.

There are many ways to run a kickoff meeting, but if this is a project tool you and your organization have never used, this post will give you everything you need to lead your first kickoff meeting successfully.

Is this project a good fit for a kickoff?

While I advocate for kickoff meetings in most situations, there are a few exceptions:

When almost everything about the project is the same as a project the team has done multiple times before, and there is only one or maybe a small handful of key differences. Deciding the magnitude of the differences is a judgment call, but I’d recommend you ask yourself, “Are the new parts of this project likely to be misunderstood or raise questions if they’re explained to the team in writing?” If you think the answer is no, then I would skip the meeting and kick off the project with an email or an instant message.

If the project itself is so small as to not be very complex. Maybe everything about it is new, but are we talking about five tasks or fewer? I would still treat and track this as a project to make sure everything gets done and any problems get solved, but as with the previous item, if you think the chance of misunderstanding or questions is low with a written explanation, I would skip a kickoff meeting here too.

When is the right time to kick off a project?

So let’s assume your project has at least a little complexity. Your next decision is when to kick it off.

I would describe the ideal point to schedule a kickoff meeting as “after the project’s deliverables are defined,” but “before work begins.” I’m assuming this is one of your early projects and it’s going to have a fairly straightforward structure that looks something like the following, with planning happening first, followed by execution or “doing the work.” If that’s the case, here’s what the placement of your kickoff meeting should look like:

Sometimes the point “after the project’s deliverables are defined” but “before work begins” is clear, but sometimes there is sort of a fuzzy time window when deliverables are still being defined and work is also beginning. You have two options, depending on what is right for your project and context:

1. Work with your team and stakeholders to make the line in the sand clearer: “Let’s finish defining deliverables before anyone starts working on them. This will be the most efficient use of everyone’s time.”
2. Pick the best time you can within that fuzzy window, when the deliverables are defined as much as possible but the least possible work has happened.

The above structure, where most planning precedes most execution, is considered a waterfall-type structure. If you are running a more agile project, where you purposely have a process in place to meet with the team regularly and define deliverables as you go, then you don’t need your kickoff meeting to get into the weeds on deliverables. But you’ll still want a kickoff experience where the team and stakeholders discuss and become aligned on the project’s goals and intended benefits. You want everyone aligned on the final outcome, even if how exactly you’ll get there will be figured out later.

How to prepare for a kickoff

Often I will receive a new project request, or be notified that a new project is needed, in the form of an email. This email is a great start, but it typically doesn’t give me enough information to schedule a kickoff. Most of my work between a project request and a kickoff looks like analyzing the information I have, identifying what information I’m missing, and holding side meetings with key stakeholders or subject matter experts to fill in those gaps. For a big project, you may want a formal planning meeting or multiple planning meetings in advance of the kickoff. It’s okay to save a few questions to be answered at the kickoff meeting itself, especially when input from the broader team is welcome. But some aspects of the project are not open to team input, so those are better clarified in advance. Take the time to learn enough about the project that you can give the kickoff meeting a clear structure, and that it can serve its primary function: equipping the team with clarity about the project.

Who to invite

As details emerge in planning and you’re approaching the inflection point (in the graphic above) where a kickoff makes sense, your next decision is who to invite to the kickoff. You have two main types of people to consider:

Team members who will do the project work. All other things being equal, I would invite everyone you expect to do any work on the project. The only times I’d leave someone off and spare them the meeting are these:

1. If they have a small part in the project that you genuinely believe can be achieved to full quality without full context. For example, yesterday I left a colleague out of a kickoff for a workshop because all we needed from him was to build an online registration page, for which I could say, “We just need you to duplicate the registration page from such-and-such previous workshop, and swap in such-and-such new date and location information.”
2. If you’re faced with a tough decision between holding the kickoff at an ideal time and holding it at a time when everyone is available. Then you really just need to weigh the value of the relevant people’s presence against the value of the timing of the meeting. If you choose not to include someone, consider whether you could preserve some of the value by inviting a coworker they work with closely to come in their place.

Typically I wait to schedule a kickoff until everyone who will work on the project has been determined. You could hold the kickoff earlier and invite functional managers instead of team members, but I find much of the value of a kickoff is lost when I do this, as much of the communication becomes secondhand.

Stakeholders who influence the project. You don’t need to invite everyone who could influence your project, but I find most of the value of a kickoff is lost if the one person or the handful of people who hold the most influence over the project aren’t there. Whoever is responsible for day-to-day decisions on the project needs to be there. Your team members will be more responsive and understand the project more clearly if some of the information is shared by this person directly.

If your project has a sponsor—someone who green-lit the project and will be able to approve or reject the result at the end, even if they’re not involved day to day—you might want them there. It depends. Often these are the busiest people and getting them to attend a kickoff is difficult. If you don’t know your sponsors very well yet, I would at least extend an optional invitation so they know the kickoff is happening. Ultimately, whether their presence is necessary comes down to the relationship between the sponsors and the day-to-day decision makers. Can the day-to-day people be trusted to understand the sponsors’ requirements and when they’ll want questions or decisions elevated to them? If so, you can probably go without the sponsor. If you’re not confident in the way this communication will happen . . . invite the sponsor.

How to structure and facilitate a kickoff

This is not the only way you could approach the kickoff meeting itself, but if you’re new to leading kickoffs, this is an accessible place to start!

Write an agenda that summarizes the purpose of the meeting and breaks the conversation down into subtopics. This agenda doesn’t have to be long (in fact, if it’s long, it’s less useful because people won’t read it). You can describe the project and the purpose of the meeting in one to three sentences, and then list the topics the meeting will progress through in three to five bullet points. Put all of this in the digital meeting invitation—it will encourage people to accept the meeting because they can see how it’s relevant to them, and it will help them pre-think the project just a little, which will make the conversation more effective.

There are many ways you could break down the conversation into subtopics, but the important part is that you do break it down, tell everybody how you will break it down, and stick to it. Often I will break down the conversation by types of work or functional teams, but you could also break it down by project phases, key deliverables, or just about anything else. Just consider whether certain parts of the project will be clearer if discussed after certain other parts of the project, or if some decisions need to be made before or after others.

If possible, open the meeting yourself. My coworkers love when I speak first at a meeting and ‘frame up’ the direction of our conversation. I get the chance to set a positive, professional, and productive tone, and I use the time to briefly summarize the project, the purpose of the meeting, and the agenda. This is the other reason I write out these things in the digital meeting invite: it helps me refresh my memory quickly in the few minutes before the meeting so I can communicate them extemporaneously without much effort, or sometimes I just read the meeting invitation I wrote, and this still gets the job done.

Pass the ‘microphone’ to the key decision maker or day-to-day approver to add more detail. I usually do this immediately after I frame up the meeting because it continues getting everybody’s brains up to speed, and it lets the team hear what we are doing directly from the person who will provide initial approval on their work. It seems to create stronger and more direct accountability. (In some organizational structures, the day-to-day decision maker might also be you! In that case, just merge this step with the previous one.)

Manage the transitions to subsequent agenda items. After everyone knows where we’re going, I’ll introduce the next agenda item, potentially suggest who might speak first on that item, and then let the conversation proceed. I make sure the key aspects of that point are made, any relevant people get to ask their questions, and any necessary decisions related to that point are made. I let other people do a lot of the talking, but I’m always watching the clock and the agenda, and I jump in to steer things as needed.

More kickoff tips

What if people go off on tangents? Allow the relevant ones, but limit their length. As the person talks, keep asking yourself whether the tangent is adding value for the whole group, and whether it has the potential to prevent the group from having time to get to an item on the agenda that is more important. Be ready to suggest a separate meeting later if the topic is worth discussing further. Be ready to kindly redirect back to the agenda if the person just likes to hear themselves talk or has trouble being concise.

What notes do I take? I usually write down decisions and action items, as these are what I’ll need to do my job after the meeting is over. I’d avoid writing out full meeting minutes unless you’re expected to and you don’t have a good way to delegate this. People who write minutes don’t talk much in meetings, and you’ll provide more value as the project manager if you put your effort into directing a productive conversation.

What if I don’t get through the whole agenda? There’s no shame in letting everyone know you’ll schedule a second meeting time to finish. It happens to the best of us. Occasionally I will let the meeting run over if I can tell by body language (or at times, by directly asking) that nobody has somewhere else they need to be. But this isn’t my preferred option, as I feel it’s less respectful of people’s time.

But really, can’t I kick off a project with an email?

Maybe. It depends on the culture among your team members. Will they read the email? Will they ask questions if they have any? With a kickoff, you are trying to make sure everybody has and understands the same information about a project. If you think everyone will be engaged with your kickoff email, then great! It could be a good fit for your situation.

I find this isn’t common though. It is much easier for me to ensure people have absorbed all the project information and gotten their questions answered in a meeting. With the exception of the low-complexity situations I described near the beginning of this post, I get less questions to answer and problems to correct later when I use a meeting to kick off a project.

Now you’re ready.

While kickoff meetings are an art and take a few tries to develop the instincts to optimize them, considering all the items above should set you up for a good, effective first kickoff. Give it a try and enjoy how much easier your job becomes once the project work begins!