Kick-off Meeting
We begin every project during the Groundwork phase with a Kick-off Meeting between our team and key stakeholders from the collaborator. This is usually conducted remotely and generally facilitated by the Project Steward.
This is to make sure that everyone has met one another and we're on the same page before we begin work. This will establish how we work with the collaborator, clarify any outstanding questions from both sides and agree on the key things we are building together.
We are trying to build trust with the collaborator in this meeting. Trust is the fuel by which the rest of the project will run. It is really important to listen very carefully during the meeting to what is being said and if there are any crucial things not being said.
We have a standard template on FigJam for running these meetings. The template and the sections outlaid here are those we've found most effective for running a Kick-off Meeting. However, it might be useful to trim the meeting as needed. For example, if the project has no visual element, there is no point having a discussion of it. It is wise to leave the pre-mortem section in. This generates a lot of valuable information.
Before the meeting, the Project Steward should reflect upon their goals for the meeting, any big questions that they have, and what is feasible to cover within the time available, considering that there will be a fair bit of time at the beginning for introductions and at the end for next steps.
Prioritise knotty problems that are best to untangle collaboratively and synchronously. If needed, the more straightforward aspects like project management tools, sign-off responsibilities and timelines can be done over email.
How long should the meeting be?
These meeting should take a maximum 90 minutes.
We want this meeting to end on time. This demonstrates that our meetings end on time and are well organised, which often helps with drumming up people to participate down the line.
Who should be involved?
We want to invite the widest possible amount of people from the collaborator to come, as this may be the only point we can get access to wider people within the collaborator's organisation. It's important therefore to bring people in and get a variety of perspectives.
We've found there are limits to how well a remote kick-off workshop can operate in terms of numbers. Eight is probably the maximum amount of people to effectively run a Kick-off Meeting. Two is probably the minimum: here the process is going to be more of an interview than a workshop, where we take notes while asking each section as a direction question to the collaborators.
From our side, the Project Steward should attend and then any major member of staff who will be working on the project, the designer, researchers or software engineers who will be involved.
We can record the Kick-off Meeting so people who are unable to attend can catch up. From our side this is quite useful for new people being added into the project.
A workshop, not a meeting
This is intended to be a collaboration between us and the collaborator, working together to kick-off. So explaining the work we are going to do together is an important element.
Over explaining everything
We make an effort to explain everything as you go along in general, but performatively so in the Kick-off Meeting.
This is the first time some people will have met us, so it is important that people know we will kindly move them through things, rather than baffling them with technobabble. It's subtle, because we don't want to patronise, but we do want to lower anxiety from the collaborator's side, especially when they are not used to doing digital work and this can be scary.
Bringing our own meeting technique to the kick-off
It is nice to bring our typical meeting practices to the Kick-off Meeting as it sets the tone culturally. After explaining what check in and check out are, we invite people to check in. Often Common Knowledge staff will go first in order to set the tone and make it clear what sort of thing it is acceptable to say in a check in.
Consent to agenda can be more informal, which a quick walk through of the FigJam board to tell them what is coming up and what to expect. Sometimes people will feel they won't be able to have their say about a particular aspect of the project. Making sure they know that most sorts of things do have a bucket in the kick off format
Normally check outs in a kick off meeting are a way of everyone expressing their excitement and commitment to the project. However, so people get the hang of check outs, it might be useful for Common Knowledge staff to engage in more regular check out, bringing a bit of reflection on what bits were effective and which bits need a bit of a tweak for next time.
If you think this is not going to work, you can drop trying to do this. Ultimately we want to have an effective kick off, but since people are working with Common Knowledge partly because of who we are and how we operate, we should bring this with us if we can.
Framing the project
The first bit of the FigJam board is summarising what we take the project to be. This grounds everyone in what we are considering here and allows them to say if we've got it completely wrong.
Making sure everyone can use the tools
As digital whiteboarding tools go, FigJam is less familiar to people than Miro, but pretty easy to use.
But you shouldn't assume that people can use it. At the start of the meeting, ask people how familiar they are with these sorts of tools and if they express they aren't that familiar, then give a little tutorial on the basics like creating a new sticky note. Even once people have received this tutorial, don't assume they will just get it. Watch how people are using the board during the activities and if people seem to be struggle, feel free to demonstrate again, sensitively.
Making sure strategy and theory of change are attended to
In the Kick-off Meeting we discuss how this work fits into a wider strategy for the collaborator, their goals and theory of change. It's really important to get under the hood of this. Common Knowledge isn't putting things into the world just to do it, it is doing so to bring about political change. So making sure the work slots into the wider strategy and being really intentional about this is really important. Understanding the broader context right from the start is crucial.
Plenty of organisations are able to produce digital work. What Common Knowledge brings is deep understanding of organising and bringing about political change and huge concern for actually bringing about change, rather than talking about bringing about change. So we are going to keep this in by discussing strategy and theory of change in the kick-off.
The Pre-Mortem
We run a pre-mortem during the Kick-off Meeting, to identify ways in which the project will not go well and not meet its goals and some mitigations for this. Where projects have not gone well, we can almost always see in these pre-mortem the precise thing that has been the problem. Regular looking back at this exercise and asking "is any of this bad stuff happening?" is very useful. It is useful to say this out loud: "though it seems a bit sad to think about what might go wrong, we've found it is really important - this list we are making today will almost certainly tell us some stuff that goes wrong".
Aesthetic preferences
For a project with a strong visual element, we talk through things that what things are needed and any aesthetic red lines they might have. Often people, for example, really don't want specific colours due to their political associations.
We can ask them for other reference materials like other websites or tools to be inspired by. Often people find it hard to come up with these things from a cold start, so it is useful to tell them these questions will be asked in the email inviting people to the kick-off.
Project tools
We explain the tools we will be using, which is typically Linear for project management and Productive for keeping track of time and budgets. Try and establish if people will need training on these tools. A lot of people will just jump in once they have an account, but sometimes people prefer more formal training. We should offer this.
Project walk through and timelines
We explain each phase of the project, their purpose and goals. You can usefully link to this guide so people have something to read!
We also explain the calendar timeline of the project. We need to really establish how hard or soft the deadlines involved are. In projects working to particular political timelines, a deadline may be totally inflexible and we want to hear this clearly. Sometimes things will be more flexible, but knowing what is and is not moveable is important.
Project communications
Finally we explain the ways in which we will communicate between ourselves and the collaborator. We like to communicate with collaborators in ways they find useful. Therefore we will always jump on their Slack or use Signal, wherever they tend to look at day to day. If they don't have some kind of real time chat already, we don't insist on one. After all, Common Knowledge tries not to use real time chat. If in doubt, we fall back to email.
It is important to remind people that the most core way we will be communicating day to day is on Linear. Linear is the place you should go to get a passive update on things ticking along.
Pressing home the need for content
Especially with content based websites, its really important to drive home that content is really really important. It takes a long time to write and arrange words. People really underestimate how long it will take. This is even the case with tools, as there is always some peripheral communication to be written, like a press release, or some internal micro-copy to explain to users how to use things. In political work, words really matter, so there is often a lot of back and forth and sign off from the collaborators side. Reminding everyone of this is important. By content, we mean mainly copy and words, but it can also be photography.
The collaborator needs to recognise the need and effort required to produce content, but should also consider if they genuinely have the resources (in terms of staffing or time) to produce and maintain the content. They need to consider the who as well as that what of content. For example, on reflection they might think that they do not have the capacity to maintain a news section of a website, so it might be best to drop this as a requirement. This is smart thinking!
For us, we will need at least some content to do most work. This is especially true with design elements. Some impression is needed before anyone can begin on design language or layouts. It doesn't need to be the final locked down version. Almost anything will enable us to make a start.
Pressing home that this needs to be thought about as early as possible is something people should really step away from the meeting with.
Watching for dynamics in the Kick-off Meeting
We are paying attention to more subtle dynamics occurring during the meeting:
- What are the power relationships between people involved in this project?
- What are the power relationships between between the people involved and the wider organisation? Is there going to be some crucial person who will want final sign off, or are the people in the meeting able to make this decision?
- Who is not in this meeting but is being mentioned a lot?
- What are the tensions going on here?
- Are there any third parties (for example, previous people who they've worked with) we need to know about and interact with in this project? Our approach should always be collaborative and friendly with these people.
- Do we think the person who is leading the project from their side has a lot of digital skills or is just making a start? Are they likely to be super distracted by other important things?
- What are people worried about? Organisations are often doing quite complex and experimental things to bring about social change, and they will naturally have doubts about if it will work. We want to pay attention to this.
- Is there some previous project or event that is in people's minds when they are approaching this work, especially something that has gone wrong? Will this be a frame they are bringing to this work it might be hard to discard?
Feel free to make some notes about things you have observed. Often the key to successes and difficulties in work is working with these dynamics. Examine the situation as an organiser would. A fun thing to do is occasionally observing these dynamics in the meeting itself and asking people to reflect on this. It often brings the most rich insight. For example, "noticing you are very worried about how the press will react to this element of the campaign strategy - why is that?".
Wrapping up the Kick-off Meeting
After the Kick-off Meeting it is nice to send a short summary and share a PDF of the Kick-off Meeting, repeating next steps, which are probably "please give us access quite a few things".