Successful Project Kick-Off Meeting
When I was working with my last client, I was challenged with a task to start working on a new innovative greenfield project. The main objective was to get people’s buy-in into the project and get full understanding why we are doing it. Let me describe steps we did.
It’s important to mention your planning meeting should have a moderator who steers the discussion and allows everyone to voice their opinion. It applies to any meeting in general.
First, you need to start with a clearly defined user problem. Without knowing what you are trying to solve, you cannot achieve any meaningful result. In our case, the clear problem description was provided by a product owner, who was present on all meanings to provide any clarification. Your product owner must be prepared to take decisions and provide clarifications on questions raised by engineers.
You should ask everyone, if there are any questions or clarifications needed, so it is clearly understood by all people involved.
We will use the following problem as an example for the following meeting parts:
Customers need to be able to add their e-mail to a subscription list. No authentication, nor authorization is needed.
2. High-Level Architecture
The second part is to draw high-level architecture as the first step towards solution. It should identify the main building blocks and allow discussion about them. I should emphasize, you as an architect / team lead / manager should not lay it down.
The architecture drawing should start with e.g. following:
The next step is to invite all team members to participate on identification of blocks. The moderator should steer the discussion towards a solution and get everyone back on the track if they diverge. They should also prevent one person speaking too much and other person not able to surface their opinion.
The outcome can look like this:
3. Break-Down to Tasks
Next action is to break down the problem into tasks. You should capture them in a reasonable granularity, so they are well scoped and understood by the team. They should not, however, supplement refinement sessions in order to make them sprint ready.
This part of the meeting aims to provide basic understanding of a way how to achieve the project. You will most likely discover that you need to do small architecture refinements based on task dependencies.
Here is an example for the e-mail subscription problem:
4. Optimize and Re-order
We all aim to deliverer as soon as possible, so it is good to understand dependencies in between tasks. You will always have some dependencies as you e.g. need to set up your project, or create an API you connect to.
In order to deliver as soon as possible you need to make your tasks executable in parallel depending on the size of your team. The result of this part should not be taken as given and it should change as you refine the tasks.
Let’s have a look on the example:
5. Assign Ownership for Refinement
This part is an important step to the project success. Clear ownership helps to speed-up refinement and allows your team to effectively communicate. All stakeholders simply know who is refining a particular task.
From this point onward you can just follow your sprint-ready process and start executing your project.
I presented an example how you can approach a team collaboration in a structured way. Based on my experience, you should really put emphasis on communication between team members. Everyone should be put on the same level and have the same understanding of the problem and high-level solution to it.