Zum Inhalt springen
gorkha.io

Eine RACI-Matrix aufbauen

Eine Methode, die funktioniert: was die vier Buchstaben wirklich bedeuten, wie viele Zeilen sinnvoll sind, die zwei Regeln, die eine Matrix brauchbar machen, und die vier Arten, auf die sie üblicherweise scheitert.

Das Gorkha-Team9 Min. Lesezeit

RACI-Matrix → Legen Sie fest, wer für jede Aufgabe durchführt, verantwortet, konsultiert und informiert wird – und finden Sie die Lücken.

Eine RACI-Matrix beantwortet für jedes Stück Arbeit eine einzige Frage: Wer macht das, und wer steht dafür ein, wenn es schiefgeht? Sie ist ein Raster. Jede Spalte ist eine Person oder eine Rolle, jede Zeile eine Aufgabe oder ein Ergebnis, und in jeder Zelle steht ein Buchstabe.

Das Format ist alt und weit gereist: Das Project Management Institute beschreibt das RACI-Diagramm als ein Beispiel für eine Responsibility Assignment Matrix, die allgemeine Kategorie von Raster, das Personen auf Arbeit abbildet. Die meisten Teams begegnen ihr als Tabelle, die jemand einmal angelegt und niemand wieder geöffnet hat. Diese Variante ist wertlos. In dieser Anleitung geht es um die andere.

Was die vier Buchstaben bedeuten

Die Buchstaben sind leicht aufzusagen und leicht zu verwechseln, weil zwei von ihnen nach demselben klingen.

  • R: Responsible (ausführend). Die Personen, die die Arbeit machen. Es können mehrere sein.
  • A: Accountable (rechenschaftspflichtig). Die eine Person, die für das Ergebnis einsteht und die Befugnis hat, es freizugeben. Genau eine.
  • C: Consulted (konsultiert). Personen, deren Einschätzung eingeholt wird, bevor die Arbeit fertig ist. Beidseitig: Sie werden gefragt und sie antworten.
  • I: Informed (informiert). Personen, denen man hinterher Bescheid gibt. Einseitig.

Die Unterscheidung, die die ganze Methode trägt, liegt zwischen R und A. Responsible ist Aufwand. Accountable ist Befugnis. Wenn die Person, die du als A markiert hast, die Arbeit nicht wirklich ablehnen kann, hast du die falsche Person markiert, und die Matrix beschreibt die Hierarchie, die du dir wünschst, statt der, die du hast.

Eine Person kann beides sein. Eine Zelle mit A/R ist in kleinen Teams normal und häufig: Dieselbe Person verantwortet das Ergebnis und macht die Arbeit. Niemals akzeptabel sind zwei verschiedene Personen mit A in einer Zeile.

Die zwei Regeln

Alles andere in dieser Anleitung ist ein Ratschlag. Diese zwei sind Regeln, und eine Matrix, die eine davon bricht, sollte nicht verteilt werden.

  1. Genau ein A pro Zeile. Accountable bedeutet einen einzigen Entscheidungspunkt. Zwei rechenschaftspflichtige Personen bedeuten: Wenn sie sich nicht einig sind, lässt sich nichts klären, ohne zu eskalieren, genau das Versagen, das eine RACI verhindern soll. Null rechenschaftspflichtige Personen bedeutet, dass die Aufgabe keine Eigentümerschaft hat und spät von irgendwem entdeckt wird, der Pech hat.
  2. Mindestens ein R pro Zeile. Wenn niemand ausführend ist, macht niemand die Arbeit. Solche Zeilen sind meist Wünsche, die in einen Plan getippt wurden.

Der RACI-Builder prüft beides, während du tippst, und markiert die Zeilen, die dagegen verstoßen, denn genau diese Fehler sind unsichtbar, wenn man sein eigenes Raster liest.

Eine aufbauen, in dieser Reihenfolge

Die Reihenfolge ist entscheidend. Die meisten schlechten Matrizen sind schlecht, weil sie von links nach rechts Zeile für Zeile gefüllt wurden, was stillschweigend dazu führt, dass Arbeit der jeweils nächstgelegenen Person zugewiesen wird.

1. Erst die Zeilen, dann die Personen

Schreibe zuerst die Ergebnisse und Entscheidungen auf, ohne irgendeinen Namen. Du beschreibst die Arbeit, nicht das Team. Wenn du beim Team anfängst, entsteht eine Matrix, die die aktuelle Verteilung rechtfertigt, statt sie zu prüfen.

Ziele auf die Ebene von Ergebnissen und Entscheidungen, nicht von Aktivitäten. „Code schreiben und prüfen“ ist eine Zeile. „Einen Pull Request öffnen“ nicht. Ein brauchbarer Test: Wenn eine Zeile genau dieselben Buchstaben hätte wie die Zeile darüber, sind die zwei Zeilen eine.

Echte Matrizen liegen meist zwischen sechs und zwanzig Zeilen. Jenseits von etwa dreißig liest sie niemand mehr, und es ist besser, nach Phase zu teilen.

2. Spalten als Rollen, nicht als Namen

Nimm Engineering-Lead, nicht Priya. Rollen überleben Personalwechsel, Namen nicht. Wo eine Rolle von einer Person besetzt ist und das alle wissen, setze den Namen in Klammern dahinter.

3. Zuerst das A, über alle Zeilen

Geh die A-Spalte von oben nach unten durch, bevor du irgendetwas anderes anfasst. Das ist der Durchgang, der die echten Konflikte hochbringt: die Zeilen, in denen zwei Personen beide annehmen, sie entschieden, und die Zeilen, in denen alle einander ansehen. Kläre das jetzt. Genau deswegen machst du die Matrix.

4. Dann das R, danach C und I

Responsible kommt als Nächstes, weil es meist klar ist, sobald die Rechenschaftspflicht geklärt ist. Dann konsultiert und informiert, und sei hier geizig. Jedes C ist eine Person, die die Arbeit aufhalten kann. Eine Zeile mit fünf C ist nicht gründlich; sie ist eine Zeile, die drei Wochen dauert.

5. Lies sie spaltenweise, nicht zeilenweise

Dreh das Raster jetzt um neunzig Grad. Eine Spalte mit A in fast jeder Zeile ist ein Engpass, und diese Person ist der Grund, warum dein Projekt langsam ist. Eine Spalte mit nichts als I gehört nicht in diese Matrix. Eine Spalte ohne jeden Buchstaben ist eine Frage, die man laut stellen sollte.

Ein durchgerechnetes Beispiel

Sechs Zeilen aus einem Software-Release, mit fünf Rollen:

AufgabeProduct OwnerEngineering-LeadEntwicklerQA-LeadRelease-Manager
Release-Umfang festlegenA/RCICI
Code schreiben und prüfenIARCI
Release-Kandidat testenIACRI
Qualität freigebenACIRI
In Produktion ausrollenICRIA
Release ankündigenA/RIIIC

Lies die A-Spalte von oben nach unten, und die Struktur des Teams ist in etwa vier Sekunden sichtbar: Der Product Owner verantwortet Umfang und Kommunikation, der Engineering-Lead verantwortet, wie gebaut wird, der Release-Manager verantwortet den Akt des Ausrollens. Niemand verantwortet alles. So sieht eine funktionierende Matrix aus.

Genau dieses Raster ist die Vorlage Software-Release im Builder, in allen sieben Sprachen.

Die vier Arten, auf die es schiefgeht

Alle werden konsultiert. Der häufigste und teuerste Fehler. C ist die Zusage, auf jemanden zu warten. Wenn du nicht benennen kannst, was du abhängig von der Antwort anders machen würdest, ist die Person I.

Die rechenschaftspflichtige Person hat keine Befugnis. Eine Projektleitung als A für eine Entscheidung zu markieren, die tatsächlich nur eine Geschäftsleitungsebene treffen kann, überträgt die Befugnis nicht; es macht die Zeile nur zur Fiktion. Markiere die Person, die nein sagen kann.

Sie ist zu kleinteilig. Eine Matrix mit vierzig Zeilen einzelner Aktivitäten ist ein Dokument, das niemand aktuell hält, es ist in einem Monat falsch und in zwei Monaten irreführend.

Sie wird einmal geschrieben. Eine Matrix, die beim Kickoff entsteht und nie wieder angesehen wird, wird still falsch: Menschen wechseln Rollen, das Raster nicht. Häng sie an das Dokument, das sie beschreibt, und prüfe sie, wenn du dieses Dokument prüfst. Wenn nichts eine Prüfung auslöst, löst nichts eine Prüfung aus.

Wann etwas anderes passt

Eine RACI beschreibt laufende Arbeit: wer was macht, über viele Aufgaben, über Zeit. Für eine einzelne, einmalige Entscheidung passt sie schlecht. Dafür gibt es eigens gebaute Alternativen: DACI (Driver, Approver, Contributor, Informed), das Atlassian als Play in seinem Team Playbook veröffentlicht, und RAPID®, entwickelt von Bain and Company und dargelegt im Harvard Business Review-Artikel „Who Has the D?“ von Paul Rogers und Marcia Blenko aus dem Jahr 2006, der die Person trennt, die entscheidet, von denen, die ausführen, und Vetorechte explizit macht.

Beide sind als Modi im Builder verfügbar, und die Unterschiede lohnen sich vor der Wahl: RACI, DACI oder RAPID, was dein Team wirklich braucht.

Sie dorthin exportieren, wo sie gelesen wird

Eine Matrix wirkt nur, wenn sie dort lebt, wo die Arbeit lebt. Der Builder exportiert nach Excel und Google Sheets, nach Word, nach PowerPoint als bearbeitbare Tabelle statt als Bild, nach PDF, CSV, Markdown für Notion und als HTML in die Zwischenablage, das sich mit intakter Tabelle in OneNote oder Google Docs einfügt.

Der praktische Rat: Leg sie in das Dokument, das sie regelt (den Projektplan, das Runbook, den Projektauftrag) und nicht in eine eigene Datei. Eine Matrix in einer eigenen Datei ist eine Matrix, die niemand öffnet.

Quellen

  1. Stakeholder management and the RACI matrix, Project Management Institute
  2. DACI: a framework for group decisions, Atlassian Team Playbook
  3. Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, Rogers und Blenko, 2006