Run SheetDecision MakingDecision Roles

DACI

KomplexitätLow

Zeit30-60 min

Teilnehmende2-10

FormatBoth

MaturityEstablished

Vorbereitung

Was vor Start vorliegen muss

Materialien

Decision-Doc-Template (Notion, Confluence) mit Sektionen Driver, Approver, Contributors, Informed, Entscheidungsfrage, Optionen, Empfehlung, Entscheidung, Folgeaktionen; geteilter Bereich für Vor-Kommentare; Timer.

Personen / Rollen

Driver (treibt die Entscheidung, sammelt Input); Approver (eine Person mit finaler Entscheidungsbefugnis); Contributors (geben Input, max. 3-5); Informed (werden nach Entscheidung informiert); optional ein Facilitator bei komplexen Entscheidungen.

Vorabinfos

Entscheidungsfrage als ein Satz; relevante Daten, Constraints, Annahmen; bekannte Optionen oder Lösungsräume; Frist und Konsequenz bei Nicht-Entscheidung; vergleichbare Vorentscheidungen (ADRs).

Zeitbedarf

30-60 min Workshop, plus async Vorlauf

Setup

Decision Doc anlegen, Rollen mit Namen besetzen (nicht „Engineering“, sondern konkrete Personen). Doc mind. 48 h vor Meeting async öffnen für Vor-Kommentare.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Entscheidung trifft der Approver, basierend auf Driver-Vorbereitung und Contributor-Input, und wer wird wann informiert?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Rollen besetzen	5-10 min vorab	Pro Entscheidung Rollen mit Namen klären. Genau ein Approver, ein Driver, 2-5 Contributors, Informed-Liste.	Mehrere Approver heißt keine Entscheidung. Wenn nicht entscheidbar, ist Entscheidung auf der falschen Ebene; eskalieren.
2Phase 2: Driver bereitet vor	1-5 Tage	Decision Doc mit Frage, 2-4 Optionen, Pro/Contra, Empfehlung. Contributors async lesen und kommentieren (mind. 48 h Vor-Frist).	Driver formuliert eine klare Empfehlung, nicht nur Optionen. Wer „bin neutral“ schreibt, hat Vorbereitungsjob nicht gemacht.
3Phase 3: Workshop oder Entscheidungstermin	30-60 min	Driver stellt Empfehlung vor. Contributors bringen Vor-Kommentare in 15-20 min Diskussion. Approver stellt Klärungsfragen.	Termin nicht für Diskussion von Grund auf. Wer Doc nicht gelesen hat, kommentiert nicht. Disziplin schafft Effizienz.
4Phase 4: Approver entscheidet	5-15 min	Approver formuliert Entscheidung mit Begründung. Bei Bedarf Dissent-Notiz (Contributors, die nicht zustimmen, mit kurzem Argument).	Disagree and Commit: Contributors dürfen widersprechen, müssen aber nach Entscheidung mittragen. Dissent-Notiz schützt Vielfalt.
5Phase 5: Doku und Kommunikation	1-2 Werktage	Driver finalisiert Doc, sendet Kommunikation an Informed (oft via Channel oder Mail). Folgeaktionen mit Owner und Datum.	Ohne Kommunikation an Informed wird Entscheidung gerüchteweise verbreitet. Kanal und Format vorab klären.

Artefakt

Was am Ende rauskommt

Form

Decision Doc mit Header (Frage, Datum, Status), Rollenliste mit Namen, Optionen mit Pro/Contra, Empfehlung, Entscheidung mit Begründung, optional Dissent-Notiz, Folgeaktionen mit Owner und Datum, Informed-Verteilerliste.

Tool-Alternativen

Notion- oder Confluence-Page mit DACI-Template
Markdown-ADR-Variante im Repo
Atlassian Decision Macro
Linear-Project mit Decision-Workflow

Versionierung / Ownership

Decision Doc unveränderlich nach Entscheidung; spätere Revision als neuer Eintrag, der den alten verlinkt und Statuswechsel begründet.

spreadsheet

DACI Arbeitsvorlage

Kompakte Arbeitsvorlage für DACI mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# DACI Arbeitsmatrix

| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |

## Ergebnisartefakte
- DACI Matrix:
- Decision Owner:
- Decision Log:

## Entscheidung oder Empfehlung

Welche Konsequenz ergibt sich aus der Matrix?

Beispielausgabe

Konkret gefülltes Szenario

daci-beispiel.md

markdown

## DACI — Wechsel von Heroku zu AWS für Backend-Hosting (Decision Date: 17.05.2026)

**Rollen**
- Driver: @anna (Lead Platform)
- Approver: @marcus (CTO)
- Contributors: @ben (SRE), @lisa (Backend Lead), @julia (Finance Director)
- Informed: Engineering Org (15 Personen), Customer Success Lead, Security Officer

**Frage**: Wechseln wir bis Q4/2026 von Heroku auf AWS (EKS + RDS)?

**Optionen**
1. AWS EKS + RDS, Migration in 4 Monaten. Geschätzte Einmalkosten 95k €, monatlich -3,2k € ab Monat 5.
2. Bei Heroku bleiben, Upgrade auf Performance-Dynos. Monatlich +2,1k €, keine Migration.
3. Hybrid: kritische Services AWS, Rest Heroku. Komplex, schwer zu warten.

**Pro/Contra zusammengefasst**: Option 1 langfristig günstiger und kontrollierbarer, aber Migration risikobehaftet. Option 2 Status quo, kein Lernfortschritt. Option 3 schwer wartbar.

**Empfehlung Driver**: Option 1.

**Vor-Kommentare**: @ben +1 (Erfahrung aus Team Discovery). @lisa stimmt mit Bedenken zu Migration-Timeline. @julia bittet um Sensitivitäts-Tabelle für Kosten.

**Entscheidung Approver**: Option 1 mit Bedingung: Migration in 5 Monaten statt 4, Buffer für Risiko. Kostentabelle vor Migration erweitert.

**Dissent**: keine.

**Folgeaktionen**:
1. Migration-Plan v1 (Owner: @anna, bis 30.05.).
2. Kostentabelle (Owner: @ben, bis 24.05.).
3. Kommunikation an Informed (Owner: @anna, bis 19.05.).

Was tun

Informed-Liste Teil des Templates. Kommunikation als Pflicht-Followup mit Frist.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Approver ist nicht entscheidungsbefugt oder nicht verfügbar; Entscheidung muss eskalieren.

Frage ist zu klein (operativ), DACI-Overhead lohnt sich nicht.

Frage ist strategisch und braucht breitere Konsensbildung, Consensus Workshop oder RAPID passender.

Driver ist gleichzeitig Approver, Trennung nicht möglich.

Pre-Read-Disziplin nicht haltbar, Termine ohne Vorbereitung.

Frage ist primär politisch, faktenbasierte DACI führt nicht zur Lösung.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden