Internal Kickoff Meeting


As project managers, we can’t stand faffing around and talking about work, when time is being wasted and work just needs to be done. We love getting things started and seeing stuff happen.

But in the case of a project kickoff meeting with a client, it’s critical not rush into it before first prepping properly with an internal project kickoff meeting to come up with a solid plan as to what exactly you’re going to do!

The internal project kickoff isn’t just a precursor to the client kickoff meeting, it sets the tone, style and vision for the entire project.

They’re a chance for you as the project manager to properly educate the team and develop cohesion before finding yourselves floundering in front of a client. The internal project kickoff meetings need to get you (and the team) to a place where everyone can confidently say, ‘We’ve got this!’


Going into a kickoff meeting with an informed team and a proper plan helps you get the most out of your discussion with the client and the stakeholders. It’s important for the team to know as much as possible about the client and project before they start asking stupid questions in front of the client! It’s also important for the team to work together to come up with a solid plan that’s going to instill confidence in the client, and to collectively make any important project decisions ahead of time, so that valuable hours, money, and face-to-face client time aren’t wasted with internal debates with the client watching (and becoming increasingly concerned that the agency team doesn’t really know what they’re doing).

Plan your internal project kickoff meeting properly

So assuming that you’ve planned ahead and spent some time preparing for the internal kickoff meeting, here’s a sample internal project kickoff meeting agenda. In going through the agenda you’ll see that you’ll need to do some preparation in advance of the meeting. Get cracking!

Every project is unique, but there’s value in ensuring that we cover off some of these basics to get our team on the same page:

  • Introductions – meet your new best buds (15 mins)
  • Client – what’s the background? (5 mins)
  • Project – why are we doing this? (5 mins)
  • Scope – what are we doing? (20 mins)
  • Approach – how are we going to make this happen? (20 mins)
  • Roles – who is doing what? (5 mins)
  • Teamwork – how are we going to work together? (5 mins)
  • Kickoff – what’s the agenda for the client kickoff? (5 mins)
  • Q&A – what haven’t we told you? (5 mins)

Client: what’s the background?

Start by scene setting to help everyone understand the sandbox you’re playing in. Sharing is caring, so don’t hoard any logins or documentation to yourself. Share everything you know with the team so they can get up to speed themselves and empower and equip your team with all the relevant information they need to digest. To keep the meeting on track, it’s probably worth delaying any Q&A until the end, otherwise, this section of the meeting can end up taking a disproportionately long length of time.

Share how you got to work on the project – was it a direct award from an existing client, is it a brand new client, or is it a friend of the CEO’s? Explain what you’ve done in the past with the client – or with different clients but similar projects and help the team understand who you’re working with.

We all know clients come in all kinds of flavours. But often, to our teams, they’re simply the people who always make bad decisions. Try to position the clients in a positive light. And to prevent any serious cases of foot-in-mouth, explain client distinctives to your team. Let them know who they are (internal/external), what we know about them, other projects they’ve worked on, and how the client likes to work.

Project: why are we doing this?

To further help put the project into perspective you need to help your teams understand why they’re doing the project in the first place. This means from a client perspective sharing the business drivers for initiating the project, and ensuring there’s clarity as to what success – or failure looks like.

And from a customer experience perspective, initiate the discussion with the team around how this project makes customers or citizen’s lives better and meets their needs. From the outset, maximizing the positive customer experience should be at the heart of why you’re engaged with the project. It’s the start of casting a vision for why the team should care about the project and helping everyone understands that what they’re doing is contributing to something that’s worthwhile.

Finally, from an agency perspective you need to be clear about what success means beyond simply delivering on time, on budget and to the agreed scope. How are you as an agency going to grow as a result of doing this project – will you doing develop a new capability or competency with a new technology?

Scope – what are we doing?

When the background is set, it’s time to get into the scope details with the team. Normally that means reviewing the timeline, estimate and SoW (statement of work) so that everyone understands the flow of the project, the activities and the outputs or deliverables. Without boring everyone to death, help everyone understand the quirks of the project, so the whole team is aware of the constraints from day one.

This is a great time to start the RAID (Risks, Assumptions, Issues and Dependencies) log. There’s nothing quite like a SoW review to get people talking about what’s going to go wrong. The sooner you know, the better. If anyone’s tried this before and failed, why was it? And how can you mitigate against it? Knowing the insider track and your team’s unique understanding of similar projects will help develop a culture of openness and ensure surprises are kept to a minimum.

Approach – how are we going to make this happen?

Reviewing the SoW and the proposed activities and outputs creates a great opportunity to discuss anything the team might want to change to the project process or new approaches they might want to try. Remember that new isn’t always better, and tried and tested often works just fine. So cast a vision clearly and don’t end up on a wild goose chase to the bleeding edge of technical or process idiocy.

Assuming the SoW has already been approved, remember that if you’re changing the approach you need to ensure you’re still able to meet the client’s (and agency) project goals and ensure that you’re still delivering what you promised in terms of outputs. This isn’t just an opportunity to make life easier for yourselves. Nonetheless, cultivate ownership of the project within the team. In order for the project to be a success, the team needs to feel like it’s their project. By leaving time and space for your team to suggest ideas, challenge your plan, and come up with a better way of working you’ll end up with a much more robust approach and a much more engaged team.

Roles – who is doing what?

When the team have had a chance to understand the project and begin to understand the context of how they might fit within it, it’s worth clarifying the team’s roles and responsibilities. It can be helpful if you’re able to map their roles back to the SoW and clarify the deliverables associated with each area, why they exist and what needs to happen to make them a reality.

It can be helpful to develop a matrix against the SoW to define a RACI (Responsible, Accountable, Consulted, Informed) for the deliverables and the team. The RACI will help mitigate against any uncertainty of responsibility and invariably helps clarify your teams comfort levels with delivery.

Teamwork – how are we going to work together?

When bringing together a team that have never worked together before there’s going to be a range of understanding on how the team should work together, how collaboration should be managed, how communication should flow, when the team should meet, the tools that should be used, and which systems you’ll use to share deliverables or outline details of specific tasks or tickets. As PM’s our role is to make it simple, to put everyone at ease and get people excited about working together on the project.

Often there’s no right or wrong to these approaches, but to get buy-in from your team it can be helpful to give them as much autonomy as possible. You want them to feel like they’re masters of the project. Define your expectations and let the team agree together amongst themselves exactly how they will deliver on it. By clarifying the teamwork and agreeing the nuts and bolts part of how it’ll all get done we’re helping managing our team’s expectations on what’s acceptable and what’s not.

Kickoff – what’s the agenda for the client kickoff?

As a project manager, you should already have a plan in place for the client kickoff meeting – the purpose of reviewing it with your team is to get their buy in and provide a sense of context and urgency for the next steps.

If at all possible, beyond the usual discussion items that are on the kickoff agenda, discuss with your team if there are any useful exercises that can be run during the client kickoff meeting to gain some early insights or kick-start the project.

By agreeing an agenda for the meeting with your team, it can help crystalize their focus and provide a helpful context for any pre-work that is required. Planning the meeting is also a great way to review actions and decisions that were made earlier in the meeting in terms of project scope, approach, roles and teamwork as you plan how to share them with the client.

Beyond just agreeing an agenda, think about scheduling another planning meeting to rehearse what you’re going to say, who will say it, what slides you’ll show and rehearse any activities. You’d be surprised at how quickly you’re able to refine the agenda and meeting content when you rehearse it properly. This extra step will help your team feel more comfortable, will allow you to communicate clearly what you expect of them in front of the client, and empower them to deliver.