8 Items You Must Cover in a Website Kickoff Meeting
Baseball player Roger Maris once said, “You hit home runs not by chance but by preparation.” The same is true for marketing projects like website redesigns. A home run doesn’t happen by chance. It happens when everyone prepares. One way to do that is with kickoff meetings. Kickoff meetings are crucial. They clear up gray areas. They snuff out assumptions. They set the tone for everything.
Here are eight items to cover at your kickoff meetings. Get ready to load up the bases and hit a home run!
1. What both parties agreed to
Before the meeting, make sure everyone reads through the proposal and/or requirements documentation. Then review it together at the start of the kickoff meeting. Encourage people to speak up about anything they don’t understand, agree with, or think is realistic.
2. Project goals
Determine the goals and critical success factors for the project. Why are you doing it? What are the must-have results?
3. Protocols, processes, and documentation
Everyone works a little differently. For example, OSD has a file-naming and organization system for our electronic files, but it may differ from our client’s system. In this case, we need to figure out where to put the files, how to organize them, and how to name them in a way that works for everyone. It’s also crucial to talk about review processes. This crosses over into the next category …
4. Roles and expectations
Every team member needs to understand what their role is and what that means. Things go off track quickly if people don’t know their assigned role or if they go beyond their role. If you don’t understand your role, speak up at the kickoff meeting.
As a project manager, I use a responsibility matrix such as a “RACI” chart to outline roles and expectations. RACI stands for “Responsible, Accountable, Consulted, Informed.” I think RACIs are critical because they help define several key things:
- Which roles are needed for the project
- Who plays which role
- Specific tasks associated with the role
- Whether there are any gaps
This part often gets more complicated than it needs to be! It should be simple and clear. If it was in the accepted, signed-off proposal or requirements document, it is in scope. If it was not in there, it needs to go through a business process to determine what to do. So much confusion occurs when “wish list” items come up and people think that talking about it will make it happen!
For every item that is not in scope, you have three options and paths to take:
- It becomes part of the current project – do an addendum to the project proposal and get a signature
- It becomes part of a later phase – document all of the requirements discussed during the meeting, gather additional requirements if needed, and then create a separate proposal later
- You don’t need it at all – document who made the decision not to proceed and why that decision was made
This part often gets overlooked at the beginning of a project. Maybe it’s because everyone is energized and ready to get going. Maybe it’s because no one wants to be the “Debbie Downer” who brings up potential trouble spots. But what you don’t know can hurt you.
Potential risks might include:
- That people don’t understand roles or don’t follow roles
- Missed deadlines
- Anything you didn’t fully explore – for example, the ability to integrate one system with another
Once you have listed the risks, create risk mitigation plans. Be proactive and realistic. What will you do if those risks are encountered?
Again, this should be simple – if you included timelines in the original requirements or proposal. If you didn’t, create specific and realistic dates for key milestones. And make sure to build in time for your risk mitigation plans.
Ensure everyone is on the same page about costs, who is responsible for those costs, and how they will be paid.