The way you kick-off a project can make it or break it. Yet often, we dive straight into delivering against the project plan and things go awry that could have been prevented by an effective project kick-off.
Here are a few things you can do to kick-off your project in a more successful way than just saying 'Go'.
I mean everyone – the client, the third party agencies, the core team. Anyone that will be working on the project at some point, not just the people that have the first set of tasks in the project plan.
This is beneficial because it means everyone can meet each other and get to know who they are working with. It wouldn't be unusual for you to never see these people again (as email & phone communications often take over) so putting a face, as well as some personality, to the email address is important. For junior members of staff this also has the benefit of making the client more approachable.
Having a bonding experience at the very beginning creates a sense of 'one team' – and people communicate and deliver better for people they have personal understanding of.
Think you can't do it because not everyone will be free at the same time or you can't fit everyone into a room? It doesn't have to be long, and it doesn't have to be in person – video conferencing or Skype is a good enough alternative.
I always ask “what could go wrong” what are the risks – for all parties, agencies, internal teams, client, stakeholders. Then think over possible solutions as a group.
Having a single vision for why this project is happening so that the whole project team understands it will allow better decision making throughout the project, particularly for decisions that have to be made on the fly.
This is ideally done by the client (straight from the horses mouth so to speak) and whoever has had the conversations with the client to shape the project. These are the people who can best explain what problem the project is trying to solve, and why. After all, you're not really building a website just because someone wants a website, it's because you want more people to find your products, for example.
Job titles may not describe what someone is actually doing on the project, and job titles often mean different things in different industries or organisations. When you go around the table doing introductions, make sure each person describes their role on this project, not just their job title.
This also helps people know how they fit in to the team, and everyone knows where to go with problems or questions.
Similar to the lack of consistency in job title terminology, names of deliverables can also mean different things to different people.
Not all tasks need to be explored, but ensure that everyone understands what outputs they're getting from which teams. Simply saying, the design team will deliver the designs can leave ambiguity – are they delivering them as Photoshop files, for every page or just key pages, with interactions annotated or not...
Key events should be discussed and scheduled at this point as well (key delivery dates and meetings for example).
It can be hard at times if you don't know what you're delivering – for instance, if you need to do user research to know what strategy or design work needs to be prioritised. But at this point you can make assumptions even if you don't have complete clarity, and ensure the teams know who they will be delivering to, even if they don't quite know what yet.
Try and keep it as simple as possible to make sure it's relevant and understandable for everyone in the room.
In as much detail as possible the plan should cover how and when things happen, but resemble more of an approach than a detailed project plan. When you're looking at the plan, encourage group discussion, your plan at this stage shouldn't be concrete so update the document during the kick-off to flex to new information.
I always ask "what could go wrong" what are the risks – for all parties, agencies, internal teams, client, stakeholders. Then think over possible solutions as a group.
The difficulty for most projects is the client relationship and how you approach risks in the project. Honesty is the best policy, and starting your relationship in this way will encourage that behaviour for all teams involved, so any issues are confidently brought to light immediately.
There are a few things you'll need to bring or prepare for this meeting to make the most of everyone's time, including: