So als Freiberufler beginnt man ja wirklich oft neue Projekte. Und zu Beginn eines neuen Projekts macht es immer Sinn ein sogenanntes Kickoff Meeting mit allen Beteiligten zu machen. Aber was genau ist ein Kickoff Meeting? Was sollte im Kickoff Meeting am Besten passieren und wie strukturiert man es?
Was ist ein Kickoff Meeting?
Beginnt ein neues Projekt, gibt es einiges zu klären. Insbesondere, wenn das Team neu zusammen kommt oder länger nicht mehr in dieser Konstellation gearbeitet hat: Worum gehts hier eigentlich? Was ist das Ziel der ganzen Nummer? Wer macht was? Wo kommuniziert man? Wo und wie dokumentiert man? Usw. usf. …
Und mit dem Kickoff Meeting ist es so, wie auch mit einer Constraints Analyse oder einer Risklist: Besser man macht das Ganze ein mal am Anfang ordentlich, damit es einem nicht die ganze restliche Produktion konstant in den Allerwertesten beißt. Aber welche Themen gehören eigentlich in so ein erstes Meeting und welche nicht?
Die Agenda im Kickoff Meeting
Grundsätzlich gilt für Kickoff Meetings erst mal das Gleiche, was für gute Meetings generell gilt: Sie sollten ein klares Ziel haben, gut vorbereitet werden, strukturiert sein. Jeder sollte wissen warum er oder sie da ist und was das Ziel des Meetings ist. Und die Agenda sollte existieren und einigermaßen durchgezogen werden. Die Themen, die aber darüber hinaus zu Beginn eines Projekts immer geregelt werden müssen, sind:
1. Was machen wir hier eigentlich?
Man sollte meinen, dass das den meisten, die an einem solchen Meeting teilnehmen doch schon klar sein sollte. Und tatsächlich meinen die meisten, die ein solches Meeting organisieren das all zu oft auch, so dass sie das eben nicht noch mal explizit thematisieren. Fakt ist aber auch, wie Ralf Adam mal zu mir sagte (sehr frei zitiert, weil schon viele Jahre her. So Ralf, wenn du das liest und dich falsch zitiert fühlst, give me a Call 😉 ):
Es ist erschreckend, wie oft man in einer Produktion unterschiedliche Leute aus einem Team fragt, an was für einem Projekt sie eigentlich arbeiten und man bekommt gänzlich unterschiedliche Antworten.
Und ich kann bestätigen: The Problem is real 😉 Und: Das Problem ist fast immer ein Führungsversagen, denn Führung heißt halt eben, den Fokus hoch zu halten.
Um das möglichst direkt von Anfang an zu verhindern, macht es also Sinn nach der normalen Begrüßung und dem ganzen Standard Geschalla des Meetings in einem dezidierten Kickoff Meeting direkt mal klar und unmissverständlich zu erklären, um was es bei dem neuen Projekt eigentlich ganz genau geht. Sprich:
- Was für ein Produkt wollen wir hier machen?
- Warum wollen wir dieses Produkt machen?
- Was ist die Vision und – falls vorhanden – die Ideologie dahinter?
- In welchem Fall würden wir das Produkt zum Ende hin als „gut“ betrachten?
- In welchem Fall würden wir das Produkt zum Ende hin als „fertig“ betrachten?
- Und wenn man möchte: Wie sind wir eigentlich auf die Idee gekommen, so ein Produkt zu machen? ….dann hat man gleich ne Basis für das spätere Marketing Narrative, ohne sich später irgendeinen Blödsinn ausdenken zu müssen…
2. Wer ist unser Team?
Weil ja Produkte tatsächlich nur so gut werden können, wie das Team ist, das dahinter steht, würde ich diesen Punkt auch schon sehr früh abfrühstücken: Welche Personen sitzen hier eigentlich gerade noch mal in diesem (digitalen) Raum? Und warum sind die hier nicht nur rein zufällig reingestolpert, sondern warum haben die einen echt guten Grund um hier zu sein. Bei der Gelegenheit auch: Was sind noch mal ihre Kompetenzen und warum sind sie die besten für den Job?
Sprich: Nutzt die Chance und stellt die Teammitglieder noch mal vor, auch und gerade wenn sich schon einige der Anwesenden kennen oder schon zusammen gearbeitet haben. Und vor allem: Sagt an dieser Stelle klipp und klar, wer für was zuständig ist. Nein, das wissen nicht eh schon alle. Nein, das kann man definitiv nicht oft genug sagen! Es gibt vermutlich echt keinen einzigen Grund, der für mehr Zoff im Team sorgt, als wenn unklar ist, wer für was zuständig ist oder hätte sein sollen. Erstickt das gleich und von Anfang an im Keim! Kein Mensch braucht sinnloses Kompetenzgerangel im Team, nur weil dieser Punkt mal versäumt wurde!
3. Wie kommunizieren wir im Team?
„Kommunikations-Pipelines“. Keine Ahnung, ob den Begriff heute noch wer kennt oder ob er nicht sogar in einem Haufen Branchen eigentlich noch geläufig ist. Aber ich habe ihn seit Jahren nicht mehr gehört. Aber trust me: Das ist etwas, das man in einem Team braucht. Es bedeutet so viel wie: Durch welche Kanäle kommuniziert wer mit wem.
Also fangen wir mal von vorne an. Die erste Frage ist ergo:
Welche Kanäle nutzen wir?
Gerade in Zeiten, wo Remote Teams, sprich Teams, wo die meisten oder alle von unterschiedlichen Orten aus arbeiten, immer häufiger vorkommen und in meinem Arbeitsalltag tatsächlich seit fast 20 Jahren die Regel sind, ist diese Frage wichtiger denn je. Und ich sage das ganz ehrlich: Ich begrüße die Entwicklung hin zu Remote Teams sehr. Mal von den vielen anderen Vorteilen eines Remote Teams abgesehen, zwingt uns diese Entwicklung die aktive Frage nach den Kommunikationskanälen erneut auf. Denn kaum etwas ist in diesem Bereich weniger zielführend, als wenn wichtige Absprachen zwischen Tür und Angel am Kaffee Automaten mal so zwischendurch geführt werden. Denn die Konsequenz davon ist allzu oft, dass weder alle benötigten Parteien dabei waren, noch dass das Besprochene ordentlich dokumentiert oder in konkrete ToDos überführt wurde.
Aber auch in Remote Teams kann uns das Problem wieder begegnen, wenn beispielsweise wichtige Absprachen mal eben schnell ohne Doku, ohne resultierende Tickets und ohne alle benötigten Beteiligten in einer PN, per Whatsapp oder in nem Spontan Anruf geregelt werden. Mit sinnvollen Kommunikations-Pipelines lässt sich das vermeiden! Und zwar, indem man von Anfang an gemeinsam festlegt, über welche Plattform die schriftliche Kommunikation und die Video Calls erfolgen sollen (zum Beispiel Discord, Slack, Teams). Hier habe ich auch schon mal geschrieben, wie man beispielsweise Discord gut dafür nutzen kann und wie nicht
Im Prinzip kann man hier alles nehmen. Aber ich würde immer ein Tool bevorzugen, was sowohl Text – organisiert nach Kanälen – als auch Video Calls unterstützt. Also sowas wie Discord, Slack oder Teams. Wichtig ist nicht so sehr, WELCHES Tool man dafür nutzt. Sondern wichtig ist, DASS man ein Tool DURCHGEHEND nutzt. Denn kaum etwas ist nerviger, als irgendwas, was irgendwann mal irgendwo irgendwer gesagt hat über zich verschiedene Kanäle und Plattformen suchen zu müssen. Nervt echt total!
Wer spricht mit wem?
Bei der Gelegenheit macht es zudem auch durchaus Sinn mal darüber zu sprechen, wer mit wem über was spricht. Natürlich kann, darf und soll im Team jeder mit jedem über alles sprechen. Hey freies Land und so. Aber bei manchen Themen macht es durchaus Sinn, wenn sich zuerst die vorher als zuständig definierten dazu äußern.
Beispiel: Ein Artist postet auf der Basis der Art Description des Art Directors in den entsprechenden Chanel ein neue Concept Skizze. Jetzt können gerne alle schreiben, wie toll sie die Skizze finden. Ehrlich, bitte macht das. Ich weiß gar nicht, wann das aufgehört hat. Wir sind doch alle hier, weil wir was cooles machen wollen und nicht nur um unsere Miete zu bezahlen? Was aber keinen Sinn macht, ist, dass jetzt jeder im Team schreibt, was er anders gemacht hätte und was für tolle Ideen er hat, wie es besser wäre. Denn das ist aus zwei Gründen null zielführend: Erstens berücksichtigen diese Kommentare mit an Sicherheit grenzender Wahrscheinlichkeit nicht die Art Description. Und damit lassen sie die tatsächlichen Anforderungen an die Skizze in der Regel außer acht. Und ganz oft berücksichtigen diese Kommentare auch nicht die Regeln des guten Feedbacks. Denn Feedback geben – insbesondere Künstlern – muss man können.
Und ich sag`s noch mal: Nervt nur. Den Artist, weil er Feedback bekommt, mit dem er nichts anfangen kann und das ihn eventuell frustriert. Das Team, weil es ja oft gute Ideen einbringt, die aber an dieser Stelle und zu diesem Zeitpunkt im Prozess nicht berücksichtigt werden können, weil sie nicht die Anforderungen der Art Description berücksichtigen. Und den Art Director. Denn der muss dafür sorgen, dass der Artist wieder fokussiert arbeitet. Deswegen sollte in einem Team klar sein, wer wem auf was Feedback gibt und wer die Abnahmen der Assets macht.
4. Wie dokumentieren wir im Team?
Oh, das legendäre Thema der Doku. Fast so umstritten, gehasst und oft nicht gemacht, wie das korrekte Vergeben von Asset IDs und das führen von Assetlisten. Ohne wenn und aber: Man braucht Doku! Wer was anderes behauptet, hat entweder keine Ahnung oder bisher nur Projekte mit der Komplexität eines Toastbrots gemacht. Das ganze Thema Doku würde hier den Rahmen sprengen und braucht irgendwann mal einen eigenen Artikel. Aber in Kürze:
Exkurs: Gute Doku
Es muss dokumentiert werden, wie das Spiel oder die Anwendung aussehen soll. Diese Doku sollte für jeden im Team einsehbar sein und sie sollte so aufgebaut sein, dass jeder im Team damit arbeiten kann. Sie sollte so kurz wie möglich und so lang wie nötig sein. Und es darf keine doppelte Buchführung geben. Inhalte dürfen also nicht an mehr als einem Ort und damit doppelt dokumentiert sein. Denn dann ist die Gefahr, dass es an einer Stelle aktualisiert wird und an der anderen nicht und es so zu Fehlern kommt einfach viel zu groß. Davon abgesehen, dass das unökonomisch wäre. Als SneakPeak: Nutzt einfach ein Wiki. Zum Beispiel von Confluence oder von Notion und packt alle wichtigen Infos auf einzelne Seiten und vernetzt sie dann klug.
Bei Doku ist wichtig, dass sie – genau wie Assetlisten – konstant aktualisiert wird. Doku muss als lebendiges Dokument angesehen und gepflegt werden. Doku muss nicht perfekt sein, aber da und aktuell! Und dafür muss klar sein, wer was wann und wo dokumentiert. Und das am Besten von Anfang an, weswegen das gleich im Kickoff Meeting geklärt werden sollte. Legt fest:
- auf welcher Plattform die Doku erfolgen soll
- Wer was dokumentieren soll
- Wann dokumentiert wird (ich persönlich halte sehr viel davon, kleinere Änderungen immer sofort zu aktualisieren, auch schon während der Meetings)
- Und wer die Doku ändern darf und wer nicht und wer und wie man am besten Kommentare da lässt.
5. Wie planen wir im Team die nächsten Schritte und Monate?
Man kann einfach drauf los arbeiten. Aber vermutlich unnötig zu erwähnen, dass ich das bei den aller allermeisten Projekten nicht für die richtige Lösung halte. Es ist einfach simple as that: Wenn das Team einen klaren Fokus hat und genau weiß worauf sie hin arbeiten, mobilisiert das Kräfte, motiviert und vermeidet so gut es geht sinnlose Arbeiten und Prozessverluste. Dabei muss nicht von Anfang an eine sogenannte Wasserfallplanung gemacht werden, die von hier bis Jericho jeden vermeintlichen Mini Task zum Erreichen des Endziels oder aber des nächsten Milestones festlegt. Aber was es auf jeden Fall braucht, ist mindestens das nächste Ziel, auf das aktuell hingearbeitet werden soll. Egal, ob das als Milestone oder als Gate oder was auch immer definiert wird. Klar, idealerweise hat das Management noch über diesen einen nächsten Milestone hinaus eine Ahnung wo es hingehen soll. Aber das Team braucht vor allem den nächsten.
Irgendwie sollte dieses nächste Ziel oder aber auch besser gleich die nächsten Ziele schriftlich und auch gerne gleich noch irgendwie visuell fixiert sein. Und zwar irgendwo zentral in der Doku, dass diese Produktionsplanung jeder sehen kann. Mein Prof hat mir damals bei meiner Diplomarbeit gesagt: „Druck das Thema deiner Diplomarbeit riesengroß aus. Oder schreib es gleich besser auf ein riesiges A2 Plakat in fetten Buchstaben. Und hänge es direkt an deinen Arbeitsplatz vor deine Nase an die Wand, damit du ständig drauf schaust.“ This 😉
6. Wie organisieren wir im Team Aufgaben?
Hat man eine Produktionsplanung oder / und zumindest das Team ein Ziel, auf das es hinarbeitet, ist die Frage: Wie zerlegen wir dieses große Ziel in viele kleine Aufgaben, verteilen diese, dokumentieren diese, halten diese aktuell? Hierzu gibt es natürlich zich verschiedene Methoden.
Bei einer traditionellen Wasserfallplanung plant man ein Projekt von Anfang an direkt bis zum Ende in jedem kleinen Detail durch und zerlegt alles in To Dos. So hat man scheinbar von Anfang an einen guten Überblick über den gesamten Ablauf des Projekts. Aber diese Art zu Planen wird den allermeisten modernen Produktionen kaum noch gerecht. Spätestens wenn man ein innovatives Produkt macht und ergo nicht von Anfang an wissen KANN, wo die Reise hingeht, klappt das so nur sehr bedingt.
Auf der anderen Seite der Skala stehen agile Methoden, die prominenteste sicher Scrum. Bei diesen Methoden werden die großen Themen (Epics), wie zum Beispiel große Features, erst in kleinere Aufgaben zerlegt, wenn deren konkrete Bearbeitung ansteht. Und somit passiert der größte Teil der Planung im Prinzip hochaktuell von Woche zu Woche in sogenannten Sprints. Der Nachteil hier ist, dass sich mit einer echten agilen Methode kaum sinnvoll Deadlines einhalten lassen. Und auch große Produktionen, wo viele Prozesse vorausschauend parallelisiert werden müssen, sind damit eigentlich nicht zu stemmen.
Das Beste von Beidem
Ich arbeite in der Praxis eigentlich immer mit einem auf das jeweilige Projekt angepassten Hybridmodell. Dabei behalte ich einerseits anhand einer High Level Produktionsplanung das große Ganze und die Deadlines im Auge. Und andererseits – wenn es mir aufgrund einer überschaubaren Teamgröße und Komplexität des Projekts möglich ist – organisiere ich die praktische Arbeit des Teams in aktuellen, auf das nächste Gate (Deadline) ausgerichteten wöchentlichen Sprints. Aber ich sag`s wie es ist: Spätestens bei echt großen Produktionen mit mehreren großen Departments geht eigentlich so eklig es ist, fast nur noch ne Wasserfallplanung.
Egal wie man es machen will, im Kickoff Meeting sollte immer festgelegt werden:
- Was für eine Art des Projektmanagements im Team genutzt werden soll
- Woher klar wird, welche Aufgaben anstehen
- Wer die Aufgaben verteilt
- Welche Software für das Projektmanagement genutzt wird
- Wie die Aufgaben in der Software notiert werden sollen
- Wie die Aufgaben Up to Date gehalten werden und wer dafür zuständig ist
- Welche regelmäßigen Meetings es geben wird und wer da mit wem über was spricht
Das Kickoff Meeting in a Nutshell
Jopp. Und das wars. Mag erstmal viel erscheinen. Aber all diese Themen müssen in einem Team, was nicht winzig ist und sehr überschaubare Projekte macht, so oder so geklärt werden. Andernfalls führen sie früher oder später ganz sicher zu vermeidbaren Problemen. Und all diese Themen könnt und solltet ihr direkt zu Anfang in einem Kickoff Meeting klären.
Produktion so oder so
Es gibt da zwei ganz wunderbare Grafiken aus dem ebenso großartigen Buch „Software Project Survival Guide“ von Steve McConnell (klare Leseempfehlung, kein Affiliate Link), die in etwa so viel sagt wie: Ich kann entweder am Anfang des Projekts etwas Aufwand in das definieren und optimieren der Prozesse stecken. Dann habe ich zwar Anfangs ein bisschen weniger Kapazitäten für die wirklich produktive Arbeit. Und ein bisschen Trashing – also Prozessverluste, unproduktive Arbeiten, Mist den man baut – hat man halt leider immer. After all sind wir alle nur Menschen.
Oder aber, ich tue das nicht. Dann spare ich anfangs erstmal Kapazitäten ein und kann direkt am Anfang mehr Zeit in wirklich produktive Arbeit stecken. Aber das rächt sich praktisch IMMER. Denn die Kapazitäten, die durch Prozessverluste, Misskommunikation, Mist, der gebaut wird, kurz „Trashing“ wegfallen nehmen dann über den Verlauf des Projekts dramatisch zu. Und dazu kommt, dass ich mich dann auch zunehmend – egal ob ich will oder nicht – mit den nicht funktionierenden Prozessen auseinandersetzen muss. Denn sie fangen an, mir konstant um die Ohren zu fliegen.
Tja und das Resultat seht ihr unten: Dann hat man irgendwann gar keine Zeit mehr für produktive Arbeit, weil man quasi nur noch Feuerwehr spielt.
Organisiert ihr also euer Kickoff Meeting gut und zieht all das, was oben steht, gut vorbereitet mit einer straffen Agenda und genügend Kaffee und Sweats durch, dann habt ihr das Thema nicht nur erstmal größtenteils von der Backe. Sondern ihr habt in den nächsten Monaten auch 3000% weniger Probleme, weniger Prozessverluste, weniger sinnlose Meetings und weniger Frust, Stunk und Drama im Team. Simple as that.
