If you’re about to start a Mäd project, then this article will give you a good indication of what to expect in your kickoff meeting.
If you’re just reading, then 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.
At Mäd, nothing short of 100% success is acceptable. We ensure that every project is a success, no matter the challenges we face. 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.
This article describes what a successful project kickoff meeting should look and feel like. We explain our 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:
- Having the best possible start to the project;
- Setting clear guidelines, goals, plans, and responsibilities moving forwards;
- Evaluating 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 as normally, a contract has to be signed before a project can start.
The issue here is to make sure all team members are aware of the constraints and of the choices already made. They have to work with this is mind.
So let’s kickoff.
The Project Team
Meet the team.
Your 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 underperform and nobody is aware.
You should also create a private mental model of the team, as well as considering the strength and weaknesses of each individual member.
Communication is the foundation of sound project management.
Everyone should be invited to the project management system. And yes, you should definitely be using one of those! At Mäd, we use Asana to help make sure our projects are a success. Asana makes communication really simple, and it’s a hundred times better than email.
You should also set standards in terms of what is an 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.
Signing Off Minutes
Having a team member keeps the minutes of all project minutes, and having project managers to sign off after the meeting ensures that everything is recorded and can be referenced later if required.
It should be stressed that only things recorded 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 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 session regarding scope is a good way to make sure nothing has been left out. Some things that are included may turn out to be a waste of time and don’t add value. The result should be a disorganized 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.
Once the brainstorm is done, then you need to organize 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 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 be something that you don’t do during the meeting, but to be delegated to one or more team members to work on at a later date.
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 as it may lead to interesting conclusions.
Any project should have a goal. Hopefully, everyone should have a clear understanding of the goal prior to starting the project. However, it is 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 an excellent idea. Thus, everyone can review the initial objective during the project when question marks arise on certain decisions.
You may 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 worthwhile reviewing and having everyone’s feedback.
Once you finalized 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 press releases for products that they haven’t even created yet!
This is a fantastic way of doing things because it feels un-natural, and so makes you reflect on each and every step instead of making assumptions that may turn out to be costly later on.
Create a timeline
Once you’ve done working backward, you probably have a good idea reading the timeline. However, it’s worth breaking down each task and giving it a responsibility. Afterwards, you should ask 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, regardless of upcoming hurdles.
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.
Having mentioned that, 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.
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.
If known, technology decisions should be laid out, with pros and cons for each decision. A timeframe should be 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 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 Mäd we employ mathematical calculations that can determine approximate infrastructure requirements given the business requirements of the number of users/orders/etc.
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 employed. It is useful to set the guidelines of who can push and pull changes.
An honest discussion around bugs and issues is always worth having right from the start. All project team members are humans, thus it is inevitable that mistakes will be made at some point. The discussion needs to be centred 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 and date for the next meeting. Everyone should leave the meeting with a clear vision of what will happen next. Anything that is required from them to move the project forward.
Best of luck to your next project kickoff meeting.