Die Frage, die Kickoff-Meetings überspringen

Ein Projekt-Kickoff, der gut läuft, lässt das Team ausgerichtet auf das Was, das Wer und das Wann. Diese Ausrichtung hält in der Regel etwa drei Wochen. Dann schleicht sich Scope Creep ein, ein Stakeholder ändert seine Meinung über eine Kernannahme, eine Abhängigkeit slippt, und das Team stellt fest, dass sie sich nie darauf geeinigt haben, wer die Entscheidung trifft, wenn zwei vernünftige Menschen uneins sind.

Die Frage, die die meisten Kickoff-Agenden überspringen, ist: Wie wird dieses Team Entscheidungen treffen, wenn etwas schiefläuft? Nicht den Projektplan – den Entscheidungsrahmen. Wer hat den Scope in der Hand, wenn ein Feature gestrichen werden muss? Was macht das Team, wenn eine technische Einschränkung eine Produktanforderung invalidiert? Welcher Stakeholder hat das letzte Wort, wenn zwei Abteilungen unterschiedliche Dinge wollen?

Diese Fragen sind einfach im Kickoff zu beantworten, weil noch nichts auf dem Spiel steht. Sie sind viel schwieriger mid-Projekt zu beantworten, wenn alle eine Position haben. Die folgende Vorlage reserviert Zeit für sie, bevor der schwierige Teil beginnt.

Die Agenda (zum Kopieren)

Dauer: 60–90 Minuten je nach Projektkomplexität
Format: Moderiert; alle wichtigen Stakeholder und Mitwirkenden anwesend oder vor Beginn async überprüft

Abschnitt 1 – Projektziel und Scope (20 min)

Das Ziel in einem Satz: Wie sieht Erfolg aus, wenn möglich messbar?
In-Scope: Was das Projekt liefern wird, konkret benannt
Out-of-Scope: Was dieses Projekt explizit nicht tun wird – mindestens drei Dinge aufzählen
Erfolgskriterien: Woran wird das Team erkennen, dass das Projekt abgeschlossen ist?
Der EM oder PM leitet diesen Abschnitt; Engineers pushback, wenn der genannte Scope nicht zur Machbarkeit passt

Abschnitt 2 – Rollen und Ownership (15 min)

Für jeden Workstream einen Owner nennen – nicht ein Team, eine Person
Wer trifft die endgültige Entscheidung bei: Produkt-Scope, technischer Architektur, externer Kommunikation?
Wer ist informiert vs. konsultiert vs. Entscheider bei jedem wichtigen Entscheidungstyp?
Den Projektlead benennen, der accountable ist, wenn nichts anderes klar ist

Abschnitt 3 – Einschränkungen und Risiken (15 min)

Harte Einschränkungen: Deadline, Budget, Compliance, Abhängigkeiten von anderen Teams
Bekannte Risiken: Was sind die drei Top-Dinge, die dieses Projekt entgleisen lassen könnten?
Für jedes Risiko: Wahrscheinlichkeit, Auswirkung und Mitigation-Owner
Was würde dazu führen, dass das Projekt abgebrochen oder erheblich descoped wird? Jetzt benennen

Abschnitt 4 – Kommunikationsplan (10 min)

Wie oft wird das Team synchronisieren? In welchem Format?
Wer bekommt ein Status-Update, und wie? Nicht annehmen, dass Stakeholder denselben Kanal wollen
Wo lebt die Projektdokumentation?
Was ist der Eskalationspfad, wenn etwas das Projekt blockiert?

Abschnitt 5 – Offene Fragen (15 min)

Jede Frage auflisten, die das Team heute nicht beantworten kann
Für jede: einen Owner und ein Datum zuweisen, bis zu dem die Antwort gebraucht wird
Fragen ohne Datum und Owner werden auf halbem Weg immer noch offen sein

Abschnitt 6 – Nächste Schritte (10 min)

Die drei Dinge, die in den nächsten fünf Arbeitstagen passieren müssen, um echte Arbeit zu starten
Jeder nächste Schritt hat einen einzigen Owner
Bestätigen, wie das Kickoff-Recap verteilt wird und an wen

Was gängige Kickoff-Vorlagen falsch machen

Die meisten Kickoff-Vorlagen sind gründlich beim Projektplan und dünn darin, was passiert, wenn der Plan nicht hält. Sie produzieren ein sauberes Scope-Dokument und eine RACI-Matrix – beides nützlich. Sie produzieren keine gemeinsame Antwort auf „Was machen wir, wenn der Datenbankvendor seinen Preis mid-Projekt verdreifacht?" oder „Was wird gestrichen, wenn wir die harte Deadline bei 80 % Feature-Vollständigkeit erreichen?"

Das Fehlen von Scope-Out ist eine weitere konsistente Lücke. Zu nennen, was im Scope ist, ist unkompliziert. Zu nennen, was explizit außen vor ist – drei oder vier konkrete Dinge aufzulisten, die das Projekt nicht tun wird – erzwingt dasselbe Gespräch über Stakeholder-Erwartungen, aber aus der anderen Richtung. Stakeholder, die davon ausgingen, dass der Mobile-Client enthalten ist, erfahren es im Kickoff und nicht in Woche sechs.

Die dritte Lücke ist der Abschnitt für offene Fragen. Teams wollen nicht zeigen, was sie im Kickoff nicht wissen, weil es wie das Eingestehen von Unvorbereitetheit wirkt. Aber unbekannte Antworten werden zu mid-Projekt-Blockern, und mid-Projekt-Blocker sind teuer. Je früher man weiß, dass die Frage existiert, desto früher kann jemand die Antwort ownen.

Wie diese Lücken über ein mehrmonatiges Projekt zu Overhead kumulieren: The Meeting Tax.

Warum Kickoff-Notizen richtig gemacht werden sollten

Das Kickoff-Dokument ist das am häufigsten referenzierte Artefakt in jedem Projekt. Es ist das, was die Leute prüfen, wenn der Scope angefochten wird, wenn ein neues Teammitglied hinzukommt, wenn ein Stakeholder fragt „haben wir X nicht im Kickoff entschieden?" Ein gut dokumentierter Kickoff ist ein Projekt, das einfacher zu managen ist.

Pavleur erfasst den vollständigen Kickoff automatisch: Scope wie angegeben, Rollen wie zugewiesen, Risiken wie genannt, offene Fragen mit Ownern, nächste Schritte mit Ownern und Daten. Wenn jemand das Projektbriefing, ein Diagramm oder ein Anforderungsdokument geteilt hat, ist das Visual mit der Diskussion im Bericht enthalten. Audio-only Tools zeigen, wer was gesagt hat; sie erfassen nicht das Architekturdiagramm auf dem Bildschirm, als der Tech Lead die Abhängigkeit beschrieb. Der resultierende Bericht dient von Tag eins als Source-of-Truth-Dokument des Projekts. Für einen Vergleich mit traditionellen Meeting-Capture-Tools: Pavleur vs. Alternativen.

Eine Anmerkung zur Teilnahme

Jeder, der voraussichtlich eine Entscheidung in diesem Projekt treffen wird, sollte am Kickoff teilnehmen oder eine vollständige Aufzeichnung und schriftliche Zusammenfassung vor Arbeitsbeginn überprüfen. Ein Stakeholder, der den Kickoff verpasst und den Scope informell zwei Wochen später erfährt, ist ein mid-Projekt-Scope-Streit, der darauf wartet zu passieren. Der Job des Kickoffs ist es, geteilten Kontext aufzubauen – und geteilter Kontext existiert nur, wenn die relevanten Personen im Raum sind.