Die häufigste Ausrede gegen einen Hackathon ist Vorbereitungsaufwand. Sie stimmt nur, wenn man ihn wie ein Großprojekt plant. Mit klaren Entscheidungen reichen fünf Arbeitstage – hier ist der Plan, den wir tatsächlich verwenden.
Tag 1 – Use Cases einsammeln
Kein Ideenworkshop, kein Miro-Board mit 200 Zetteln. Eine Frage an alle Teilnehmenden: Welche Aufgabe kostet Sie jede Woche Zeit und nervt Sie? Drei Sätze, per Formular, Deadline am Abend. Sie bekommen zwischen 30 und 80 Antworten, davon sind 15 brauchbar.
| Kriterium | Frage | Ausschluss, wenn |
|---|---|---|
| Frequenz | Wie oft passiert das? | Seltener als monatlich |
| Klarheit | Kann man den Ablauf aufschreiben? | Niemand kennt den Ist-Zustand |
| Datenzugang | Sind Daten verfügbar? | Zugriff braucht drei Freigaben |
| Risiko | Was passiert bei Fehlern? | Direkte Außenwirkung ohne Prüfung |
| Eigentümer | Wer will es haben? | Niemand meldet sich freiwillig |
Tag 2 – Teams schneiden
Drei bis fünf Personen pro Team, immer gemischt: jemand, der den Prozess wirklich macht, jemand mit Technikaffinität, jemand mit Entscheidungsbefugnis oder direktem Draht dorthin. Reine Abteilungsteams bauen reine Abteilungslösungen.
Das beste Signal für ein gutes Team ist Reibung am Vormittag. Teams, die sich sofort einig sind, bauen meistens das Offensichtliche.
Tag 3 – Tools und Zugänge
Accounts anlegen, Credits verteilen, Testdaten vorbereiten. Dieser Tag entscheidet über den Erfolg des Events mehr als jede inhaltliche Vorbereitung, weil verlorene Zeit am Eventtag nicht aufholbar ist.
- Alle Zugänge einmal mit einem echten Testnutzer durchspielen, nicht nur anlegen.
- Synthetische oder anonymisierte Datensätze bereitstellen – Diskussionen über Echtdaten am Eventtag kosten Stunden.
- Eine Fallback-Variante pro Tool definieren, falls ein Dienst ausfällt.
- WLAN-Kapazität prüfen. Ja, wirklich.
Tag 4 – Choreografie festlegen
Der Eventtag hat einen festen Takt. Kein offenes Arbeiten, sondern Blöcke mit harten Übergängen. Der Zeitplan ist das eigentliche didaktische Instrument.
| Zeit | Block | Ergebnis |
|---|---|---|
| 09:00 | Kickoff und Toolimpuls | Alle haben einmal etwas gebaut |
| 10:00 | Scoping im Team | Ein Satz: Was ist am Abend fertig? |
| 10:30 | Build I | Erste lauffähige Version |
| 13:00 | Zwischenstand mit Coach | Scope halbiert |
| 14:00 | Build II | Funktionierender Kernablauf |
| 16:00 | Pitch-Vorbereitung | Drei Minuten, Live-Demo |
| 17:00 | Demos und Entscheidung | Owner und nächster Schritt je Projekt |
Tag 5 – Nachbereitung vorbereiten
Klingt paradox, ist aber der Unterschied zwischen einem netten Tag und einer Veränderung. Legen Sie vorher fest, was nach dem Event passiert: Wer entscheidet über Weiterbau, welches Budget steht bereit, wann ist der Review-Termin. Ohne diese drei Antworten endet jeder Hackathon in Applaus und Stille.
Die fünf teuersten Fehler
- 01Zu große Use Cases zulassen – die Halbierung um 13 Uhr rettet den Tag nur teilweise.
- 02Echtdaten ohne vorherige Freigabe einplanen.
- 03Führungskräfte nur zur Demo einladen statt zum Kickoff.
- 04Keine Coaches im Raum: Ein Team pro Coach ist zu wenig, fünf sind zu viele.
- 05Nach dem Event keinen Termin im Kalender haben.