Whisper & Company

How to Have an Awesome Project Kickoff Meeting

Emanuele Faja

If you’re about to start a Whisper project, then this article will give you a good indication of what to expect in your kickoff meeting. If you’re just reading, then we hope this article will give you some great ideas regarding your own kickoff meetings.

It’s often said that the start of a project sets the tone and pace for the remainder of the project. 

With digital, the main issue is managing risk. Something in the region of 68% of software projects fail to reach their intended outcomes. (link http://www.zdnet.com/article/study-68-percent-of-it-projects-fail/)

At Whisper & Company, nothing short of 100% success if acceptable. We ensure that every project is a success, no matter the challenges, and this requires great communication, and honest discussions around risk. 

Having a great kickoff meeting plays a crucial part in making sure that the project will be successful.

So today we want to explain to you what we feel a successful project kickoff meeting should look and feel like, and the approach we take to make sure that our projects have the best possible start. 

We’ve tried to keep it general, so much of the advice here can be used by companies and individuals who don’t work in digital design. We’ve included a “Digital Specific” section where we tackle what we do that is particular to our industry. 

As stated in the introduction, the kickoff meeting sets the tone  for the rest of the project. It may also be the first time you meet the project team from the other side, and as we all know:


You don't get a second chance to make a first impression.

~ Someone, somewhere, sometime. 


The goal of the kickoff meeting is threefold:

  1. To have the best possible start to the project
  2. To set clear guidelines, goals, plans, and responsibilities moving forwards
  3. To evaluate risk.

Kickoff meetings are not the start of the project.

There is one strange thing about kick-off meetings, and that is the fact that they are not really the true start to the project. Plenty of decisions regarding timelines, budget, approach, vendors, and methodology will have been made by stakeholders, who are not part of the project team, before the project starts. 

This is unavoidable, because normally a contract has to be signed before a project can start. 

The issue here is making sure that all team members are aware of the constraints and of the choices already made, and that they have to work with this is mind. 

So let’s move to the kickoff meeting itself.

The Project Team

Meet the team.

You first priority should be simply meeting all the team members and learn a little about them as people. The success of the project depends on the people involved, and it pays dividends to spend time bonding with the people you will work with in the near future.

You should be prepared for the fact that perhaps not all project team members will be present at the meeting.  Often project members have full-time jobs and this project has been thrown on top of their existing workload.


The project managers on both client and supplier side should ensure that a team list is compiled with names, contact details, roles, and responsibilities. 


It absolutely crucial that responsibilities are clear. There have been some interesting studies regarding joint vs individual responsibilities and the conclusion is always this:

Group responsibility means that there is no responsibility. People can hide within a group and under perform and nobody is aware. 

You should also create a private mental model of the team, and think about the strength and weaknesses of each individual member. 

Project Guidelines 


Communication is the foundation of good project management. 

Everyone should be invited to the project management system. And yes, you should definitely be using one of those! At Whisper & Company, we use Basecamp to help make sure our projects are a success. Basecamp makes communication really simple, and it’s a hundred times better than email.  We even pull some interesting statistics from our Basecamp. [link to stats]

You should also set standards in terms of what is acceptable wait for a reply. 


There should be an escalation plan on both sides if there are issues within the project team. Each project manager should be able to go to the stakeholder(s) if they cannot resolve issues within the team. 

There should be a clear standard for when this should happen, as it often means there is an important issue that needs to be addressed. 

Minutes Sign Off

Make sure that someone is given the responsibility to keep minutes of all project minutes, and that the project managers sign off on them after the meeting. This ensures that everything is recorded and can be referenced later if required. 

It should be stressed that only things recorder in the project meeting minutes or in the project management tool counts as official communication. Private emails, conversation, etc, are not official communications and cannot be referenced at a later date. 


The scope of what you are building and doing in the project is perhaps the most important thing to be clear on. After all, if you’re not sure what you’re building, there is a big chance that you won’t build it!

While the scope may already be clear, it is always a great idea to review it and make sure that there are no misconceptions. 


Having a brainstorming sessions regarding scope is a great idea to make sure nothing has been left out, and that perhaps somethings that are included are not a waste of time and don’t add value. The result should be a disorganised list of scope deliverables and a light discussion on each point. It’s a great idea to also list out what isn’t included, as this makes everything more explicit.

This is a great low-stress way to start collaborating. 

Detailed Clarification

Once the brainstorm is done, then you need to organise and sort the scope, and write enough about each part to have a clear idea of how each deliverable should be delivered, and what it means for it to be delivered. 

Again, this may already have been decided and be in the contract, but it’s a great idea to do it again. 

Perhaps this may something that you don’t do in the meeting, but is delegated to one or more team members to work on at another time.


Depending on the project, the project plan already have been created, and if this is the case, then it should be presented and discussed, and feedback and changes should be incorporated back into the plan. 

If the plan hasn’t already been created, then it’s worth discussing the high level issues during the kickoff meeting, and then delegating the project plan to a team member to present at the next meeting. 

What is the Project Goal

Asking, and answering, this question, is a great team exercise because it might lead to interesting conclusion. 

Any project should have a goal. Hopefully, everyone should have a clear idea of this before you start the project, but it’s never a bad thing to speak about what a successful project will look like, and what the key goal is. Creating a project mission statement is a great idea, as this is something that everyone can review during the project when unsure about certain decisions. 

You might discover how risk-averse the team is, how important it is to respect the budget, or if it’s the case of getting it done at any cost. 

Again, plenty of this work may already have been done before the kickoff meeting, if so, then it’s worth reviewing it and having everyone feedback on it.

Work Backwards

Once you have the goal, a great exercise is to work backwards from the goal all the way to the current project meeting. Amazon goes even as far as making teams write the press releases for products that haven’t even created yet! 

This is a fantastic way of doing things because it feels un-natural, and so makes you think about each and every step instead of making assumptions that may turn out to be costly later on. 

Create a timeline

Once you have done the working backwards exercise, you probably have a good idea reading the timeline. However, it’s worth breaking down each task and giving it a responsibility, and then asking the person responsible to estimate how much time they reasonably need. 

Good risk management is to add 20% to 30% on top of that estimate. If you can still complete the project within the time allotted, then you know that you will most probably be able to complete the project on time, even if you hit a few road bumps along the way. 


You should allow a certain amount of flexibility within the project plan, as unforeseen changes are often required mid-project. Everyone should be aware that this is the case, and they shouldn’t regard the project plan as a “carved-in-stone” document that must be strictly adhered to. Creating a project plan is not something that you do once and forget about. It’s best to think of the project plan as an organic document that changes over time to reflect new information. 

That said, any departures or changes from the project plan should be well documented, so the reasons can be fully understood by someone reviewing it later on. 

Digital Specific 

Content Strategy

Having a coherent content strategy is difficult, and having the content for a digital project ahead of time is almost always the best idea. 

Of course, sometimes this isn’t practical, especially in eCommerce projects where there are thousands of products and variations. 

However, a timeline still needs to be set to work on the content. 

Technology Decisions

If known, technology decisions should be laid out, with pros and cons for each decision, and a timeframe set for making those decisions.


If it’s a web project, we would specifically block out time to create a sitemap during the kickoff, as that’s a great way to think about scope, and also content. 

One thing that often project team members struggle with is the understanding that one page may be shown in multiple different ways to different types of users.


Infrastructure is something that needs to be planned out carefully, and the kickoff meeting is a good time to set a date for infrastructure decisions based on business requirements. At Whisper & Company we employ mathematical calculations that can determine approximate infrastructure requirements given the business requirements of number of users/orders/etc. 

Version Control

Version control is absolutely required for every project, no matter how big or small. If both sides of the project team will be handling the version control, the guidelines to be set in regards to the branching model employeed, and also a framework for who can push and pull changes.



An honest discussion around bugs/issues is always worth having right from the start. All project team members are humans, and so it is inevitable that mistakes will, at some point, be made. The discussion needs to be centered around how bugs are discussed and handled.

Set the next steps. 

It's important to set a series of next steps during the kickoff meeting, including the time/date for the next meeting. Everyone should leave the meeting with a clear vision of what will happen next, and anything that is required from them to move the project forward.