Understand both sides’ expectations before the kickoff

I’ve participated in meetings that were organized mostly by one side of the partnership. It was either the client who prepared the agenda and decided how much time to allocate to the kickoff, or the software house took full responsibility for the kickoff.

Personally, I'm not a fan of this approach.

It might seem that leaving the organization of the project kickoff in the hands of one party would lead to a more coherent plan, but that is not the priority here. The priority is to get people involved.

I’ve come to realize that the best kickoffs were the ones that were prepared in collaboration. During kickoffs in which both parties were engaged, we covered everything: who should participate in the meeting, why they should participate, what would be the best points to include in the agenda and how long the meeting should take. Even if one side gets a bit more active in this process than the other one - that’s fine. The most important thing is to ensure that both sides feel that their needs have been taken into consideration while organizing the kickoff.

Block off a sufficient time slot for the kickoff

Here is one of the most challenging things to do - decide how much time you actually need to run a valuable project kickoff.

Unfortunately, I do not believe there is a 'one size fits all' answer to that question. If you were about to start working with a major player such as Facebook and you had as many as 5 agile teams to introduce to the project, it would most likely take you much more time than if you had to introduce 1 team to a brand new, ‘greenfield’ startup.

In my experience, the best approach is to take your time and make your kickoff long enough to discuss everything. Rushing will do you no good. Remember, people are totally new to the project and the more they learn about the project in the early days, the less setbacks you will have in the future.

The kickoffs that I’ve participated in usually took from 1 to 5 working days. My observation is that kickoffs taking 2 days or less are usually too short. Your mileage may vary, but if you’re on the fence you should err on the side of caution and give yourself enough time for an effective kickoff. 

Involve as many people as possible

Do not get me wrong here; I know that there are people that won’t be very visible during the project and thus it might seem natural not to involve them in the kickoff. STX’s developers may not have a lot of contact with the client’s accounting department, for example.

But on the other hand, if they ever have anything to discuss, why not introduce them to each other during the kickoff stage? It won’t take too much time.

One easy approach to make that happen would be to start the kickoff with everyone’s introduction. It could be a short, 1-hour meeting in which each person would say 2-3 sentences about themselves. It will be much easier to get people to engage in positive communication when they first meet each other in person instead of only building relations via email.

Give people space to work together

You can schedule a thousand meetings in your kickoff agenda but there’s no meeting that will guarantee that the agile teams have actually understood what the project is about. That will only come to light once they start working on it.

In this initial phase of cooperation, it’s a good idea to organize a space for people to work together. This will help raise the quality of communication between the client and the software house, facilitating communication.

If you have developers on the client’s side, let them share the room with the software house’s devs for a few days. Same thing on the business side − you can organize story mapping sessions and do product backlog refinements together.

Check to make sure everyone shares a common understanding of the project. Treat it like an investment for the future. Working out any confusion at the very start pays off every single day for the rest of the project.

Remember the afterparty

Honestly, I’ve never seen a better way to establish a cooperative vibe between people than by having a pint together.

High quality work based on technical skills is crucial, but I believe that it’s only one part of the equation. Good relations between people are at least equally as important.

So make sure that once the business side of the kickoff project is squared away, you take the time to go out, have fun and unwind. It might seem frivolous, but it could be a great way to cement the relationship.

Evaluate your kickoff

As with any endeavor, the kickoff project should be followed by taking a moment to see what worked and what could be done better next time.

I have never participated in a project kickoff that would prepare the STX team to work 100% independently. Nor do I believe it is possible or the goal at this stage. 

Instead, here are a few signs that help me recognize if our project kickoff was efficient:

                     
• The client’s feedback is positive.
                     
• The agile team members are satisfied and full of energy to work.
                     
• The agile team is able to work with only limited guidance from the client, i.e. the team doesn’t get stuck - or at least not too often.
                     
• If the agile team has any issues, they know who they should contact on the client’s side about these issues.
                   

Actually, if you’re looking to make your next project kickoff a success, I’ve compiled a project kickoff checklist that you can use to ensure an effective process. You can get it here, along with a sample kickoff agenda:

Don’t hesitate to send this article to the participants of your next kickoff or anyone else who might find it useful. It always helps to be prepared.

Good luck with your project kickoff!