Zum Inhalt springen
James Okafor

RACI-Matrix: Wann du eine brauchst (und wann nicht)

RACI-Matrix: Wann du eine brauchst (und wann nicht)

Eine RACI-Matrix ist ein Raster. Auf der einen Achse die Arbeit, auf der anderen die Menschen, in jeder Zelle einer von vier Buchstaben: Responsible (macht es), Accountable (verantwortet es), Consulted (wird vorher gefragt), Informed (wird hinterher informiert). Das ist die ganze Idee — und jeder Artikel auf Seite eins bei Google braucht 2.000 Wörter, um sie zu erzählen.

Was keiner davon sagt: wann man keine bauen sollte. Die Seiten, die für diesen Begriff ranken — Atlassian, Wrike, project-management.com —, verkaufen alle Projektmanagement-Software. Keine von ihnen hat einen Anreiz zu schreiben: „Du brauchst das wahrscheinlich nicht.”

Ich kenne beide Seiten. In einer Firma mit 130 Leuten ist eine RACI der Grund, warum eine Preismigration über vier Teams in einem Quartal live ging statt in zwei. In einem Sechs-Personen-Startup habe ich zugesehen, wie ein Gründer einen Dienstagnachmittag an einer verbrachte, die nach zwei Wochen nicht mehr stimmte und nach einem Monat vergessen war. Dasselbe Werkzeug, gegenteiliges Ergebnis — und der Unterschied lag nicht am Template.

RACI auf einem Bildschirm: die vier Rollen und eine echte Matrix

RACI steht für Responsible, Accountable, Consulted, Informed. Hier steht, was jede Rolle erlaubt und was sie verbietet — genau der Teil, den die Definitionen überspringen:

  • Responsible — macht die Arbeit. Mehrere Personen können in einer Zeile R sein. R ist ein Verb, kein Jobtitel: Wenn du nicht benennen kannst, was diese Person produziert, ist sie kein R.
  • Accountable — verantwortet das Ergebnis und gibt es frei. Genau eine Person pro Zeile, niemals delegiert. Das A ist oft gleichzeitig ein R; das ist völlig in Ordnung.
  • Consulted — beidseitig. Der Input wird vor der Arbeit eingeholt und kann das Ergebnis verändern. Wenn die Meinung nichts ändern kann, ist die Person kein C.
  • Informed — einseitig, im Nachhinein. Sie bekommen Bescheid. Sie bekommen keine Stimme.

Genau an der Grenze zwischen C und I laufen die meisten Matrizen aus: Leute werden aus Höflichkeit als C markiert, verhalten sich dann, als hätten sie ein Vetorecht, und das R kommt nicht mehr vom Fleck. Markiere jemanden nur dann als C, wenn du die Arbeit wegen seiner Aussage tatsächlich ändern würdest.

Eine echte Matrix — eine quartalsweise Preisänderung in einem SaaS-Unternehmen mit 40 Leuten:

LiefergegenstandGründerProduktMarketingEntwicklungSupport
Neue Preispunkte festlegenARCIC
Aussagen auf der Seite freigebenIAR
Seitenänderung ausliefernICARI
Abrechnung + Bestandsschutz-LogikICIA/RC
Bestandskunden per E-Mail informierenCIA/RIC
Support-Makros + Erstattungen aktualisierenIICIA/R

Jetzt lies sie diagnostisch — was dir kein Template beibringt:

  • Lies die A-Spalte von oben nach unten. Verantwortung sollte in der Organisation nach unten wandern, je kleiner das Risiko wird. Steht überall der Gründer, hast du keine RACI, sondern einen Flaschenhals in Tabellenform.
  • Eine Zeile ohne R ist ein Wunsch. Jemand gibt frei, andere schauen zu, niemand baut es.
  • Eine Zeile nur aus C und I ist ein Meeting, kein Liefergegenstand. Streich sie.
  • Ein A in mehr als fünf Zeilen ist das Nächste, was bricht.

Infografik: eine sechszeilige Verantwortungsmatrix für eine Preisänderung über Gründer, Product Lead, Marketing, Entwicklung und Support, mit genau einer verantwortlichen Person pro Zeile und einem Befugnisrahmen, der festhält, was die ausführende Person ohne Rückfrage tun darf

Sechs Liefergegenstände, sechs Verantwortliche, keine geteilte Verantwortung. Die Befugnis-Spalte ist der Teil, den die meisten Matrizen weglassen.

Brauchst du überhaupt eine RACI? Ein Schwellentest

Eine RACI ist eine Anschaffung: Sie kauft Klarheit und kostet Pflege. Die ehrliche Frage lautet, ob deine Unklarheit teuer genug ist, um dafür zu zahlen.

Hier die Rechnung. Wenn n Personen ein Stück Arbeit plausibel verantworten könnten, ist die Zahl der „Ich dachte, du hast das”-Paare n(n−1)/2. Drei Personen: drei Wege, es fallen zu lassen. Sechs: fünfzehn. Zehn: fünfundvierzig. Unklarheit wächst mit dem Quadrat der Kopfzahl — deshalb ist dieselbe Matrix bei sechs Leuten Zeremonie und bei 130 eine Rettung.

Bewerte die Arbeit vor dir, je ein Punkt:

  1. Mehr als acht Personen fassen sie an.
  2. Mehr als eine Funktion muss Ja sagen, bevor sie live geht.
  3. Sie läuft länger als einen Monat.
  4. Eine falsche Entscheidung braucht mehr als eine Woche, um sie rückgängig zu machen.
  5. Eine Übergabe überschreitet eine Zeitzone, eine Agentur- oder eine Dienstleistergrenze.
  6. Jemand steigt mittendrin ein.

0–1 Punkte: Bau keine Matrix. Sag den Namen der verantwortlichen Person laut und mach weiter. 2–3 Punkte: Du brauchst schriftliche Verantwortung, keine Matrix. Nimm die Owner-Liste unten. 4+ Punkte: Bau die Matrix. Der Pflegeaufwand zahlt sich aus.

Wrike zitiert Forschung, wonach nur 20 % der Organisationen bei Entscheidungen wirklich gut sind. Ein echtes Problem — ab einer gewissen Größe. Kein Grund für ein Fünf-Personen-Team, ein Raster zu malen.

Unterhalb der Schwelle: die einzeilige Owner-Liste

Im Bereich 2–3 nehme ich das hier. Vier Spalten, nicht zwanzig:

Ergebnis — Verantwortliche Person — Was sie allein entscheiden darf — Datum

Eine Zeile pro Ergebnis, ein Name in der Owner-Spalte, niemals zwei. Die dritte Spalte ist die, die alle überspringen, und die, die die eigentliche Arbeit macht — der Unterschied zwischen „Priya verantwortet das Onboarding” und „Priya verantwortet das Onboarding und darf Flow, Texte und E-Mails ohne Rückfrage ändern; neue Preise kommen zu mir.”

Sie lebt in der Aufgabenliste, nicht in einem Dokument, und wird wöchentlich korrigiert — rund vier zusätzliche Minuten in einer wöchentlichen Planungsrunde.

Wechsle zur Matrix, wenn dasselbe Ergebnis innerhalb eines Monats zweimal die verantwortliche Person wechselt — oder wenn du dir eine fünfte Spalte wünschst. Bis dahin leistet saubere Aufgabenhygiene mit genau einem Owner alles, was eine RACI leisten würde, zu einem Bruchteil der Kosten.

Infografik: ein Entscheidungsbaum dazu, ob ein Arbeitspaket eine RACI-Matrix braucht, mit sechs bewerteten Fragen zu Teamgröße, beteiligten Funktionen, Dauer und Umkehrbarkeit, drei Ergebnissen - keine Matrix, eine einzeilige Owner-Liste oder eine vollständige Matrix - und der Rechnung, nach der n plausible Verantwortliche n(n-1)/2 Paare von Unklarheit erzeugen

Drei plausible Verantwortliche ergeben drei Paare von „Ich dachte, du hast das”. Zehn ergeben fünfundvierzig.

Ist RACI überholt?

Die Leute googeln das ununterbrochen, und keine einzige Seite, die für den Begriff rankt, beantwortet es. Also, ganz direkt: Nein, RACI ist nicht überholt. Es wird überstrapaziert.

Hinter der Frage stecken drei echte Einwände, jeder davon teilweise berechtigt.

„Sie ist statisch, Projekte sind dynamisch.” Stimmt — Atlassians eigener Guide räumt ein, die Matrix sei „eine statische Darstellung eines dynamischen Projekts”. Das ist ein Argument für einen Review-Rhythmus, nicht für den Verzicht. Eine Matrix mit Datum ist nicht statisch.

„Sie vereinfacht zu stark.” Auch richtig. Wrike formuliert es am schärfsten: Eine als C markierte Business-Analystin beeinflusst das Ergebnis oft weit stärker, als „consulted” nahelegt, und echte Menschen halten mehrere Rollen gleichzeitig. Die Lösung sind weniger Zeilen mit mehr Präzision, kein längeres Alphabet.

„Sie widerspricht kollektiver Verantwortung.” Der agile Einwand, und der schwächste: Teams, die Arbeit gemeinsam verantworten, haben trotzdem eine Person, die mit der Kundschaft spricht, wenn etwas kaputtgeht. RACI erschafft diese Person nicht, RACI schreibt sie auf.

Was sich tatsächlich geändert hat: Tools haben einen Teil von RACIs Job übernommen — eine Aufgabe mit genau einer zuständigen Person ist eine RACI mit einer Zelle — und für reine Entscheidungen haben entscheidungsspezifische Frameworks sie überholt. Atlassian, das dieses Zeug verkauft, empfiehlt zuerst DACI, wenn es um Entscheidungsbefugnis geht. Da stimme ich zu.

Was ist die goldene Regel von RACI?

Genau ein A pro Zeile. Nicht eines pro Projekt, nicht eines pro Team — eines pro Zeile. Jeder Guide sagt es, keiner begründet es. Hier ist die Begründung.

Eine Umstellung, die ich miterlebt habe: eine Datenbankmigration mit fest gebuchtem monatlichem Wartungsfenster. Zwei Personen waren für das Go/No-Go als accountable markiert — der Engineering Manager und der Ops Lead —, weil beide senior waren und eine Auswahl politisch gewirkt hätte. Keiner der beiden stritt. Genau das verstehen die meisten an zwei A’s falsch: Sie erwarten einen Zusammenstoß. Stattdessen wartete jeder auf das Signal des anderen, das Fenster schloss um 4 Uhr morgens ohne Deployment, und das nächste lag dreißig Tage entfernt. Eine Zeile in einer Matrix, ein Monat Laufzeit.

Zwei Accountables erzeugen keinen Konflikt. Sie erzeugen wechselseitiges Zurücktreten, unsichtbar bis zur Deadline. Einen Konflikt siehst du und löst ihn; ein Schweigen siehst du nicht.

A ist kein Maß für Aufwand oder Seniorität. A ist der Stichentscheid — die Antwort auf „Wenn die Leute, die das machen, sich uneinig sind, wer entscheidet?” Schreib zwei Namen hin, und du hast eine Blockade dokumentiert und sie Alignment genannt.

Der Test, den ich anwende, bevor ich ein A akzeptiere: Vervollständige den Satz „Wenn das schiefgeht, wird ___ derjenige sein, der es erklären muss.” Passt mehr als ein Name, ist die Zeile nicht fertig.

Das Machtgefälle-Problem — und die Lösung, die niemand aufschreibt

Wrike ist der einzige Artikel auf der Seite, der ehrlich genug ist, das anzusprechen: Eine Junior-Person, die als Responsible markiert ist, handelt möglicherweise trotzdem nicht ohne Freigabe von oben. Zwei Sätze dazu, dann geht es weiter — schade, denn das ist der häufigste Grund, warum eine fachlich korrekte RACI null Verhaltensänderung bewirkt.

Die Matrix sagt, Sam ist R. Die Organisation sagt, Sams Direktor wird eine Meinung dazu haben. Sam fragt also vernünftigerweise vorher — und jedes „verantwortlich” wird zu einer Bitte um Erlaubnis: Wartezeit ohne Autonomie.

Die Lösung besteht aus drei Teilen, von denen keiner im Template steht.

1. Hänge das A an die Entscheidung, nicht an die Hierarchiestufe. Schreib es als Satz mit einer Schwelle darin — „Textänderungen freigeben, die keine Preisaussage verändern” — nicht als Substantiv wie „Marketing-Freigabe”.

2. Gib jeder Zeile einen Befugnisrahmen. Eine Zeile, die festhält, was R ohne Rückfrage tun darf und was eine Eskalation auslöst:

R darf Layout, Text und Bilder ändern. Eskalation, wenn die Änderung eine Preisaussage verändert, eine rechtliche Verpflichtung erzeugt oder mehr als 2.000 $ kostet.

Das ist das Feld, das eine RACI operativ macht. Ohne es bedeutet „Responsible” nur „tippt es ab”.

3. Setz dem Consulted eine Uhr. Wenn eine Senior-Person ein Junior-R immer wieder überstimmt, markiere sie als C und gib dem C ein Antwortfenster: Input innerhalb von 48 Stunden, sonst macht R weiter. Schweigen wird zu Zustimmung, mit Frist. Das verwandelt ein implizites, unbegrenztes Veto in einen befristeten Input — genau das, was ohnehin alle unter „consulted” verstanden haben.

Eine Diagnose: Wenn ein R für dieselbe Art von Entscheidung dreimal um Erlaubnis gefragt hat, stimmt entweder der Rahmen nicht oder das A nicht. Zeichne die Zeile neu. Gut gemacht, gewinnt das überraschend viel ununterbrochene Arbeitszeit zurück — die meiste Fragerei ist nur ein nicht aufgeschriebener Befugnisrahmen.

RACI für verteilte und asynchrone Teams

Niemand, der für dieses Keyword rankt, schreibt über asynchrone Arbeit — was seltsam ist, denn genau dort verdient das Werkzeug am meisten. Am selben Standort kostet „Moment, wem gehört das?” dreißig Sekunden. Über acht Stunden Zeitverschiebung kostet es einen Arbeitstag: um 17 Uhr fragen, die Antwort am nächsten Tag lesen, am übernächsten handeln. Dieselbe Unklarheit, ungefähr der 200-fache Preis. Verteilte Teams sollten früher zur RACI greifen, als der Schwellentest nahelegt, nicht später.

  • Bemiss jedes C-Fenster an der größten Zeitdifferenz plus einem Arbeitstag. 48 Stunden sind in einem Büro großzügig und zwischen Berlin, Lagos und San Francisco unmöglich. Schreib echte Stunden hin.
  • Definiere I als Artefakt, nicht als Ereignis. „Informed” benennt das Ding, das sie lesen werden — das Freitags-Update, den Release-Kanal. „Sie waren im Meeting” ist kein Informieren, das ist Hoffen.
  • Ergänze eine Spalte für die Entscheidungs-Deadline. Halt fest, bis zu welcher Uhrzeit im Tag des R eine Rückfrage an das A noch am selben Tag beantwortet wird. Klingt kleinlich. Beseitigt eine ganze Kategorie stiller Ein-Tages-Verzögerungen.
  • Lass das R eine schriftliche Definition of Done veröffentlichen. Das A kann der Arbeit nicht beim Entstehen zusehen, also braucht es etwas, woran es vorher prüfen kann.

Eine bauen, die nicht veraltet

Der Aufbau geht schnell: Liefergegenstände auflisten (keine Aktivitäten), die Buchstaben in zwanzig Minuten selbst entwerfen, dann eine halbe Stunde live mit dem Team daran korrigieren. Lass den ersten Entwurf niemals von der Gruppe machen — ein leeres Raster und sechs Leute in einem Call verbrennen zwei Stunden und produzieren Brei.

Über die Pflege spricht niemand, also hier meine ehrliche Zahl: rund 20 Minuten alle zwei Wochen pro zehn Zeilen, das meiste davon die Nachprüfung, ob die A-Spalte noch abbildet, wer tatsächlich entscheidet. Eine Matrix mit dreißig Zeilen ist eine Stunde im Monat, für immer. Das ist der Listenpreis.

Drei Regeln halten sie am Leben.

Die Matrix braucht ein eigenes A. An dieser Auslassung sterben die meisten Matrizen — ein Verantwortungsdokument ohne Verantwortliche ist der Witz, der sich selbst schreibt. Benenne, wer sie aktualisiert, und datiere die Datei.

Sie muss dort leben, wo die Arbeit lebt. Wrikes Best-Practice-Liste hat hier recht — halte sie im Tool, nicht in einem separaten Dokument —, verbindet das aber nie mit dem Veralterungsproblem, das sie ein paar Absätze vorher beschreibt. Dasselbe Problem: Eine Matrix in einem Wiki, das niemand öffnet, ist von Geburt an veraltet. Eine Zelle einer RACI ist nichts anderes als das Zuständigkeitsfeld einer Aufgabe — deshalb halte ich die Verantwortung an den Aufgaben selbst in Fokus und behandle das Raster als Zusammenfassung dessen, was diese Aufgaben ohnehin schon sagen.

Lösch sie, wenn sie still wird. Wenn die Matrix zwei Review-Zyklen lang nicht angefasst wurde, weg damit. Das fühlt sich verschwenderisch an und ist es nicht: Eine gelöschte Matrix bringt Leute dazu zu fragen, wem etwas gehört, eine veraltete bringt sie dazu, es anzunehmen. Mein wöchentlicher Review in Fokus ist der Ort, an dem diese Entscheidung fällt — freitags korrigiert oder in Rente geschickt.

Atlassian benennt die Grenze am besten: Eine RACI „gibt keine Anleitung zur Ausführung der Aufgaben, was zu Inkonsistenzen durch unterschiedliche Auslegungen der Verantwortlichkeiten führt”. Sie sagt dir, wer — nie, wie gut.

Wenn RACI die falsche Matrix ist: RASCI, DACI, RAPID und CARS

Wähle nach der Form deiner Unklarheit:

  • RASCI ergänzt eine explizite Supportive-Rolle — Cornells IT-Dokumentation beschreibt sie am besten. Nimm es, wenn viele Leute helfen, ohne im Obligo zu stehen.
  • DACI (Driver, Approver, Contributor, Informed) ist für Entscheidungen, nicht für laufende Arbeit.
  • RAPID (Recommend, Agree, Perform, Input, Decide) trennt Empfehlen vom Entscheiden — für den Fall, dass Expertise und Befugnis auseinanderliegen.
  • CARS (Communicate, Approve, Responsible, Support) ist schlanker, für kommunikationsförmige Probleme.

Grobe Regel: Unklarheit darüber, wer entscheidet → DACI oder RAPID. Darüber, wer die laufende Arbeit macht → RACI. Darüber, welche von vierzig Sachen diese Woche zählt → gar keine Matrix; das ist ein Priorisierungsproblem, und keine Verantwortungsmatrix hat je eines gelöst.

Die Kurzfassung

R macht die Arbeit, A verantwortet sie, C formt sie vorher, I hört hinterher davon. Die goldene Regel ist genau ein A pro Zeile, weil A der Stichentscheid ist und zwei Stichentscheide eine verkleidete Blockade sind.

RACI ist nicht überholt, es wird überstrapaziert. Mach den Sechs-Fragen-Test. Unter zwei Punkten: verantwortliche Person benennen und weitermachen. In der Mitte: eine Zeile pro Ergebnis, mit ausgeschriebenen Entscheidungsrechten. Über vier: bau das Raster, gib jeder Zeile einen Befugnisrahmen, setz dem Consulted eine Uhr, halte es dort, wo die Arbeit lebt, und lösch es an dem Tag, an dem es nicht mehr stimmt.

Eine Matrix, die richtig ist und ignoriert wird, ist nichts wert. Eine Matrix, die falsch ist und der man vertraut, ist weniger als nichts wert.

James Okafor

James Okafor

Team Collaboration Writer

James focuses on remote work, team dynamics, and collaboration strategies. He brings firsthand experience leading distributed teams across four continents.