Starting a project is hard. Even after all these years I still get some anxiety whenever I begin a new project. What’s the scope? Is everyone on the same page? Will there be enough funding to get everything done? What if nobody likes me?
But whenever I’m feeling overwhelmed or apprehensive about how I’m going to go about it, I begin visualizing how I want the project kickoff to go. And then the project management creative juices start flowing. To help you overcome the first days of your project jitters, here’s an overview of how I structure my kickoff presentations:
The opening of a kickoff sets the stage for the entire presentation. Most professional speakers will tell you to “know your audience”, but how the hell are you supposed to know your audience when you’ve been there 8 minutes and are being asked to get things moving? So. My advice is to try out a few different openers and then stick with one that suits your personality more than it suits the environment or your client. After all, they’re going to have to work with you for the foreseeable future and will need to get accustomed to your leadership style, so you may as well rip off the bandaid.
Team rules/general housekeeping
This part is important and often missed. Before you get into scope/schedule/budget talk, you need to establish some project ground rules. It also helps expedite the forming/storming/norming/performing process. (If this is the first time you’ve heard of this process, feel free to look it up here) Here’s a few I like to use:
- Scope change= Ok, Scope creep= Not ok. All scope changes go through the PM for review/evaluation before getting worked on. (I like starting with this one because it seems like the term “scope creep” gets thrown around way too much these days. Your team needs to know that an approved scope change is not the same as scope creep, and changes are ok as long as it goes through the proper approval method.)
- Plan the work, work the plan. All team members are required to build the project plan, with the understanding that once it’s been developed, everyone agrees it’s achievable. (There’s nothing worse than a PM banging away at MS Project for a week and then ‘presenting’ the plan to the team. And not the best way to get the team on side with the scope and schedule.)
- Team conflict. (This is where I turn to the team and say, “It’s inevitable that at some point on this project, conflict will occur. How should we try to handle it before it happens?” This calls it out point blank, and gets the team talking about how they work best in stressful situations. Best part is, the entire team is in the room to hear everyone’s feedback/comments so it gives everyone a good starting point on how to work with one another.)
- Show up. This means show up to meetings, show up to work, show up for your team mates. And if you can’t show up, let me know, so it doesn’t give everyone the impression that you’re not pulling your weight. (No additional explanation required here.)
See how those can help you set the tone even before you start going through the boring scope/schedule/budget slides?
Be brief, bright and to the point in this section. It’s important, and intended to bring up any glaring issues that you have missed in the planning process, but also the rudimentary stuff that makes people’s eyes glaze over.
Close with action items
The last slide should contain some “next steps” or “action items” with names assigned and deadlines. This lights the fire under people’s arses and gets the project going. A couple I always have in my kickoff are:
- Updates to plan (Kindra- tomorrow)
- Approval of plan (Sponsors- day after tomorrow)
- Set up weekly project team meetings (Kindra- after this meeting)
- Set up monthly project steering committee meetings (Kindra- also after this meeting)
- Requirements gathering/design (Whoever- once plan is approved)
Finish with something unexpected
This can be a quote, a Dilbert cartoon, or whatever. Again, go with something that suits you and your leadership style. I like to include this picture so people laugh but also understand that #projectfail is real and happens easier and more often than people think:
Was this article helpful? What kickoff tips/tools of the trade do you have? Share your thoughts in the comments below!