You are an IT project manager in a reputable company and in your role you are responsible for the successful delivery of various IT solutions to clients. You have just been assigned a new project with a signed statement of work (SOW). Also, you have been assigned a team of developers, a solution architect, tech lead, and a UI/UX designer. An initial introduction has been made between you and the client sponsor and the ball is now in your court to convince your client that your team is the best team for the job and kick the project to a great start.
A Client Project kickoff meeting for me is one of the most important aspects of project initiation. I always strive to gain the trust of the client early on in the project which is why I ensure my team and I are well prepared for the meeting. When a project kickoff is done correctly, good relationships are established between the client and my team, and trust is built for a smooth and successful project delivery.
Project kickoff with a client is where the project team gets introduced to the client; project scope is confirmed and expectations are set for the entire project duration.
It is very important to set the right expectations and getting everyone’s buy-in at the start of a project. Key project stakeholders do not want to be blindsided and want every aspect of the project laid on the table at least at a high level in a format they can understand.
Most times the client kickoff meeting is where the delivery team (my team) meets the client for the first time after finalizing the contract or the statement of work so my team needs to make a good impression.
How I prepare for a Client kick-off meeting.
- Review the Statement of Work (SOW): I thoroughly review the statement of work to understand what has been sold to the client and to have an idea of what the client is expecting from the engagement. I will identify any unclear areas and note them down to be review with the client on the day of the kickoff. I also note down details of what is in-scope and what is out-of-scope and any other items that could potentially be a cause for dissent. You want to have this documented and with possible alternatives already thought though to help me lead a robust and productive discussion.
- Review the SOW with my technical delivery team: I need to get some insights on the project deliverables through the eyes of the people doing the work which is the technical team. So next, I schedule an internal project kickoff with the internal team to review my findings from the SOW to get their input. Because they are the ones doing the actual work, they are in a better position to assess and identify areas that are cause for concern. For example, I was once assigned to a project where we were contracted per the SOW to only build a proof of concept but my initial interactions with the client implied that they were expecting a full deployment. I knew this was a red flag but I needed to hear from my team how much of a red flag it was in terms of additional time and cost. In cases like the one I just mentioned, I needed to get the facts and numbers from my tech team so that I am better equipped to lead a productive discussion with the client and set the right expectation. I also want to use the internal review with my team before the kickoff to bring the team up to speed on the client’s history and their priorities. Where I don’t have as many details, I invite the sellers and the internal client representations to brief the team about the client’s goals and how best to relate with the client. Nothing makes the client happier than to see a well prepared, knowledgeable, and informed team ready to take on their project.
- Prepare a high-level Schedule: Based on my understanding of the SOW and the outcome of review the tasks with my project team, I come up with a high-level schedule. The high-level schedule will give key stakeholders an idea of what to expect schedule-wise throughout the project duration.
- Prepare a kick-off deck and review it with your team. I review the final kick-off deck with the team, get their input, and make some final adjustments. For IT projects, it helps to have a demo or sneak peek of the client is to expect from the technology being implemented. Sometimes the client already has an idea during the sales cycle. If you have a demo to share, you want to include some details in the deck and ensure that it runs smoothly.
- Schedule the kick-off meeting and send out invites to key stakeholders: I reach out to the contact on the client-side to get a list of key persons (email and role) from his side whom he wants to attend the project kickoff. Send an invite out to both your team and client team with a description of the goal of the project kick-off and an agenda.
- Before the kick-off, I usually just send the deck to my counterpart on the client-side to get some feedback and suggestions for additional agenda items (if any). I also want to remind them to be prepared to speak clearly to their goals and objectives for the project.
During the kick-off meeting
- Team introduction: This is an opportunity for your team to showcase their wealth of experience. For each member of both teams, it should start with their name; role; experience with similar projects: and responsibilities on this project. Each person should be allowed to introduce themselves.
- Project Goals and Objectives: Here I allow the project owner to describe their project goals – what they want to achieve from the project. It is an opportunity for both teams to understand the project background, organization vision, and reason for project initiation and what success would look like for the business. This is the WHY for the project. The delivery team can ask any questions that come to mind that could better explain the directions and priorities of the project. During this item on the agenda, I make it a point to listen very carefully and jot down clearly what the client wants for the engagement. I want to be able to come back to it throughout the project and measure project progress against the client’s needs. I also listen to implicit and explicit statements from the client.
- Project description: Here the IT project manager discusses the solution to be implemented. From my experience, the solution is usually clearly stated in the SOW. As the PM, I want to clearly state what is in scope and what is out of scope for the project. This item of the agenda is very paramount to getting everyone in alignment with what is to come in the final deliverable. The client can use this opportunity to ask clarifying questions to eliminate any surprises midway into the project. I also make sure to document any deviations to the SOW both teams agree on and share as an addendum to the original SOW.
- Establish Success criteria– The goal here is to ensure that all parties are aligned with their expectations for the project. It is a chance for both teams to ask as many questions as possible to understand the project scope and agree on what success should look like for the project.
- Any Issues, Risks, Dependencies: If there are any risks, issues, or dependencies the client or the delivery team wants to discuss, then it can be done at this point. Sometimes I prefer to have such discussions in the status meetings just to stick to the positive flow for the project kick-off meeting.
- High-level schedule and task (When & How & Who): As the Project Manager, I will share a high-level schedule consisting of high-level tasks; who will be responsible for what and when on the project timeline.
- Communication Plan- This explains the communication pattern for the entire project. You want your client team to know when and what to expect as far as communication goes. I try to take the first stab at this based on what I think would work on a project the size and complexity. Then during the meeting, I get agreement or adjustments to the communication plan from the client team.. Once again, I re-establish roles, client sponsor, counterpart PM, the counterpart for the tech team. An example of a communication plan will include meeting types, agenda, frequency, and required attendees; reports, frequency of delivery and recipients of the reports, and so on. (watch out for my blog on creating a communication plan)
- Project Prerequisites: Here, I usually go over the of everything both teams need to put in place before we can reengage and start the project. I usually come up with this list based on my experience from past similar engagements and confirm them with the technical team since they are doing the work.
- Next Steps: I establish clear and immediate next steps which can look like for some projects.- Grant access to project delivery team to client environment; for AI projects- data gathering by the client for ground truth development; Identify key subject matter experts (SMEs) from the client-side to work with the project delivery team, and so on.
- Q & A: Open the floor for questions and answers.
At the end of the meeting, I give a quick summary of the discussed items; review action items; owners; and due dates. I let both teams know that I will be sending out a note with action items from the meeting along with the deck.
Finally, end on a fun note: I try as much as possible to present my team as a fun group by throwing little fun statements here and there. If joking around is not your thing (it wasn’t my thing for the longest time), it will suffice to simply expressing how excited you are with starting the project and how much you you are looking forward to a fun and successful engagement.
After the kick-off meeting
Send an email to all invitees with following content.
- Thank everyone for their participation during the meeting
- Attach the deck used during the meeting.
- Include discussion, action items, owners, and due dates. It is important to have an owner printed for each action item to avoid confusion.