---
name: project-kickoff-brief
description: Schreibt aus einem Ziel und groben Notizen ein einseitiges Kickoff-Briefing für ein Projekt - Ziel und warum es zählt, ein Erfolgsmaß, Scope drin und draußen, Meilensteine mit Datum, Rollen in einer schlanken RACI-Tabelle mit einer verantwortlichen Person, die größten Risiken mit je einer zuständigen Person und wie das Team kommuniziert. Nutze sie, wenn ein Projekt startet, jemand ein Kickoff-Dokument, einen Projektsteckbrief, ein Project Charter oder ein Projektbriefing möchte oder ein Team vor dem Start klären muss, wer was macht.
---

# Kickoff-Briefing für ein Projekt

Ein Kickoff-Briefing sorgt dafür, dass sich alle vor dem Start einig sind: warum es das Projekt gibt, wie „fertig“ aussieht und wem was gehört. Es passt auf eine Seite. Alles, was nicht ändert, was die Leute diesen Monat tun, kommt in ein verlinktes Dokument.

## Wann du sie nutzt

- Ein neues Projekt, ein Launch, eine Migration oder ein Kundenauftrag startet, und alle brauchen eine gemeinsame Seite.
- Jemand bittet um ein „Kickoff-Dokument“, ein „Project Charter“, einen „Projekt-One-Pager“ oder eine „Vorablektüre für das Kickoff-Meeting“.
- Ein Projekt läuft schon, aber man ist sich über den Scope oder darüber, wer entscheidet, nicht einig. Schreib das Briefing, um neu aufzusetzen.
- Nicht für eine Produktspezifikation oder ein Anforderungsdokument. Was das Produkt tut, gehört in ein PRD; dieses Briefing regelt, wie das Projekt läuft.

## Was du brauchst

- Das Ziel und warum es jetzt zählt. Fehlt es, frag einmal: „Was ändert sich für das Unternehmen oder die Kunden, wenn das fertig ist?“
- Die Deadline oder das Zieldatum. Gibt es keins, schreib „[kein Datum festgelegt]“ und führe es als erste offene Frage auf.
- Die beteiligten Personen und ihre Rollen. Sind die Rollen unklar, liste die Namen auf und markiere die RACI-Tabelle mit „[Entwurf, beim Kickoff bestätigen]“.
- Optional: Budget, bekannte Einschränkungen, verwandte Projekte und alles, was schon entschieden ist.

## Schritte

1. **Schreib das Ziel in 1 oder 2 Sätzen.** Sag, was danach anders ist und warum das jetzt zählt. Der Kickoff-Leitfaden von Asana nennt es den wichtigsten Teil eines Kickoffs, sich darauf zu einigen, „worauf ihr hinarbeitet und warum diese Arbeit zählt“.
2. **Wähl ein Erfolgsmaß.** Eine Zahl mit Datum („40 Kunden bis 30. Juni auf den neuen Tarif umgestellt“) oder ein Ja/Nein-Test, den jede Person prüfen kann. Das Kickoff-Play von Atlassian nennt solche Tests „eine gemeinsame Definition von ‚fertig‘“. Standard dieser Skill: ein Hauptmaß, höchstens 2 Leitplanken (Dinge, die nicht schlechter werden dürfen).
3. **Teil den Scope in drin und draußen.** Liste 3 bis 6 Punkte im Scope und mindestens 3 außerhalb. Die Punkte außerhalb sind die, nach denen jemand auf halber Strecke fragen wird; sie früh zu benennen verhindert, dass der Scope ausufert. Ist ein Punkt unklar, gehört er zu den offenen Fragen, nicht in den Scope.
4. **Leg 3 bis 6 Meilensteine fest.** Jeder ist ein fertiges, prüfbares Ergebnis mit Datum und zuständiger Person („Preisseite auf Staging live“), keine Tätigkeit („an der Preisseite arbeiten“). Der letzte Meilenstein ist das Datum des Erfolgsmaßes.
5. **Füll die schlanke RACI-Tabelle.** Eine Zeile pro Arbeitspaket. Responsible macht die Arbeit; Accountable gibt frei und verantwortet das Ergebnis; Consulted prüft, bevor es weitergeht; Informed wird über den Fortschritt informiert. Der RACI-Leitfaden von Asana: „Pro Aufgabe sollte es nur eine Accountable-Rolle geben.“ Standard dieser Skill: auch für das ganze Projekt eine Accountable-Person, oben namentlich genannt.
6. **Liste die 3 bis 5 größten Risiken.** Zu jedem: was schiefgehen kann, wie wahrscheinlich (hoch/mittel/niedrig), was du jetzt tust und eine zuständige Person. Schnell findest du sie mit dem Pre-Mortem von Atlassian: Das Team schreibt still auf, was schiefgehen könnte, stimmt dann über die größten Gefahren ab und gibt jedem Top-Risiko eine Maßnahme mit zuständiger Person. Ein Risiko ohne zuständige Person ist eine Sorge, kein Plan.
7. **Sag, wie das Team kommuniziert.** Wo der tägliche Austausch läuft (Channel), wie der Fortschritt geteilt wird (ein wöchentliches schriftliches Update, Tag und Verfasser), wann sich die Gruppe trifft und wo Entscheidungen festgehalten werden. Der Kickoff-Leitfaden von Asana führt das als festen Teil des Kickoffs.
8. **Liste offene Fragen und schon Entschiedenes.** Offene Fragen bekommen eine zuständige Person und ein Datum. Bereits Entschiedenes steht in je einer Zeile, damit der Kickoff es nicht wieder aufmacht.

## Ausgabeformat

```markdown
# [Projektname] — Kickoff-Briefing

**Verantwortlich (Accountable):** [ein Name] · **Start:** [Datum] · **Zieldatum:** [Datum oder „kein Datum festgelegt“]

## Ziel
[1–2 Sätze: was sich ändert, für wen und warum jetzt.]

## Erfolgsmaß
- **Hauptmaß:** [Zahl + Datum oder Ja/Nein-Test]
- **Leitplanken:** [was nicht schlechter werden darf, oder streichen]

## Scope
| Im Scope | Nicht im Scope |
|---|---|
| [Punkt] | [Punkt] |

## Meilensteine
| Meilenstein (ein fertiges Ergebnis) | Zuständig | Datum |
|---|---|---|
| [Meilenstein] | [Name] | [Datum] |

## Rollen (schlankes RACI)
| Arbeitspaket | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| [Arbeitspaket] | [Name] | [ein Name] | [Namen] | [Namen oder Gruppe] |

## Risiken
| Risiko | Wahrscheinlichkeit | Was wir jetzt tun | Zuständig |
|---|---|---|---|
| [Risiko] | [hoch/mittel/niedrig] | [Maßnahme] | [Name] |

## Wie wir kommunizieren
- **Im Alltag:** [Channel]
- **Fortschritt:** [schriftliches Update, Tag, Verfasser]
- **Meetings:** [welche, wie oft]
- **Entscheidungen festgehalten in:** [Ort]

## Schon entschieden
- [Entscheidung, eine Zeile]

## Offene Fragen
- [Frage] — [zuständig], bis [Datum]
```

## Beispiel

**Eingabe:** „Wir ziehen unsere 120 aktiven Kunden vom alten Abrechnungstool (Billwise) zu Stripe um. Kickoff ist am 7. April; Billwise wird zum 30. Juni gekündigt. Jana leitet das, Marco macht die Integration, Aisha kümmert sich um die Kunden-E-Mails, die Buchhaltung (Lena) muss die neue Rechnungsvorlage bis 2. Mai freigeben. CEO Tom will, dass alles vor der Preisänderung am 1. Juli fertig ist. Marcos Plan: 5 interne Testkonten rechnen bis 25. April im Stripe-Testmodus korrekt ab, alle Kunden live bis 13. Juni. Aisha verschickt die Ankündigung bis 16. Mai, dann eine Erinnerung 1 Woche vor jedem Kundenumzug, und ruft die 20 größten Kunden an. Machen wir nicht: Historie gekündigter Kunden, ein Self-Service-Abrechnungsportal, Änderungen an der Buchhaltungssoftware. Sorgen: Gespeicherte Karten werden vielleicht nicht übertragen; jemand wird im Umstellungsmonat doppelt belastet. Fehlgeschlagene Zahlungen dürfen nicht steigen. Wir reden in #billing-migration, Jana schreibt freitags ein Update, wir treffen uns dienstags 20 Minuten, Entscheidungen kommen ins Projektdokument. Schon entschieden: keine Preisänderungen während der Migration. Lena will wissen, ob wir Billwise nach der Kündigung noch einen Monat schreibgeschützt behalten.“

**Ausgabe:**

```markdown
# Abrechnungsmigration zu Stripe — Kickoff-Briefing

**Verantwortlich (Accountable):** Jana · **Start:** 7. April · **Zieldatum:** 30. Juni

## Ziel
Alle Kunden vor der Preisänderung am 1. Juli von Billwise zu Stripe umziehen, damit die neuen Preise in einem einzigen System starten und Billwise gekündigt werden kann.

## Erfolgsmaß
- **Hauptmaß:** 120 von 120 aktiven Kunden werden bis 30. Juni über Stripe abgerechnet.
- **Leitplanken:** Kein Kunde wird in irgendeinem Monat doppelt oder gar nicht belastet; fehlgeschlagene Zahlungen bleiben auf oder unter dem aktuellen Monatsniveau.

## Scope
| Im Scope | Nicht im Scope |
|---|---|
| Umzug der aktiven Abos und gespeicherten Karten | Preisänderungen (entschieden: keine während der Migration) |
| Neue Rechnungsvorlage, freigegeben von der Buchhaltung | Umzug der Historie gekündigter Kunden |
| Kunden-E-Mails vor und nach dem Umzug | Ein neues Self-Service-Abrechnungsportal |
| Kündigung von Billwise | Änderungen an der Buchhaltungssoftware |

## Meilensteine
| Meilenstein (ein fertiges Ergebnis) | Zuständig | Datum |
|---|---|---|
| Stripe-Testmodus rechnet 5 interne Konten korrekt ab | Marco | 25. April |
| Rechnungsvorlage freigegeben | Lena | 2. Mai |
| Ankündigungs-E-Mail an Kunden verschickt | Aisha | 16. Mai |
| Alle 120 Kunden live auf Stripe | Marco | 13. Juni |
| Billwise gekündigt | Jana | 30. Juni |

## Rollen (schlankes RACI)
| Arbeitspaket | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Integration und Datenumzug | Marco | Jana | Lena | Tom |
| Rechnungen | Marco | Lena | Jana | Aisha |
| Kunden-E-Mails | Aisha | Jana | Lena | Tom |

## Risiken
| Risiko | Wahrscheinlichkeit | Was wir jetzt tun | Zuständig |
|---|---|---|---|
| Gespeicherte Karten werden nicht übertragen, Kunden müssen sie neu eingeben | Mittel | Diese Woche beim Billwise-Support fragen, ob ein Kartenexport zu Stripe unterstützt wird | Marco |
| Ein Kunde wird im Umstellungsmonat in beiden Systemen belastet | Mittel | Jedes Billwise-Abo am selben Tag abschalten, an dem es in Stripe startet; tägliche Kontrollliste | Marco |
| Kunden ignorieren die Ankündigung und verpassen die Umstellung | Hoch | Ankündigung bis 16. Mai, Erinnerung 1 Woche vor jedem Umzug; Aisha ruft die 20 größten Kunden an | Aisha |

## Wie wir kommunizieren
- **Im Alltag:** #billing-migration
- **Fortschritt:** schriftliches Update jeden Freitag von Jana
- **Meetings:** 20-minütiger Check-in dienstags
- **Entscheidungen festgehalten in:** Abschnitt „Entscheidungen“ im Projektdokument

## Schon entschieden
- Keine Preisänderungen während der Migration.

## Offene Fragen
- Behalten wir Billwise nach der Kündigung einen Monat schreibgeschützt? — Lena, bis [Datum beim Kickoff festlegen]
```

## Prüfen vor dem Senden

- [ ] Das Ziel sagt, warum jetzt, und das Erfolgsmaß ist eine Zahl mit Datum oder ein Ja/Nein-Test.
- [ ] „Nicht im Scope“ hat mindestens 3 Punkte, nach denen plausibel jemand fragen könnte.
- [ ] Jeder Meilenstein ist ein fertiges Ergebnis mit einer zuständigen Person und einem Datum.
- [ ] Jede RACI-Zeile hat genau eine Accountable-Person, und das Projekt hat oben eine namentlich genannte Verantwortliche.
- [ ] Jedes Risiko hat eine Maßnahme, die jetzt passiert, und eine zuständige Person.
- [ ] Kein Name, Datum oder Wert taucht auf, der nicht in der Eingabe steht; Lücken sind mit „[kein Datum festgelegt]“ markiert oder als offene Fragen aufgeführt.
- [ ] Es passt auf eine Seite.

## Häufige Fehler

- Ein Erfolgsmaß, das niemand prüfen kann („Abrechnung verbessern“). Frag, welche Zahl oder welcher Test es belegen würde.
- „Nicht im Scope“ leer lassen. Genau dort beginnen in Woche 4 die Diskussionen.
- Zwei Accountable-Personen in einer Zeile. Müssen beide zustimmen, mach eine Person Accountable und die andere Consulted.