How to Have Successful Project Kickoffs (And Why They Matter)
Kickoffs Are Key
Sometimes the success of a project is determined before it even starts. Understanding the context about the environment and circumstances in which the project was approved is key to making sure you can deliver value to your clients. Projects can come in many different sizes. In this article I’m assuming a large size project that has stakeholders and project team members. (We can discuss smaller and/or internal kickoffs another time.)
It’s often the case at agencies that clients have a lot of up front calls and discussions with someone on the business development team. I’ve worked with BD teams that have thoughtful and informative handoffs, and I’ve also worked at agencies where the only information I have is in an email about a new project kickoff that has already been scheduled. Either way, it’s important for digital project managers (DPMs) to understand the deeper reasons behind why a project is happening and what success really looks like.
Project kickoffs are often rushed or treated as a formality, but they can be incredibly valuable. Keep in mind this may be one of the only times you have all of the stakeholders and the whole project team in the same meeting. It’s also an opportunity to set the tone for the project and establish expectations for how team members should communicate. I’m not here to discuss abstract concepts, let’s dig into the essential aspects of a project kickoff.
Before the meeting even starts, make it clear that you need all stakeholders, decision makers, and team members to attend. You may get some push back, like emails telling you the C-suite stakeholders can’t attend due to busy schedules. Insist. Communicate that it’s crucial to have everyone with a vested interest in the project in the kickoff meeting. Don’t feel uncomfortable saying that, because it’s true. If someone is going to have feedback during the life of the project they should be there at the start.
Make All Project Roles Clear
Once you manage to get everyone in a meeting: Say hello. Ask people how they are doing. Be a human and try to make a connection with the other humans there. (If you’re thinking it’s crazy for me to include this advice I could absolutely introduce you to a number of project managers who stay quiet until the presentation starts.) Once you’ve been friendly: start the meeting with introductions. I know it can be tedious (especially if there are dozens of people in the meeting) but you have to start somewhere, and this is the best place to do it. I’ve learned to ask people to state their name, title, and role in the project. That last bit is key. The CMO may have the most important title in the room but asking them to state their role in the project may reveal that they really only want to see the end result and won’t have time to participate in the project details.
Why Is This Project Happening?
Next you’ll want to make sure everyone in the room is on the same page regarding the project background and the business case for the project. You may be tempted to jump right into scope review because these meetings can be long and tough but, trust me, you don’t want to skip this. Summarize the business circumstances that led to this engagement and why it is important. State what you know and make sure to observe others in the meeting so that you can discuss things as a group if you can tell everyone is not aligned. This goes for all stages of kickoff actually.
Project backgrounds can be complicated and you may need to use your soft skills to make sure you’re aligned without touching on issues that may make some people uncomfortable. One of the biggest projects of my career came to be because the CEO of a company decided that the two major divisions of said company needed to operate as one. They had two massive global websites and we needed to merge them together. The stakeholders from the larger division were on board, but the stakeholders from the smaller division (including one person who’d been at the company for decades) were furious. In order to discuss the project background I had to really lean into the business circumstances that led to the project being approved. I talked about brand recognition, the ease of users being able to navigate from one division to the other, and shared company history and leadership. The CEO was able to chime in with more context and this conversation went a long way into level setting that this project was supported by company leadership no matter how either of the divisions felt.
Success Metrics and Stinky Fish
This conversation about why the project is happening will usually have a natural transition into what success looks like. For some clients, success may not just be a shiny new design, but also a reduction in customers calling them directly for help. A thoughtfully structured IA and user flow could help users find what they need without calling a help line. Other clients may need a new site by a certain date in order to present it at an annual stakeholder meeting, and no matter how good the new site is, missing the unveiling at that meeting could lead to lost jobs. Another my tell you that an important part of their business isn’t well represented on the site and that needs to be fixed. Once you know why the project is happening, you should be able to infer some success metrics but do not make assumptions. I have gone around the table before and asked every stake holder to say out loud what success looks like to them. Make sure you get a few solid goals that have been explicitly stated and repeat them back for clarity if you need to.
Mmm stinky fish!
If you spot any competing goals or red flags, now is the time to bring them up in what I like to call the stinky fish portion of the meeting. I usually find a funny picture of fish in a market and put it on a slide with no words. When I get to it I let everyone know that it’s time to voice our fears and worries. One stinky fish can ruin a whole shipment of seafood, just as these worries can erode a project, so we’re going to get them all out NOW. If you have any hesitation about this portion I’m here to tell you that people love it. Your clients have stories, they’ve been burned by projects or agencies in the past, and they want to tell you all about it. Also, this is going to be your first trust building moment as the PM for this project. People will raise past traumas, internal concerns. and sometimes they even reveal things like “your agency was not the one I would have chosen and I don’t think you’ll do as good of a job as the other agency would have done”. This seriously happened to me in a kickoff meeting. I took a breath and asked for more specific concerns related to how the other agency pitched the project vs our approach and we talked about it in a matter of fact way.
Sussing Out REAL Decision Makers
The next part of the meeting gives space for the simplest question with the hardest answer: Who is responsible for final approvals? I don’t care how many RACI charts you’ve made. The org chart you researched on LinkedIn won’t help you here either. Approval authority is often fuzzy and riddled with political landmines. Maybe the client says “No problem. John is the final approver.” I promise you, it’s not that simple. Dig in. Ask questions. What has to happen before John gets the deliverable? Who sends it to John? What other hurdles will you have to jump before John is able to review your team’s work? You’re the one who is going to have to navigate a project plan with all of these feedback loops so don’t let it get pushed aside. Say the quiet parts out loud. One tactic I like is to say “I’d like to just state the approval process out loud so that I can make sure I’m understanding each part of it.” Go on to relay the details, starting after you have internal approval (you can discuss internal reviews in your internal kickoff). Maybe Diane needs to review and give you feedback before any deliverables get presented to John. That’s fine, but it needs to be accounted for in the timeline.
The person with final approval may or may not be the person with real decision making power. The importance of this aspect grows in direct relation to the size of the project and the company you’re doing it for. Will Diane be able to make decisions when stakeholder feedback contains contradictions? Ask directly. It’s not the most comfortable conversation but I promise you it can get much worse if you don’t get this out in the open now, in a room where everyone involved in the project can weigh in. At best, your clients realize that they need to be more involved than they originally thought and make an effort to do so. At worst, this is something you can come back to when you can’t make sense of the feedback for your work.
Tools and Agreed Upon Process
You’re doing amazing sweetie. This kickoff is going great! The next part of the agenda will be a breeze: talk about the communication tools you’ll use. If you will assimilate into the tools your client uses: make sure they know who to add to the tools and state your assumptions about how that will work. If you’ll be setting up the tools: be specific about what they are for and how they should be used. For example, you may create and Slack channel shared with the client. Make a note that Slack is a great place for quick questions and alignment, but that deliverables will be a SharePoint link they get in email. Or they will exist in a specific Drive folder. However you’re going to do it, say it explicitly and make sure you get buy in. I’m not sure you’ve ever tried this, but did you know you can tell clients how you want them to give you feedback? I know, it’s insane. Tell them that changes don’t start until all feedback is collected and if there are questions the team will need answers before they can work on revisions. Ask them to make comments on your Google doc, or write you an email with changes, or send you telegrams. It doesn’t matter how you ask for feedback, as long as it works well for your team and doesn’t necessitate a lot of back and forth. Nothing will throw a wrench in your project plan faster than clarifying questions that take days to get answered.
Scope and Timeline Review
Speaking of project plans, now you finally get to talk about scope and timelines. This is a time for high level broad strokes. For example: creative is included and there will be 2 rounds of revisions for the overall site design. You can just say that. Even if it is in your project plan, this isn’t the time to note the exact delivery dates and approval deadlines. More importantly, make sure you mention what is NOT in scope. Maybe you have a client who may want to sell products on the site one day, but for right now they are just getting their name out there. This is another example of saying the quiet part out loud. Make sure to say, in this meeting where all of the stakeholders can hear you, “eCommerce is not included in this scope, but we can revisit that as another phase after launch”. This feels like a good time to mention that there’s a difference between telling clients that something is out of scope for this project, and nervously telling them “no we won’t be doing that”. If the ask is within your team’s skillset, you probably can do it, but it needs to be paid for. Saying that something can be added to a list for Phase 2 is one of the best ways to stay on track. Really actually make a list for Phase 2 and add to it for the duration of a project. This is a great resource for BD to pick up and get a subsequent contract with the client.
Make sure you have a visual example of a timeline for this project. It doesn’t have to have every approval and hand off in it, but it should show phases of work at a high level. As you talk through it, it may be helpful to mention to your clients how involved they will need to be during each phase. They may need to have weekly meetings with your strategy team at the start of a project, but only monthly checkins once the project is in development.
What Should Everyone Be Doing
Deep breath, you’re almost through a wonderfully successful kickoff meeting. Take a moment to ask your clients if there is anything else you and your team should know. Now all that’s left to do is to remind everyone of immediate next steps. Here are a few examples: To the client project manager: please remember to add me to Jira and let’s plan a working session to schedule approval meetings as soon as possible. To the CEO: I’ll send you an email reminder but please remember to find 3 inspiration websites and get them to me this week so that I can get them to the design team. To some stakeholders you may not see until the first big presentation of the project: Thanks for your time today. We’ll see each other again when my team presents the strategy document in 7 weeks. Thank everyone for their time and reiterate that you and your team are looking forward to a successful project.
When the meeting is done be sure to gather up any decisions made in one document/email and share them with your own team and the main POCs on the project. If you’re giving homework make sure you follow up with an email (or whatever communication method you agreed upon) to the responsible party with the ask so that they don’t forget.
A Few Final Thoughts
If you have a lot to present, make sure to ask a team member to take notes on your behalf so that you don’t get distracted. Recording the meeting and getting AI notes is always a good move as well.
First impressions really count. It’s a cliché saying for a reason. Setting up a successful kickoff meeting is the first way you can begin to build trust with your client and give them confidence that their project is in the right hands.
By following the direction in this article you’re already on your way to creating a foundation for project success. Good luck out there!
Recap of important kickoff meeting aspects:
Ensure attendance
Introductions
Project background
Success & stinky fish
Roles, responsibilities, and approvals
How we will work together
Scope and timeline review
Next steps
